Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility

From: Russ Housley <[email-masked]>
Date: Mon, 1 Jun 2015 14:19:58 -0400

Christian and Ian:

> On 26/05/2015 19:15 pm, Christian Huitema wrote:
>>>> Apart from an initial comment on the draft I've tried to avoid getting
>>>> involved in a debate over this since I think the issue is at least as
>>>> much (if not more) religious than technical.  For example I can use
>>>> Russ' WEP example to argue exactly the opposite of the point he's
>>>> trying to make: The problem with WEP wasn't a 1TCS one, it was that it
>>>> was designed by non-cryptographers, and was badly broken. If they'd
>>>> gone with four cipher suites instead of one, we'd just have four badly
>>>> broken ones instead of one, or, worse, three badly broken ones and one
>>>> not-quite-as-broken one so they could tell everyone to use the not-quite-as-
>>> bad one.
>>> 
>>> I see the history a bit differently.  The original WEP had a 40-bit key, and no one
>>> looked at the protocol because the security was obviously weak.  When the key
>>> size was increased to 128-bits, then people looked at the protocol and saw all of
>>> the major mistakes.  It is hard to believe that so many mistakes can be made in
>>> one protocol.
>> 
>> WEP is certainly one of the worse examples out there. The initial key length was ridiculous, the initialization vector was used incorrectly, the linear CRC did not protect the data integrity, etc. It seems like a textbook example against having just one cipher. But at the same time, WEP issues could not be fixed by just changing the underlying encryption algorithm. The fixes required changing the whole protocol, which is actually an example of versioning.
> 
> "But at the same time..." :)
> 
>> The other "bad example" of security design is of course the use of A5 in GSM. This one provides an interesting view on key and algorithm negotiation. The standard was deliberately compromised to enable mass surveillance.
> 
> It was deliberately compromised, yes.  The MiB were in the design room.
> 
> However, it is important to remember our security modelling.  GSM crypto was designed to protect against two things:  paparazzi and billing fraud.  It did those very well.  It was never designed to protect against national security agencies, and didn't need to, given that the GSM protocol was only secure on air.  Both the European agencies and every other agency could easily hack in and listen in the clear.

Both WEP and GSM A5 were only intended to protect one radio hop.

The capabilities available to the non-nation-state attacker grew considerably from the time of the design to the end-of-life for that design.  And, that is the thing that we need to consider for this document.  What guidance would allow a solid protocol design an the transition to a stronger algorithm?

Russ

---

From: Watson Ladd <[email-masked]>
Date: Mon, 1 Jun 2015 11:28:40 -0700

On Jun 1, 2015 11:21 AM, "Russ Housley" <[email-masked]> wrote:
> >> WEP is certainly one of the worse examples out there. The initial key
length was ridiculous, the initialization vector was used incorrectly, the
linear CRC did not protect the data integrity, etc. It seems like a
textbook example against having just one cipher. But at the same time, WEP
issues could not be fixed by just changing the underlying encryption
algorithm. The fixes required changing the whole protocol, which is
actually an example of versioning.
> >> The other "bad example" of security design is of course the use of A5
in GSM. This one provides an interesting view on key and algorithm
negotiation. The standard was deliberately compromised to enable mass
surveillance.
> > However, it is important to remember our security modelling.  GSM
crypto was designed to protect against two things:  paparazzi and billing
fraud.  It did those very well.  It was never designed to protect against
national security agencies, and didn't need to, given that the GSM protocol
was only secure on air.  Both the European agencies and every other agency
could easily hack in and listen in the clear.
> The capabilities available to the non-nation-state attacker grew
considerably from the time of the design to the end-of-life for that
design.  And, that is the thing that we need to consider for this
document.  What guidance would allow a solid protocol design an the
transition to a stronger algorithm?

TLS has algorithm agility. Has TLS successfully transitioned algorithms in
response to weaknesses? The data indicates not, and in fact algorithm
agility has weakened TLS as shown by logjam.

Version changes are a much easier mechanism to implement securely. Removing
options from user control makes upgrades easier. We need to really think
through how depreciation will work, before we know what is the solution and
what is the problem.
>
> Russ
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Russ Housley <[email-masked]>
Date: Mon, 1 Jun 2015 14:51:24 -0400

Ian:

> Section 3.3 said this:
> 
>   3.3.  Preserving Interoperability
> 
>   Cryptographic algorithm deprecation is very hard.  People do not like
>   to introduce interoperability problems, even to preserve security.
>   As a result, flawed algorithms are supported for far too long.  The
>   impacts of legacy software an long support tails on security can be
>   reduced by making it easy to develop, deploy, and configure new
>   algorithms.
> 
> Suggest changing last two lines to this:
> 
>   ...
>   reduced by making it easy to rollover old suites to new suites.
> 
> 
> Elsewise, the text would be to suggest that "adding new algorithms" is the solution when actually it's part of the problem.

I suggest this minor rewording:

Cryptographic algorithm deprecation is very hard.  People do not like to introduce interoperability problems, even to preserve security.  As a result, flawed algorithms are supported for far too long.  The impacts of legacy software an long support tails on security can be reduced by making it easy to rollover from old algorithms and suites to new ones.

[snip.  removing part where there is agreement.]

>> I suggest adding another paragraph:
>> 
>> In many ways preserving interoperability is a difficult social problem.  For example, consider web browsers.  Dropping support for an algorithm suite can break connectivity to some web sites because, and the browser will lose users by doing so.  This situation creates incentives to support algorithm suites that would otherwise be deprecated, but preserving interoperability.  Coordinating the demise of an algorithm suite is an important aspect of the answer to this social problem.
> 
> 
> Yep, that's good.
> 
> I don't like the "social problem" part.  While this may sound good to our ears, it gives the impression that the users are the problem, when in fact they are simply responding to the hand we dealt them.  I.e., we created the protocol, and we created it in a way that it isn't easy to deprecate old stuff.  Now we're blaming them for acting precisely how the protocol channels them.
> 
> How about this:
> 
>     Without clear mechanisms for rollover, preserving
>     interoperability becomes a difficult social problem.
>     For example, consider web browsers....but preserving
>     interoperability.
> 
>     Institutions, being large or dominating users within
>     a large user base, may find that coordinating the demise
>     of an algorithm suite is an important method to minimise
>     the trauma of rollover to the users.
> 
> 
> 
> Notes. 1. I'm using the term "institution" in its economic sense, which is natural for me, but may be weird to others.  I'm not sure what term would be comfortable here, but recall NIST is another institution (other than the browsers) that has coordinated demise in this fashion.
> 
> 2.  Then, it would be grand if we could also expand on ways in which the designer / WG / IANA / IETF could help by coordinating.  But that's beyond my ken to write.

I have not seen anyone comment on your use of "institution" or offer any suggestions on ways that the IETF can help with the coordination.

So I suggest a minor editorial change that is intended to point out that the coordination will help used in the institution and others too:

Without clear mechanisms for algorithm and suite rollover, preserving interoperability becomes a difficult social problem.  For example, consider web browsers.  Dropping support for an algorithm suite can break connectivity to some web sites because, and the browser will lose users by doing so.  This situation creates incentives to support algorithm suites that would otherwise be deprecated, but preserving interoperability.

Institutions, being large or dominate users within a large user base, can assist by coordinating the demise of an algorithm suite, making the rollover easier for their own users as well as others.

[snip.  removing part where there is agreement.]

>>> I find Section 4.6 baffling.
> 
> The para is disjoint.  It starts out with a discussion of what might happen, without clear point (to me).
> 
> Then switches dramatically to how to transition.  I suspect the 'bits' discussion belongs elsewhere.
> 
> Then, the meat:
> 
>   Where possible, authors SHOULD provide
>   notice to implementers about expected algorithm transitions.  One
>   approach is to use SHOULD+, SHOULD-, and MUST- in the specification
>   of algorithms.
> 
>   ...
> 
> seems happy stand-alone, following on from the title.

We often get a lot of notice for transitions like DES --> Triple-DES --> AES.  We should not surprise product planners.

>>> We have words that we can use for these
>>> things.  They are MUST NOT, MUST and SHOULD.  None of these attempt to
>>> presage the future.  But generating new conventions for what might or
>>> might not happen in the future is much harder than waiting and just
>>> making the change when the time comes.
>> 
>> This idea is not new.  It was first used with IKEv1 when Jeff Schiller was SEC AD.  The idea is to give product planners a heads up.
> 
> 
> So, could this be introduced with that explanation?  Something like:
> 
>   Where possible, authors SHOULD provide
>   notice to implementers about expected algorithm transitions.
> 
>   IKEv1 introduced a mechanism to provide notice which this ID adopts
>   [REF].  This approach uses additional hints SHOULD+, SHOULD-,
>   and MUST- in the specification of algorithms.
> 
>        SHOULD+...
>        SHOULD-...
>        MUST-...

Does this work for the reference?

Where possible, authors SHOULD provide notice to implementers about expected algorithm transitions.  One approach that was first used in RFC 4307 [RFC4307] is to use SHOULD+, SHOULD-, and MUST- in the specification of algorithms.

Russ

---

From: Watson Ladd <[email-masked]>
Date: Mon, 1 Jun 2015 23:18:44 -0700

> The capabilities available to the non-nation-state attacker grew considerably from the time of the design to the end-of-life for that design.  And, that is the thing that we need to consider for th…

Taking the opportunity to expand on my previous email:

A Freudian slip much? Because we really do care about stopping nation
state adversaries, and can afford to only use strong ciphers.

When A5 designed the goal was 56 bit security. But the existence of
Berkenlamp-Massey algorithm and the design of A5 ensures that a guess
and determine attack is possible, as Ross Anderson noted in 1994,
shortly after public description of the algorithm.  That should have
started the clock ticking on replacement, but didn't. DES would have
been a better, more studied choice, but probably didn't fit the
performance requirements.

Fallback to A5/2 is one of the major issues: the same key is used with
two ciphers, one weak and one strong. When GSM began to replace A5/1
and A5/2, they picked A5/3 as KATSUMI, a modified MISTY. But the
modifications reduced security significantly in the related key mode,
and were done concurrently with the AES, which produced a much better
result.

Likewise, WEP used a known-broken cipher. The first analysis results
on RC4 date from a month after it was publicly presented, and are due
to Andrew Roos, back in 1995. They should have immediately
disqualified it from use, but didn't for unclear reasons.

If we want to do better, we need to learn. I think this draft should
provide the following guidance:
-Key agreement schemes should produce keys that hash the entire transcript.
-Signatures should indicate all data that affects the choice of what
is being signed at the start to avoid cross-protocol attacks.
-Replacement of algorithms needs to begin when results are discovered,
not when attacks become practical.
-In order to ensure algorithms aren't used, the code needs to be
deleted by a certain date. If that cannot be achieved, ending use is
only an illusion.
-Protocol designers should be familiar with the cryptographic
literature regarding constructions and ciphers used.

Sincerely,
Watson Ladd

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Jun 2015 13:09:35 +0100

Hi Watson,

> not when attacks become practical.

Just on this point. Most IETF folks do not monitor the academic
literature for crypto publications. And indeed, it's in the nature
of academic publishing that all papers try to sound like they are
world-changers (with a few honourable exceptions), so it's not clear
to me that we should immediately start to deprecate <foo> as soon
as a <foo-has-an-issue> preprint hits arxiv.org in all cases. So
there's a bit of skilled interpretation required here.

I don't think it's part of Russ' draft, but if folks had any ideas
of ways to better feed important academic results into the IETF
process that'd be good. (And yes, we could ask CFRG, but I'm not
sure that kind of ongoing maintenance type thing is so well suited
for that group.)

I wonder if some of the larger vendors have groups who do this
internally and would be willing to share some of that analysis with
the IETF from time to time?

Anyway, ideas welcome.

Cheers,
S.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 2 Jun 2015 13:17:14 +0000

Stephen Farrell <[email-masked]> writes:

>And indeed, it's in the nature of academic publishing that all papers try to
>sound like they are world-changers (with a few honourable exceptions), so it's
>not clear to me that we should immediately start to deprecate <foo> as soon as
>a <foo-has-an-issue> preprint hits arxiv.org in all cases.

+1 Insightful.  On the one hand there are complaints that vendors won't do
anything until there's an active exploit in the wild, but then if they
believed every arxiv.org (although I'd use eprint.iacr.org) article then
nothing would be safe to use.  Or, worse, there'd be ten conflicting ways that
we're supposed to use something safely.  So then it becomes a judgement call
on what to respond to and what can be safely ignored, or perhaps postponed
until more data is available.

For me, this is an engineering issue, not a crypto/mathematics one.  At the
start of my book on crypto architecture design I include Jon Bentley's quote
about John Roebling:

  John Roebling had sense enough to know what he didn’t know.  So he designed
  the stiffness of the truss on the Brooklyn Bridge roadway to be six times
  what a normal calculation based on known static and dynamic loads would have
  called for. When Roebling was asked whether his proposed bridge wouldn’t
  collapse like so many others, he said “No, because I designed it six times
  as strong as it needs to be, to prevent that from happening”

If you look at SSL, that design principle is evident there in the use of dual
MD5 + SHA1 hashes.  MD5 has been broken, SHA1 is looking a bit wobbly, but no-
one's even managed to suggest an attack against the combined hashes.  It's a
20-year-old design using broken/near-broken hash functions, and yet its
Roebling-style design means it's still sound, and there's (currently) no sign
of it failing.

Peter.

---

From: Russ Housley <[email-masked]>
Date: Tue, 2 Jun 2015 12:01:58 -0400

Phillip:

> Comments
> 
> Section 2.2
> 
> " Note that this is not done for protocols that are embedded in
>    other protocols, where the system-level protocol specification
>    identifies the mandatory-to-implement algorithm or suite."
> 
> I would rather this is called out as a named exception, 'Specifications that provide a platform' or some such.
> 
> The reason for this is that I have sat through many unproductive hours of argument over what should be MTI in what is obviously a platform spec. Having RSA-SHA1 be MTI in XML Signature only hurts.
> 
> As written, the language uses 'protocol' which is too narrow. Only some IETF specs are protocols.

I suggest a subsection:

   2.2.1.  Platform Specifications

   Note that mandatory-to-implement algorithms or suites are not
   specified for protocols that are embedded in other protocols; in
   these cases the system-level protocol specification identifies the
   mandatory-to-implement algorithm or suite.  For example, S/MIME
   [RFC5751] makes use of the cryptographic message Syntax (CMS)
   [RFC5652], and S/MIME specifies the mandatory-to-implement
   algorithms, not CMS.  This approach allows other protocols can make
   use of CMS and make different mandatory-to-implement algorithm
   choices.

> "To achieve this
>    goal, the base protocol specification includes a reference to a
>    companion algorithms document, allowing the update of one document
>    without necessarily requiring an update to the other.  "
> 
> I would prefer it if the 'companion document' can be shared across specs. As a practical matter, a mail client has to use TLS these days. Ergo the intersection of the cipher suites supported by TLS, OpenPGP and S/MIME should be non-zero and be MTI for the 'email' domain.

This cross-many-security-protocol document seems like a pretty high bar.  I am unaware of any attempt to write used a document, ever.  So, it certainly is not current practice.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 2 Jun 2015 12:05:35 -0400

> until more data is available.

Does this capture the point?

   It takes a long time to specify, implement, and deploy a replacement
   algorithm or suite.  For this reason, the transition process needs to
   begin when initial flaws are discovered, not when attacks become
   practical.

Russ

---

From: Watson Ladd <[email-masked]>
Date: Tue, 2 Jun 2015 09:36:22 -0700

> there's a bit of skilled interpretation required here.

It's true that some foo has issue papers are overhyped or contain
mistakes. But this tends to be easy to notice. Wang's 2004 MD5 paper
came complete with collisions. Andrew Roos's experimental observations
can be replicated with a comparatively small amount of machine time.
Could you point to examples of attack papers, widely believed to work,
that should have been ignored?

Of course, if you don't understand what properties ciphers are
required to have, you'll ignore any result. IETF participants were
absolutely aware of the 2001 Vaudenay paper, and Bard's production of
practical attacks: look at Bodo Moeller's text file from 2004,
detailing these attacks. They dismissed them for incorrect reasons,
and never fixed the core problems.

The Fluhrer and McGrew of RC4 cryptanalysis are who you think they
are. That didn't help with RC4 depreciation, which didn't start until
2013.

One of the flaws which logjam exploits is the absence of any data
indicating what was supposed to be signed. This was a widely known
weakness of TLS, which wasn't fixed through several revisions. It
doesn't exist in SSH, and IKEv2 handles it slightly better.  Clearly
some people understood the issues better than others, and some
communities, like the SSH community, have been able to react better
than other communities like the TLS community.

This is not missing obscure paper on the archive: these were widely
publicized results, or in some cases immediately visible flaws in
schemes, which some people payed attention to and others didn't. The
problem is not "plugging into the IETF", but the way in which IETF
participants don't take security seriously, and instead come to accept
longstanding issues as not worth the trouble of fixing: the IKEv1
aggressive mode issue that the NSA is exploiting today isn't new.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2015 11:56:32 -0500

>    begin when initial flaws are discovered, not when attacks become

Our protocols need to be agile-capable so that we don't have to struggle
with that aspect of protocol design when it comes time to design,
specify, implement, and deploy a replacement algorithm/algorithm suite.

As to when an algorithm's flaws are first found, well, generally we can
start extrapolating based on Moore's law and past improvements in
cryptanalysis capabilities.  Every flaw isn't panic button worthy, but
some are.  We need a process to decide when to hit the panic button.

The IETF ought to commit to reviewing public cryptanalysis results and
then making _official_ (IESG and IAB) statements as to their impact on
Internet protocols in particular, and the IETF in general.

Official statements coupled with I* policy.

That is: we should NOT allow ourselves to ignore public cryptanalysis
results (whatever the cause might be, such as apathy, inertia, whatever).

This way we'll be ready to start the migration process as soon as it
becomes advisable to do so.  And if we make our protocols agile to begin
with, then migrations won't hurt much.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2015 11:59:49 -0500

>    use of CMS and make different mandatory-to-implement algorithm

I agree with this.  But note that TLS is not quite like CMS here.  TLS
needs a set of MTIs for general use.  Other profiles of TLS might change
this.

> > I would prefer it if the 'companion document' can be shared across
> > specs. As a practical matter, a mail client has to use TLS these
> > days. Ergo the intersection of the cipher suites supported by TLS,
> > OpenPGP and S/MIME should be non-zero and be MTI for the 'email'
> > domain.
> 
> This cross-many-security-protocol document seems like a pretty high
> bar.  I am unaware of any attempt to write used a document, ever.  So,
> it certainly is not current practice.

If we can pull it off, we should.  How many such "domains" might we
have?

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Jun 2015 18:15:11 +0100

Hi Nico,

> Official statements coupled with I* policy.

In practice the IESG (and probably the IAB) would assume the
SEC ADs would do this. I don't think it's feasible to assume
that the SEC ADs are going to be able to monitor all academic
crypto publications. (That also goes against attempts the IESG
are starting to make to reduce the time required for the AD
role.)

And I'm not sure if pronouncement from on high like that are
really a good plan for us either, even though it has been the
case that the IETF and implementers of IETF RFCs have been too
slow to deprecate stuff.

So while I do like the aimed-for outcome, I really doubt
there's a mechanism to get there that'd work. But if you have
a detailed suggestion I'd be v. interested.

Cheers,
S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2015 12:42:15 -0500

> are starting to make to reduce the time required for the AD

As Watson points out, we do tend to notice cryptanalysis results that
require our attention.  The problem is that we've dropped the ball in
the past.  We need a process for obtaining official statements, and a
way for anyone who notices such results to trigger it.

> case that the IETF and implementers of IETF RFCs have been too

It's about removing excuses.

We might still take years to respond (perhaps because the protocols as
deployed are not really agile, or because implementation update
mechanisms are slow, or because of abandonware with large market share),
but at least we'll know we have to, and everyone will know we know we
have to.

> a detailed suggestion I'd be v. interested.

 - someone notices such a paper
 - they open a ticket in the Datatracker requiring IAB and/or IESG
   attention
 - the IESG and/or IAB should be obliged to produce a response, with a
   Datatracker ticket for it.

   If no response is forthcoming, we'll at least have the ticket.

 - if an official statement is deemed unnecessary, this should be
   recorded in the ticket

 - if an official statement issues, this too should be recorded in the
   ticket

   Any proposed official statement should have IETF review.

Do we need an RFC to document such a process?  It should suffice that we
have the requisite Datatracker functionality.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Jun 2015 19:08:24 +0100

Hiya,

On 02/06/15 18:42, Nico Williams wrote:
> the past. 

I agree we've done that. I'm less sure there would have been
an overall better outcome if we'd acted sooner, but it's
definitely arguable.

> We need a process for obtaining official statements, and a

I'm not convinced an official statement that isn't an RFC
is useful, but that's a detail, we do know how to produce
statements as RFCs.

>    Datatracker ticket for it.

Yeah, I'm very unconvinced that the "IESG and/or IAB" is right
for that. That'd basically be the SEC ADs (do you think the
routing ADs would do it?:-) and that's too much work for which
SEC ADs aren't usually qualified. To illustrate, if we got a
credible problem report about alg-X, it could take quite
a while to figure out all the protocols that use that, and to
figure out how important/practical it is to deprecate alg-X.
And even more effort to push that through the consensus
process, esp if there are folks (as there will be) who'd
prefer to not start deprecating alg-X just now. That's a lot
of work, and as one of the SEC ADs I'd not be willing to take
it on or argue that the IESG/IAB ought take it on collectively.

I could maybe buy a version of this where we setup a new
"cryptodir" with a smallish number of qualified folks selected by
the IESG or SEC ADs and who have just this responsibility, i.e.
to do the analysis and churn out RFCs signalling when it's time
to start to deprecate alg-X or mode-Y or similar. I'd need to
ponder it more though, but reactions to that (and/or other ideas)
are welcome.

> have the requisite Datatracker functionality.

I'd say best would be to figure out something practical and where
it'd be something to which thos e implementing and deploying would
pay attention and then we can figure out how to do the related
process-wonkery.

Cheers,
S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2015 13:51:04 -0500

> an overall better outcome if we'd acted sooner, but it's

We can't know that.  I'm not talking about the past anyways, but the
future.

> is useful, but that's a detail, we do know how to produce

Well, just this week there's a long thread about a statement, isn't
there, about the IETF using HTTPS everywhere.  So we do know how to make
such statements in ways other than by producing RFCs.

> [...]

Any security-conscious AD might, or any AD might at the request of an
IETF participant.  That should suffice.

What matters is that we begin tracking the issue and that it result in
some sort of action (perhaps an RFC, perhaps something else).

I don't think it's a lot of work to start the ball moving!  Finishing,
of course, might take a while, but again, the key is to have a
datatracker item we can... track.

> ponder it more though, but reactions to that (and/or other ideas)

Secdir should suffice.  How often do we think such cryptanalysis results
to occur?

> pay attention and then we can figure out how to do the related

This is a good argument for producing an RFC.  But we can start with a
statement that produces the impetus for participants to bother with an
RFC.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 2 Jun 2015 19:18:12 +0000

>   begin when initial flaws are discovered, not when attacks become

Uhh, no, I think it makes it worse.  Every algorithm has flaws (well, with the
possible exception of Montgomery ladder-based ECC systems, which are totally
perfect, if you've been following the discussion on the cryptography mailing
list :-), so what the above is saying is that every crypto algorithm needs to
have steps taken to replace it.

Now you could say "practically exploitable flaws", but that means different
things to different people.  I don't think there's a way to definitively state
this.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Jun 2015 20:25:19 +0100

Just a couple of points below, this is maybe more
one to ponder for a bit or let's see if we get more
input...

> IETF participant.  That should suffice.

Sure, in theory. But we're after something systematic here
so I really can't see that happening. (Where that == anyone
other than the SEC ADs being on the hook for doing all the
work, and this one won't be:-)

> datatracker item we can... track.

I figure tracking is necessary, but far from sufficient for
this.

> Secdir should suffice.  How often do we think such cryptanalysis results

I don't think secdir is right for this myself, but I could be
wrong. Reasons: a) secdir folk are good but generally aren't crypto
people, b) there're ~50 secdir folks which is too many for this,
if the starting point was to be some level of group-consensus that
a report is worth pursuing, (which I think would be needed) and
c) secdir is busy already, I think getting it even better at what
it does would be more worthwhile than adding new tasks for now.

Cheers,
S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2015 16:00:20 -0500

> work, and this one won't be:-)

"on the hook for doing all the work" is not what I have in mind.

More like: on the hook for shepherding the work, which is what ADs do.
And if they want to delegate that to someone outside the IESG, that'd be
fine too.

What I imagine is that for the more obvious cases the statement would be
obvious and non-controversial.  "Algorithm A is now clearly on its last
legs [or utterly useless, or whatever might be the case], it's time to
move on.  We ask that WGs X, Y, and Z re-charter to make specification
for a replacement (likely algorithm B) a priority."

Where the statement to make is less obvious or more controversial, an
IETF LC (and I-D vehicle for it?) may be necessary.  So what.

> I figure tracking is necessary, but far from sufficient for

Tracking is a first step.  Not quite a sine qua non, but look, it
doesn't cost much and it will be harder for us to ignore things that
shouldn't be if we have a tracker.

> people, b) there're ~50 secdir folks which is too many for this,

Yes, but again, some of the papers we're talking about have very obvious
impact.  If not, go ask CFRG or whatever crypto experts you can round
up.  If you (the ADs, the IESG, the IAB) can't find the requisite
expertise and advise even when you ask for it, and you're not sure
yourselves, then leave the issue open in the tracker and make no
statement until the expert advise required materializes.

> it does would be more worthwhile than adding new tasks for now.

The starting point is never consensus.  The starting point is a proposal
that begins the process of discovering consensus.  I want to put the
onus for *starting* that process on the adults in the room: the IESG and
the IAB.  With luck you won't really have to do much because we, IETF
participants, hopefully will be on the ball.

It's not like you guys don't make statements about this or that all the
time.  And it's not like keeping an eye on cryptanalysis news is
something you really don't do or really ought not have to do.  We
engineer cryptographic protocols here.

Why is all this not obvious?  I don't get how this is asking ADs to do
that much more work than they are doing now.  When something bad
happens, ETOOBUSY is not really an appropriate answer.

(Don't make me browbeat you into this even more.  That's no fun.  Submit already!  :)

Nico
--

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 2 Jun 2015 17:01:27 -0400

Hello,

I agree with Stephen in that we would need more help, how about...

> >>>  - someone notices such a paper

That someone starts a discussion on SAAG/CFRG to get consensus on next
steps.

>>>  - they open a ticket in the Datatracker requiring IAB and/or IESG

The list builds sample text in a draft or for a statement

> work, and this one won't be:-)

This is tough, but delegation would be key and capable volunteers are
necessary.

> I figure tracking is necessary, but far from sufficient for

Agreed, we need more help on leg work, there aren't enough hours in the day
unfortunately for ADs.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Jun 2015 22:06:31 +0100

> (Don't make me browbeat you into this even more.  That's no fun.

Yeah, sure. Maybe later, like when I'm done being an AD:-)

More chat about this would be good though. Would anyone be
willing to document a concrete proposal with enough detail
so folks could shoot it down? A wiki page or git repo that
folks could edit might be a fine start. Shouldn't take more
than a few paragraphs to start.

(And yes, anyone == Nico is fine:-)

S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2015 16:10:18 -0500

> >>>  - they open a ticket in the Datatracker requiring IAB and/or IESG

SAAG is fine, but we need something we can track.

> The list builds sample text in a draft or for a statement

Sure.

> This is tough, but delegation would be key and capable volunteers are

Exactly.  I want an AD to be on the hook for doing that which only an AD
can really do: make sure that someone's looking at this and obtaining
and/or providing advice to I*.

> Agreed, we need more help on leg work, there aren't enough hours in the day

Indeed, so other things may get displaced by more pressing new things.
Tough, too bad, c'est la vie, them's the breaks, ...

But at least you get to delegate.  Ask SAAG/secdir/CFRG, random experts
who are willing to provide advice free of charge (they will materialize,
since plenty of vendors are effectively providing such experts to the
IETF and IRTF as it is, and we are more security-conscious today).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2015 16:11:15 -0500

> (And yes, anyone == Nico is fine:-)

Sure, I'll whip up a skeleton I-D and put it on one of the git*s.

---

From: Russ Housley <[email-masked]>
Date: Tue, 2 Jun 2015 17:14:07 -0400

> things to different people.  I don't think there's a way to definitively state

Thanks Peter.  Is this better?

   It takes a long time to specify, implement, and deploy a replacement
   algorithm or suite.  For this reason, the transition process needs to
   begin when practically exploitable flaws become known, which is
   expected to be well before it becomes available in attacker toolkits.

Russ

---

From: ianG <[email-masked]>
Date: Tue, 02 Jun 2015 23:05:27 +0100

> there's a bit of skilled interpretation required here.

A whole lot of skilled interpretation, and unfortunately the more skill 
the more over-reaction.  In cryptography world, a cipher can be called 
broken if it's lost 2 bits of strength, which is no way broken to the 
user world.

Also, if you start monitoring, you also create a flag to capture. 
Crypanalysts's careers are made or unmade by the success of their 
papers, they are incentivised to get a red flag listed at IETF's 
monitoring service as with any other.

> the IETF from time to time?

So, several institutions present views on this.

NIST has a list, as do others.  About 5 years back, NIST famously 
started recommending that everyone shift to RSA 2048 minimum. 
Unfortunately (imho) its advice wasn't entirely appropriate because NIST 
has a different threat model to most of the rest of the world, by its 
charter.  To some people it was no odds, to others it was an 
embuggerance.  There is a danger in a powerful voice over-reacting, as 
much as under-reacting and wrong-reacting.

When the Wang presentation on MD5 hit in 2004, everyone knew we were in 
trouble.  I remember it because every cryptographer was talking about 
it, all of a sudden, within hours of the talk.  At that time there was a 
feeling that SHA1 would fall imminently, and indeed SHA0 did fall fairly 
shortly.  But SHA1 is still going strong...

On the other hand people have been recommending against RC4 for the 
longest time, and MD5 should have been replaced from 1996 onwards.

What comes out of this is that one institution isn't that reliable.  A 
committee isn't that useful either.  Simple signals don't work well.  A 
single person can say what the single person knows, or can also be 
asleep.  In economics we talk about the value of the buck as a reliable 
signal - in this context, the only thing that matters is whether someone 
lost dollars to theft but so far crypto itself hasn't given us that 
information in abundance.

The industry as a group does however seem to have some sense of the 
wisdom of crowds.  How to capture that?

How about taking a straw poll at each IETF meeting?  Put up a huge chart 
with algorithms down the left hand axis, and ratings across the top 
horizontal axis.  Say, from 1="might as well email it to the NSA" all 
the way up to 10="exceeds power of sun."

Then, hand a bunch of sticky dots to the various security groups and ask 
everyone to stick on their dots.  At the end of the event count them up 
and display the results.  It might not say much the first time, but if 
we see a downtrend over 3 meetings, that might indicate it's time to 
raise the red flag.  It's also a soft indicator, if something averages 
at a 7 that says something whereas a 4 says something else, all in 
relativity.

In a sense we want to record a hum over each cipher, but in a way that 
brings in a large choir over a longer time.

iang

---

From: Watson Ladd <[email-masked]>
Date: Tue, 2 Jun 2015 16:26:19 -0700

> things to different people.  I don't think there's a way to definitively state

How does delaying replacement improve security? Can you point to
ciphers we would have replaced where that replacement would not have
been a good idea? Can you point to flaws in AES that merit
replacement? I don't see how the change being proposed makes things
better. If anything it enables the sort of stuff in the TLS WG where
people argue against changes on the basis that the flaws don't really
exist, even after live demos.

How about "Replacement of an algorithm takes time. However, it is
usually clear that replacement will be necessary long before
exploitation techniques advance enough to produce reliable exploits.
Algorithms that fail to meet the desired security goals, or where
continued advance of computing power will weaken security, should be
replaced ahead of time. As adversaries can record encrypted data and
decrypt it later, it's more critical for encryption algorithms to be
secure then authentication algorithms".

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2015 18:31:55 -0500

> How does delaying replacement improve security? Can you point to

If it led to a surfeit of MTIs, or very fast thrashing of MTIs...
Though arguably the latter would be good: we'd get to practice alg.
agility, so we could make fair predictions about future costs of, and
timelines for, replacement.

> secure then authentication algorithms".

"...it's more critical for encryption and key exchange algorithms..."

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Jun 2015 16:34:54 -0700

On Jun 2, 2015, at 4:26 PM, Watson Ladd <[email-masked]> wrote:
> How does delaying replacement improve security?

It does not improve cryptographic security, but it can improve operational security.

For encryption algorithms, a sender using a new algorithm before the receiver is able to use it means that encryption will not be set up (for interactive protocols) or the receiver will not be able to read the message (for store-and-forward protocols). The receiver might need to get the message, so they fall back to trying to get it unencrypted.

For a signing algorithms, replacing the algorithm when verifiers don't yet have the new algorithm means that they will receive messages that they cannot verify that they would have been able to verify yesterday. So, now they don't know if the message really is signed.

In other words, delaying replacement the "right" amount of time improves security. However, determining "right" is impossible when a community contains activists, followers-along, and feet draggers.

--Paul Hoffman

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Jun 2015 08:27:48 +0000

Russ Housley <[email-masked]> writes:

>Is this better?

Definitely.  This then leaves the problem of determining what constitutes a
"practically exploitable flaw", for which until now there didn't seem to be
any obvious solution, until I saw iang's suggestion.  His whole email is worth
reading, but I'll excerpt one bit from the end:

  How about taking a straw poll at each IETF meeting?  Put up a huge chart
  with algorithms down the left hand axis, and ratings across the top
  horizontal axis.  Say, from 1="might as well email it to the NSA" all the
  way up to 10="exceeds power of sun." Then, hand a bunch of sticky dots to
  the various security groups and ask everyone to stick on their dots.  At the
  end of the event count them up and display the results.

The only change I'd make is to do it via the mailing list(s), since only a
particular subset of people go to IETF meetings.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Jun 2015 08:32:57 +0000

Watson Ladd <[email-masked]> writes:

>Can you point to flaws in AES that merit replacement?

That wasn't what the original text said, it simply said "flaws" (not "flaws
that merit replacement").  See the subsequent discussion about possible
methods to distinguish "flaws" from "flaws that merit replacement".  In
particular for:

  it is usually clear that replacement will be necessary long before
  exploitation techniques advance enough to produce reliable exploits.

it is only occasionally clear, and very often the topic of endless debate,
whether replacement will be necessary.  That's why I found iang's suggestion
on a way forward interesting.

Peter.

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Wed, 3 Jun 2015 10:35:57 +0200

> On 03 Jun 2015, at 10:27, Peter Gutmann <[email-masked]> wrote:
> 

And perhaps have this prefixed by a smaller team taking input of the various regional and annual 'Algorithms, Key Sizes and Parameters Report
’s* report as a ‘minimal’ baseline.

Dw.

*: e.g. https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-size-and-parameters-report-2014, the NIST reccomendations, the BSI ones, etc. Ending up with something perhaps akin to an updated version of:

	http://www.keylength.com/en/4/

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Jun 2015 08:38:33 +0000

Dirk-Willem van Gulik <[email-masked]> writes:

>And perhaps have this prefixed by a smaller team taking input of the various
>regional and annual 'Algorithms, Key Sizes and Parameters Report ’s* report as
>a ‘minimal’ baseline.

Uhh, no.  Ideally we'd want something based on real-world experience (which is
what iang's straw poll is meant to capture), not just numerology.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Jun 2015 13:51:25 +0300

> On Jun 3, 2015, at 1:05 AM, ianG <[email-masked]> wrote:
> 
> 
> The industry as a group does however seem to have some sense of the wisdom of crowds.  How to capture that?

The industry as a group kept using RC4 years after it was clear that this was not a good idea. The industry as a group (not every vendor, but some) kept using MD5 for signing certificates as late as 2009.

> How about taking a straw poll at each IETF meeting?  Put up a huge chart with algorithms down the left hand axis, and ratings across the top horizontal axis.  Say, from 1="might as well email it to the NSA" all the way up to 10="exceeds power of sun."
> 
> Then, hand a bunch of sticky dots to the various security groups and ask everyone to stick on their dots.  At the end of the event count them up and display the results.  It might not say much the first time, but if we see a downtrend over 3 meetings, that might indicate it's time to raise the red flag.  It's also a soft indicator, if something averages at a 7 that says something whereas a 4 says something else, all in relativity.
> 
> In a sense we want to record a hum over each cipher, but in a way that brings in a large choir over a longer time.

Or we can find volunteers to keep Dave’s and Sean’s effort current, perhaps with a bit more advice such as “good”, “bad”, “try to migrate away”:
https://tools.ietf.org/html/draft-irtf-cfrg-cipher-catalog

Yoav

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Jun 2015 10:21:59 -0400

Trying to pull the divergent ideas together in the text, I suggest:

   It takes a long time to specify, implement, and deploy a replacement
   algorithm or suite.  For this reason, the transition process needs to
   begin when practically exploitable flaws become known.  Replacement
   will necessarily take a long time, but it can be accomplished before
   exploitation techniques become widely available exploits.

Russ

---

From: Eliot Lear <[email-masked]>
Date: Wed, 03 Jun 2015 16:36:58 +0200

Hi Russ,

I must admit I don't have the context of the whole section in my head,
and so this might be a queue for a new draft rev ;-)  Please see below.

>    exploitation techniques become widely available exploits.

Editorially speaking I think you're saying the same thing in the first
sentence and first part of the last sentence.  Strictly speaking the
last statement may not be true, if not qualified.  Consider the case of
a long-lived device with no update path (like many cell phones from
yesteryear that still function today).  My suggestion is to either drop
the last sentence or run with something like the following:

   It takes a long time to specify, implement, and deploy a replacement
   algorithm or suite.  For this reason, the transition process needs to
   begin when practically exploitable flaws become known.  Proper and
   timely update processes on long-lived devices, therefore, are
   particularly critical.

This leads to another question (sorry).  Such update processes on
certain classes of devices are going to slowed by certification regimes
(think health and safety or other devices that can harm people).  Again,
the current draft isn't directly in my head, but do we want to say
something about weighing the value of such certification against risk
posed by the algorithm vulnerability?

Eliot

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Jun 2015 07:42:12 -0700

> particular subset of people go to IETF meetings.

Peter, you rarely go to IETF meetings, but you are on mailing lists here. Do you really think that the majority of people who would participate in such a poll who have any relevant input? That is, that they read any of the crypto research? As much as some folks here would love the IETF to become the Crypto Police, I would only want the ones who both read technical articles (not news reports) and can quickly and correctly differentiate CCM from CBC, and Curve25519 from Goldilocks, from voting in the poll. Otherwise, we might as well just do darts.

Yes, your proposal would simplify things. It will also make enough wrong statements to make operational security worse, not better, possibly in the first year.

--Paul Hoffman

---

From: Eliot Lear <[email-masked]>
Date: Wed, 03 Jun 2015 16:52:56 +0200

Argh.

> and so this might be a queue for a new draft rev ;-)  Please see below.

s/queue/cue/.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 3 Jun 2015 08:03:58 -0700

On Tue, Jun 2, 2015 at 4:34 PM, Paul Hoffman <[email-masked]> wrote:
> For encryption algorithms, a sender using a new algorithm before the
receiver is able to use it means that encryption will not be set up (for
interactive protocols) or the receiver will not be able to read the message
(for store-and-forward protocols). The receiver might need to get the
message, so they fall back to trying to get it unencrypted.
>
> For a signing algorithms, replacing the algorithm when verifiers don't
yet have the new algorithm means that they will receive messages that they
cannot verify that they would have been able to verify yesterday. So, now
they don't know if the message really is signed.
>
> In other words, delaying replacement the "right" amount of time improves
security. However, determining "right" is impossible when a community
contains activists, followers-along, and feet draggers.

Huh? I'm not saying that we shorten the time between when we roll out the
new version and stop the old version. Rather, I'm saying that delaying the
start of the transition is almost never a good idea. Of course, when it
comes to RC4 you can turn off RC4 right now and nothing bad will happen:
the MTI algorithm for all TLS is not RC4.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 3 Jun 2015 08:41:32 -0700

> what iang's straw poll is meant to capture), not just numerology.

Could you provide an example of when it is unclear when to depreciate
today, or say from 5 years ago?

Could you provide an example of recommendations based on "numerology", and
explain why the analysis is wrong?

Conversely, given that most people exploiting cryptography don't publicize
the fact, how does real-world experience help?

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Jun 2015 12:30:52 -0400

Eliot:

> and so this might be a queue for a new draft rev ;-)

I was hoping to sort out this paragraph before turning my working buffer into the next Internet-Draft.

> posed by the algorithm vulnerability?

This leads to a somewhat different take on the paragraph.  Maybe it gets us closer.

   Mechanisms for timely update of devices are needed to deploy a
   replacement algorithm or suite.  It takes a long time to specify,
   implement, and deploy a replacement, therefore the transition process
   needs to begin when practically exploitable flaws become known.  The
   update processes on some devices involve certification, which further
   increases the time to deploy a replacement.  For example, devices
   that are part of health or safety systems often require certification
   before deployment.  Prompt action is needed if a replacement has any
   hope of being deployed before exploitation techniques become widely
   available exploits.

Russ

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Jun 2015 12:01:46 -0500

On Wed, Jun 03, 2015 at 07:42:12AM -0700, Paul Hoffman wrote:
> Peter, you rarely go to IETF meetings, but you are on mailing lists
> here. Do you really think that the majority of people who would
> participate in such a poll who have any relevant input? That is, that
> they read any of the crypto research? As much as some folks here would
> love the IETF to become the Crypto Police, I would only want the ones
> who both read technical articles (not news reports) and can quickly
> and correctly differentiate CCM from CBC, and Curve25519 from
> Goldilocks, from voting in the poll. Otherwise, we might as well just
> do darts.

IETF consensus finding already accounts for this sort of thing.  It's
not about numbers of votes, and we do get to weigh input from
noise-makers and experts according to their expertise and their
arguments' merits.

We don't need a big board, but we do need a range of estimates of
realistic cryptanalysis improvements (this being speculation) and
Moore's law progress (this being less speculative), which is where most
of the error range in the estimated remaining useful lifetime of any
cryptographic algorithm will come from.  Consensus as to work factors
required to break an algorithm given current cryptanalysis will, I
assume, be easy to reach (though there may be errors in the
cryptanalysis).

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Jun 2015 19:18:05 +0000

For example, devices that are part of health or safety systems often require
  certification before deployment.

I'd perhaps add as a second example:

  Embedded/SCADA systems, which often have upgrade cycles stretching over many
  years, have similar issues.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Jun 2015 19:24:32 +0000

Paul Hoffman <[email-masked]> writes:

>Yes, your proposal would simplify things. It will also make enough wrong
>statements to make operational security worse, not better, possibly in the
>first year.

This isn't an irrevocable, binding vote, merely a poll.  At the moment we have
no data on this, just a lot of opinions.  If we ran a poll or two, we could
see... well, I have no idea what we'd see or we wouldn't need a poll for it.
The point is we would at that point at least have some data.  Since it's just
an opinion poll, there's nothing to prevent us from then saying "well, that
didn't work, all we got was noise" (or, more hopefully, "this gives us some
useful guidance").

(Oh, and it's iang's idea, not mine, he should get the credit for it).

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 4 Jun 2015 09:31:36 -0700

> didn't work, all we got was noise" (or, more hopefully, "this gives us some

If you take a bunch of blind people, put them together, and take a poll,
they don't suddenly develop sight. We're still assuming that the problem is
that we didn't "know" that MtE in TLS was insecure. I think it's pretty
clear that a good number of people were aware: after all, you wrote the
draft that was ultimately adopted to solve the problem, several years
afterwards. Would taking a poll have actually helped that situation?

It may have helped with RC4.

---

From: Russ Housley <[email-masked]>
Date: Thu, 4 Jun 2015 18:26:36 -0400

Based on the discussion on this thread, I have made many updates.  A new version (-05) was just posted:
	https://www.ietf.org/internet-drafts/draft-iab-crypto-alg-agility-05.txt

The diff from previous version is here:
	https://www.ietf.org/rfcdiff?url2=draft-iab-crypto-alg-agility-05

Thanks for all of the helpful discussion.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Jun 2015 11:22:47 +0100

Hiya,

Now that I'm back from me holliers, I had a read of this and I
think it captures all the main points made in the list discussion.
But I might have missed something, (I see 183 messages on this
draft in my local archive of the saag list;-) so if there's something
from the discussion that you figure wasn't captured and that ought
go into the draft, can you point that out in the next few days?

There were places the discussion ranged beyond what ought go into
this draft - to be clear, I'm not asking that we re-do all that
discussion so please try limit this to stuff that's missing from, or
badly wrong in, -05.

There's clearly another rev needed, as is indicated in the document
itself, but it'd be good if that were basically editorial, e.g.
re-structuring to make it flow better. My hope is that the -06
version could be ready for IETF LC if nothing major shows up now
as having been missed in -05.

Thanks,
S.