Subject: [saag] SHA-3 Upgrade group

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Apr 2011 15:58:25 +0200

There was a proposal (possibly in a bar, possibly at SECDIR) that there be a
single WG to look at upgrading protocols to use SHA3 across the board.

This group would not be allowed to do anything other than add algorithms, it
would not be allowed to 'fix' things in the protocol.

I see the following issues:

1) Drop in replacement of SHA3 for SHA1 should be straightforward

2) Replacement of RSA-with-SHA1 for RSA-with-SHA3 is a bit more involved. We
have to consider things like packing etc. If we are going to make SHA3
consistent across the board, we should probably decide on a consistent
approach to using RSA. Different protocols have different approaches.

3) Replacement of HMAC-SHA1 is also required and this is likely to be
supported through a native MAC mode in SHA3 which may well be the most
important security benefit that is achieved.

4) In the case that there is a parameterized hash mode, in particular a
random hash, we would have to decide whether or not to use it. I would
really like to be able to use a randomized hash in certificates, I see a lot
of value to doing that there. I am less interested in using randomized
hashes in other circumstances.

5) If we are going to be making SHA3 consistent across the board, would it
make sense to also consider adding ECC support with a consistent curve
consistent across the board?

6)  While the group should not be writing features, it would be useful for
it to capture requirements that could then be fed into relevant WGs, in
particular I see a need to interact here with PKIX, TLS and DANE.

6a) In some cases we have protocols that cannot be upgraded without creating
a deployment deadlock. We may well need to think about tools and techniques
that would simplify the process of deployment.

For example, a common file format for storing multi-certs so that a CA can
throw a 'bag' of certificates (RSA-SHA1, RSA-SHA3, RSA-SHA3) at a customer
and the customer's server would then select the one that the client asks
for. This is going to have to integrate with TLS.

6b) Adding stronger cipher suites does not make anyone more secure. You only
improve security if you eliminate insecure suites. Thus the question of
security policy has to be addressed. How does a server tell a client what
its minimum level of security is in a manner that is not subject to a
downgrade attack? (It is easy for the client as they can simply abort the
connection if the level of security is not high enough.)

At the end of the process, I would like to see a single RFC emerge,
preferably one that has a 'memorable' number (RFC 6666 is coming up). And I
would like it to be possible for an implementation to tell users that it has
the modern crypto set by simply referencing that RFC.
-- 
Website: http://hallambaker.com/

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 06 Apr 2011 02:19:33 +1200

> important security benefit that is achieved.

Uhh, given that there's nothing wrong with HMAC-SHA1, I think this needs to be
rephrased a bit.  In particular the security benefit to replacing HMAC-SHA1
with SHA3-MAC (or whatever it'll be called) is precisely zero.  I'm guessing
the benefit of switching is that you'll only need to provide one hash
algorithm, SHA-3, for signing and integrity-protection.  However, whatever
text is produced should point out that this is a convenience switch, not a
security upgrade.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 05 Apr 2011 15:39:51 +0100

Right - thanks for starting this. We had meant to try bring
it up at the saag session but didn't have time. It was
discussed briefly at the secdir lunch.

We do plan to discuss it at saag next time, but progress on
this list in the meantime would be good. If this gets to be
a lot of mail we can setup a new list.

The basic idea is as Phill said - to try to define code
points, ciphersuites for the loads of things that might
want sha3 without modifying protocols, and to do so in
a way that removes the temptation to meddle with protocols
that may otherwise arise:-)

Some questions I see are:

- good/bad idea generally?
- not modifying protocols means not changing the mandatory
  to implement algorithms, so each time we wanted to move
  to actually using a sha3 thing, that'd require more work
  in another WG or as an AD sponsored draft - does that
  make sense?
- scoping - should we try identify protocols that will need new
  codepoints/ciphersuites now and just charter something for those
  or should that be the first task of such a group to be
  followed by rechartering?
- when to start? we might be able to get started before
  the competition is done if we knew the sizes etc. earlier,
  would that be worthwhile? (I believe we won't know the
  winner for about a year or so.)
- how to deal with this where there is an existing WG (e.g.
  TLS, kerberos) - would it help to offload some of the work
  to such a group, or is it better left just to those WGs?
  if the putative group were to take on work in e.g. TLS
  then I assume that anything relevant would have to be
  last called in both the new group and TLS for example.
- who'd help? (it'll be kind of boring I expect:-) NIST
  might be able to help (Tim said:-) but we'd need people
  who know the actual protocols as well of course
- I'm sure there's more we've not thought of yet.

FWIW, I don't see the output being one RFC here. I can't
see that one spec would be that useful given the range of
protocols that might want to make use of sha3.

Stephen.

On 05/04/11 14:58, Phillip Hallam-Baker wrote:
> There was a proposal (possibly in a bar, possibly at SECDIR) that there
> be a single WG to look at upgrading protocols to use SHA3 across the board. 
> 
> This group would not be allowed to do anything other than add
> algorithms, it would not be allowed to 'fix' things in the protocol. 
> 
> 2) Replacement of RSA-with-SHA1 for RSA-with-SHA3 is a bit more
> involved. We have to consider things like packing etc. If we are going
> to make SHA3 consistent across the board, we should probably decide on a
> consistent approach to using RSA. Different protocols have different
> approaches.
> 
> really like to be able to use a randomized hash in certificates, I see a
> lot of value to doing that there. I am less interested in using
> randomized hashes in other circumstances.
> 
> 5) If we are going to be making SHA3 consistent across the board, would
> it make sense to also consider adding ECC support with a consistent
> curve consistent across the board?
> 
> 6)  While the group should not be writing features, it would be useful
> for it to capture requirements that could then be fed into relevant WGs,
> in particular I see a need to interact here with PKIX, TLS and DANE.
> 
> 6a) In some cases we have protocols that cannot be upgraded without
> creating a deployment deadlock. We may well need to think about tools
> and techniques that would simplify the process of deployment. 
> 
> For example, a common file format for storing multi-certs so that a CA
> can throw a 'bag' of certificates (RSA-SHA1, RSA-SHA3, RSA-SHA3) at a
> customer and the customer's server would then select the one that the
> client asks for. This is going to have to integrate with TLS.
> 
> 6b) Adding stronger cipher suites does not make anyone more secure. You
> only improve security if you eliminate insecure suites. Thus the
> question of security policy has to be addressed. How does a server tell
> a client what its minimum level of security is in a manner that is not
> subject to a downgrade attack? (It is easy for the client as they can
> simply abort the connection if the level of security is not high enough.)
> 
> 
> preferably one that has a 'memorable' number (RFC 6666 is coming up).
> And I would like it to be possible for an implementation to tell users
> that it has the modern crypto set by simply referencing that RFC. 
> -- 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Apr 2011 10:57:54 -0500

> consistent across the board?

This strikes me as potentially difficult to do without "fixing" the
protocol, in some cases.

> connection if the level of security is not high enough.)

Phase out of older algorithms should be the province of each WG.

> the modern crypto set by simply referencing that RFC.

I am not sure that this is a good idea.  It's workable, but review of
each little protocol fix could delay the whole thing.  I think I'd
rather have a per-protocol RFC and one big FYI that explains what was
done and lists all those little RFCs.  Or, I'd be OK with
re-publishing all those little RFCs in one big one (but then you have
to watch out about where errata go, or obsolete the little ones with
the big one).

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Apr 2011 09:09:03 -0700

>  winner for about a year or so.)

Tim Polk can correct me if I'm wrong, but since the third hash conference will be at the end of March next year, it seems unlikely that NIST will decide the winner a month later. In fact, it seems unlikely that NIST will decide how many code points will be needed that soon after the conference, either.

If we aren't going to know for maybe 18 months whether there will be just one code point, or many code points, for 256-bit strength, it seems premature to start saying what will be needed in each security protocol. It is fine to collect data now on which protocols have hashes as protocol elements, but doing any more than that before we are sure what the code point needs will be is likely to end up making developers' lives worse for no good reason.

And we still don't have any statement from NIST about what SHA3 is supposed to be used for...

--Paul Hoffman

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Apr 2011 13:34:12 -0400

When Steve Bellovin and I were the SEC ADs, we tried to start a project for the transition of SHA-1 to SHA-256.  We tried to get this started well in advance of the deadline for the transition.  We thought it would take 5 years to make the transition AFTER the protocol specifications were done.  We are still not there across the board.

In my opinion there is a real reason to transition from SHA-1 to something stronger.  I fear that a focus on SHA3 at this point in time will further reduce the energy needed to get SHA-256 deployed in all of te places where it is needed.  Until SHA3 is selected, it is impossible to determine if it offers any benefits over SHA-256 in our protocols.

Russ

On Apr 5, 2011, at 9:58 AM, Phillip Hallam-Baker wrote:

> There was a proposal (possibly in a bar, possibly at SECDIR) that there be a single WG to look at upgrading protocols to use SHA3 across the board. 
> 
> This group would not be allowed to do anything other than add algorithms, it would not be allowed to 'fix' things in the protocol. 
> 
> 2) Replacement of RSA-with-SHA1 for RSA-with-SHA3 is a bit more involved. We have to consider things like packing etc. If we are going to make SHA3 consistent across the board, we should probably decide on a consistent approach to using RSA. Different protocols have different approaches.
> 
> 3) Replacement of HMAC-SHA1 is also required and this is likely to be supported through a native MAC mode in SHA3 which may well be the most important security benefit that is achieved.
> 
> 4) In the case that there is a parameterized hash mode, in particular a random hash, we would have to decide whether or not to use it. I would really like to be able to use a randomized hash in certificates, I see a lot of value to doing that there. I am less interested in using randomized hashes in other circumstances.
> 
> 5) If we are going to be making SHA3 consistent across the board, would it make sense to also consider adding ECC support with a consistent curve consistent across the board?
> 
> 6)  While the group should not be writing features, it would be useful for it to capture requirements that could then be fed into relevant WGs, in particular I see a need to interact here with PKIX, TLS and DANE.
> 
> 6a) In some cases we have protocols that cannot be upgraded without creating a deployment deadlock. We may well need to think about tools and techniques that would simplify the process of deployment. 
> 
> For example, a common file format for storing multi-certs so that a CA can throw a 'bag' of certificates (RSA-SHA1, RSA-SHA3, RSA-SHA3) at a customer and the customer's server would then select the one that the client asks for. This is going to have to integrate with TLS.
> 
> 6b) Adding stronger cipher suites does not make anyone more secure. You only improve security if you eliminate insecure suites. Thus the question of security policy has to be addressed. How does a server tell a client what its minimum level of security is in a manner that is not subject to a downgrade attack? (It is easy for the client as they can simply abort the connection if the level of security is not high enough.)
> 
> 
> At the end of the process, I would like to see a single RFC emerge, preferably one that has a 'memorable' number (RFC 6666 is coming up). And I would like it to be possible for an implementation to tell users that it has the modern crypto set by simply referencing that RFC. 
> --

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Apr 2011 19:44:28 +0200

> text is produced should point out that this is a convenience switch, not a

I would hope that the HMAC mode of SHA3 is going to be faster.

But more generally, the objective here is to remove SHA1 from service
because we only get better security when that happens.

In order to audit that, I want to be able to see that there is no SHA1
loaded which may well impact implementations of HMAC-SHA1.

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Apr 2011 12:50:13 -0500

[Resend.  Forgot to reply all.]

On Tue, Apr 5, 2011 at 12:34 PM, Russ Housley <[email-masked]> wrote:
> In my opinion there is a real reason to transition from SHA-1 to something
> stronger.  I fear that a focus on SHA3 at this point in time will further
> reduce the energy needed to get SHA-256 deployed in all of te places where
> it is needed.  Until SHA3 is selected, it is impossible to determine if it
> offers any benefits over SHA-256 in our protocols.

+1

Also, to avoid having to do some of this twice, I'd recommend leaving
HMAC-SHA-1 uses alone.

The set of security-relevant uses of MD5 and SHA-1 outside HMAC and
outside public key signatures are relatively few, which makes an
upgrade to SHA-256 a project with a good chance of proceeding quickly.

Perhaps then we need these projects:

 - replace non-HMAC-SHA-1, non-RSA uses of MD5 and SHA-1 with SHA-256;
 - replace RSA uses of MD5 and SHA-1 with SHA-256 (and/or randomized
hashes?  but I suspect that non-ramdomized SHA-256 will be simpler);
 - replace all hashes with SHA-3 where SHA-3 makes it highly desirable.

The last one wouldn't start anytime soon.  The first two could start right now.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Apr 2011 12:51:23 -0500

> loaded which may well impact implementations of HMAC-SHA1.

We will not likely lose all the non-security-relevant uses of SHA-1
for a long time, nor many of the security relevant uses for that
matter (think of git, for example, which is not even an Internet
protocol).  By "long time" I mean "on the order of a decade".  Which
means that checking for the absence of SHA-1 code on a system will
only make a poor audit tool.  And if you'd audit _uses_ of SHA-1,
well, then you might as well put "HMAC-SHA-1" in the "OK" column.

In general I prefer auditing that isn't so simplistic that it causes
make-work for admins, or fails outright.

Nico
--

---

From: Bryan Geraghty <[email-masked]>
Date: Tue, 5 Apr 2011 13:02:42 -0500

> it is needed.

This is a very good point.

> Until SHA3 is selected, it is impossible to determine if it offers any
> benefits over SHA-256 in our protocols.
>

Due to huge amounts of cryptanalysis and benchmarking, we know that all of
the SHA-3 finalists are out-performing SHA-2 variants in every aspect. I
believe it is pretty clear that there is a benefit. From the results of my
own benchmarking, fighting the urge to implement some of the finalists has
been very hard.

-- 
Bryan C. Geraghty
[email-masked]
Cell: (702) 715-4574

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Apr 2011 20:11:14 +0200

> The last one wouldn't start anytime soon.  The first two could start right

Its the non-security use cases that I expect to result in issues.

One big problem is working out whether something is in fact a non-security
use case because that can frequently take rather longer to work out than
fixing the protocol would.

Is the git case really non security? I have not seen the protocol but I bet
that if a group of college students were given the task of finding an attack
that some of them would surprise you. Sounds to me like the digest is being
used to verify cache integrity. I could certainly see attacks that I could
use there. Isn't git a source code manager? You really think thats not
security related?

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Apr 2011 14:59:04 -0500

> fixing the protocol would.

Indeed.

> Is the git case really non security? I have not seen the protocol but I bet

I definitely meant that git is a security-related case because if you
could make useful SHA-1 collisions against non-chosen plaintexts then
you might be able to surreptitiously make undetectable changes to git
repositories or similarly fool clients [that don't use HTTPS or SSHv2
for transport].

> use there. Isn't git a source code manager? You really think thats not

git is a Merkle tree of changesets.

> You really think thats not
> security related?

What I wrote was "...nor many of the security relevant uses for that
matter (think of git, for example...".

Nico
--

---

From: Bryan Geraghty <[email-masked]>
Date: Tue, 5 Apr 2011 15:02:39 -0500

On Tue, Apr 5, 2011 at 1:22 PM, Robert Moskowitz <[email-masked]>wrote:

>  Given your testing, can you comment on any which will work well on highly
> constrained sensors?  These sensor vendors cry about anything that adds more
> code or eats up more cpu and battery.  They DO have AES-CCM in hardware,
> Any testing and insights you have will help me in working with people in
> 6lowpan, core, and 802.15.4.
>
> Thanks
>

Actually, this is one of the major areas that is being tested by the
contest. The details of the round 2 candidates was published in February:

http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/documents/Round2_Report_NISTIR_7764.pdf

There is so much information available about each algorithm, that it
wouldn't make much sense for me to go into detail here. Since each algorithm
has a different combination of state size/cpu cycles/security
margin/parallelization/raw speed, the person implementing the algorithm
really needs to evaluate what would work best in their situation.

For my purposes, I like Skein but it doesn't have the best performance
characteristics in a constrained environment and it has a large internal
state. On the other hand, it can do MAC internally, which speeds up the
implementation dramatically, and it was designed to be a SHA drop-in
replacement.

The best place for info on the algorithms is:

http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo

Each hash project has their own website where they collect the benchmarks of
each implementation. They are each listed at that site.

Hope this helps,
Bryan

-- 
Bryan C. Geraghty
[email-masked]
Cell: (702) 715-4574

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Apr 2011 15:08:28 -0500

> own benchmarking, fighting the urge to implement some of the finalists has

Performance considerations are very tempting.  But can we wait?
(Arguably we can, given how long we've waited so far.)

Nico
--

---

From: Bryan Geraghty <[email-masked]>
Date: Tue, 5 Apr 2011 15:13:45 -0500

> (Arguably we can, given how long we've waited so far.)

Agreed. The process takes so long for a good reason. I was just pointing out
that there certainly is a benefit in migrating from the SHA-2 family to
SHA-3 when it's time.

Bryan

-- 
Bryan C. Geraghty
[email-masked]
Cell: (702) 715-4574

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Apr 2011 21:16:10 +0000

> (Arguably we can, given how long we've waited so far.)

I think Russ just said that from an IETF point of view - no we cannot wait,
WGs need to have a deployment plan for SHA256 ASAP and the move to SHA3
cannot be allowed as an excuse for further procrastination.

That said, I think it probably helps if the expectation is set that the
future upgrade to SHA3 is not going to be a reason to keep open an otherwise
finished working group. Since all the current WGs have already considered
how to deploy SHA256, there is really no reason that SHA3 should require
more than a new code point and some test vectors.... That said, I bet that
it is going to turn out otherwise!

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 06 Apr 2011 17:09:40 +1200

Phillip Hallam-Baker <[email-masked]> writes:

>Since all the current WGs have already considered how to deploy SHA256, there
>is really no reason that SHA3 should require more than a new code point and
>some test vectors.... That said, I bet that it is going to turn out otherwise!

+1.  Having a SHA3-upgrade WG would solve the killer problem of crypto geeks
deciding they're going to reinvent half the protocol they're dealing with as a
side-effect of adding a new algorithm (oh yeah, and we can change the key wrap
mechanism, and mandate new key sizes, and add some more message subtypes, and
...).  So the single biggest advantage of having a dedicated SHA3 upgrade WG
would be that it would ensure that that's the only thing that changes in the
protocol.  As you say, we need a new algorithm ID and some test vectors, not
an excuse for every WG to start bikeshedding every security protocol ever
invented.

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Apr 2011 05:34:25 -0700

> an excuse for every WG to start bikeshedding every security protocol ever

Note, however, if NIST defines SHA-3 with tunable parameters (something that they have discussed in the hash workshops), then either most protocols will need to be changed to handle parameters (which none do now) or "someone" is going to have to decide which parameter we mean for "SHA-3 that has 256 bits of effective strength", "SHA-3 that has 384 bits of effective strength" and so on. A WG might be good at that, but the chairs are going to have a hell of a time calling consensus, given that the likely purpose of parameters (if NIST chooses that path) will be speed and register size, and we will have to choose which are more important to us.

--Paul Hoffman

---

From: Bryan Geraghty <[email-masked]>
Date: Wed, 6 Apr 2011 08:20:30 -0500

On Wed, Apr 6, 2011 at 7:34 AM, Paul Hoffman <[email-masked]> wrote:

Note, however, if NIST defines SHA-3 with tunable parameters (something that
> they have discussed in the hash workshops), then either most protocols will
> need to be changed to handle parameters (which none do now) or "someone" is
> going to have to decide which parameter we mean for "SHA-3 that has 256 bits
> of effective strength", "SHA-3 that has 384 bits of effective strength" and
> so on. A WG might be good at that, but the chairs are going to have a hell
> of a time calling consensus, given that the likely purpose of parameters (if
> NIST chooses that path) will be speed and register size, and we will have to
> choose which are more important to us.
>

The fact is, NIST defined an API for the SHA-3 competition which every
contestant had to implement:

http://csrc.nist.gov/groups/ST/hash/documents/SHA3-C-API.pdf

I can't imagine they would have gone through all of that trouble and then
change it when the final algorithm is chosen. This standard API made it
extremely easy for implementers to test all of the functions. And the Hash()
function does have an argument for bit length.

-- 
Bryan C. Geraghty
[email-masked]
Cell: (702) 715-4574

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Apr 2011 13:21:53 +0000

Tunable parameters for performance seems to me to be a bad idea in the
context of IETF protocols.

I want to have consistency across IETF protocols so that they all share a
common set of required algorithms. If the IETF has consistency it will
almost certain that W3C and OASIS will follow the same approach.

The reason I want to see a single WG is that I want to have the discussion
exactly once.

At the moment at least 50% of the arguments I see in WGs are repetition of
arguments I have seen before. And the ones that consume the most time are
the ones that everyone can have an opinion on (what color to paint the
bikeshed).

* Choice of crypto algorithm
* Choice of ECC curves
* REST / SOAP BEEP
* XML feature set
* Format of URI identifiers

These are all issues where we have the argument over and over again and
almost always come to almost but not quite the same decision. I want to have
these arguments once.

I want one digest algorithm with fixed parameters that is used as a drop in
replacement. We have no idea what the deployment scenario is going to be and
so we cannot tune parameters for performance in any case. I do not want to
modify a protocol so as to allow performance tuning either.

On Wed, Apr 6, 2011 at 12:34 PM, Paul Hoffman <[email-masked]> wrote:

> Note, however, if NIST defines SHA-3 with tunable parameters (something
> that they have discussed in the hash workshops), then either most protocols
> will need to be changed to handle parameters (which none do now) or
> "someone" is going to have to decide which parameter we mean for "SHA-3 that
> has 256 bits of effective strength", "SHA-3 that has 384 bits of effective
> strength" and so on. A WG might be good at that, but the chairs are going to
> have a hell of a time calling consensus, given that the likely purpose of
> parameters (if NIST chooses that path) will be speed and register size, and
> we will have to choose which are more important to us.
>
> --Paul Hoffman
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Apr 2011 06:45:17 -0700

On Apr 6, 2011, at 6:20 AM, Bryan Geraghty wrote:

> The fact is, NIST defined an API for the SHA-3 competition which every contestant had to implement:
> 

Correct. And that short document discusses algorithm-specific parameters in section 3.

> I can't imagine they would have gone through all of that trouble and then change it when the final algorithm is chosen.

They don't need to change it: the use of parameters is documented.

> This standard API made it extremely easy for implementers to test all of the functions. And the Hash() function does have an argument for bit length.

True, but irrelevant.

We won't know about turnable parameters until NIST makes its final decision more than a year from now. Many (most?) of us hope that there will be no parameters, but designing changes in protocols based on an assumption like that will cause our work to be more error-prone.

--Paul Hoffman

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 07 Apr 2011 01:56:43 +1200

Phillip Hallam-Baker <[email-masked]> writes:

>arguments I have seen before. And the ones that consume the most time are the
>ones that everyone can have an opinion on (what color to paint the bikeshed).
>
>* Choice of ECC curves

For an example of this, see my recent posting to the TLS WG
(http://permalink.gmane.org/gmane.ietf.tls/8390), the single biggest shopping-
list of problems in TLS 1.2 is caused by ECC, and every single one can be
solved by the same single change which gets rid of the unnecessary flexibility
(and complexity) that's involved.

>[...]

You forgot the ultimate bikeshedding trigger:

* PKI

Peter :-).

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 07 Apr 2011 02:09:54 +1200

Paul Hoffman <[email-masked]> writes:

>need to be changed to handle parameters (which none do now)

NIST can define whatever they want, it doesn't mean anyone has to use it.
Currently we have SHA2-256, SHA2-512, SHA2-384, SHA2-224, SHA2-chipotle, SHA2-
streaky-bacon, SHA2-thousand-island, SHA2-chunky, SHA2-extra-chunky, SHA2-
barbeque, SHA2-salt-and-vinegar, SHA2-balsamic-vinaigrette, SHA2-caesar, SHA2-
organic-sea-salt, and SHA2-barium-enema, but what's mostly implemented in
practice is SHA2-256 and... nope, can't actually recall seeing anything else
in use in practice [0].  Again, referring back to my TLS 1.2 post, if you
simply default to SHA2-256 you can talk to anything that actually does SHA2.
So all we need to do is choose one standard mode with 256 bits of output to
match SHA2-256, and probably another one for SHA2-512.  Just because NIST
hands us a really long coil of rope, doesn't mean we have to use it.

Peter.

[0] OK, I've seen -512 and -384 in obscure, isolated implementations, but I've
    also seen Whirlpool and Tiger and others.  I think I saw SHA-224 on
    display at the Ripley's Odditorium, but it may have been Haval.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Apr 2011 14:35:49 +0000

As I pointed out in the original post, the thing that makes this non trivial
is that may protocols have multiple algorithms specified, some have suites.

Parameters are a non-starter when you have suites. If there is a choice of
parameters and nobody can tell the difference, a standards organization
should pick ONE, not create a mechanism for allowing a choice. The process
of standardization is to limit choices and in particular to eliminate
choices that don't matter or don't matter much.

I would like to see the approach to suites to be that the group picks
exactly one algorithm of a given type and no more than two variations
thereof to support different cipher strength, roughly corresponding to 128
bit and 256 bit work factor (accepting that we can't do 256 bit for RSA)

Even so, we end up with rather a lot of suites since we have 3 public key
building blocks (encryption, signature, key exchange) and 2 approaches
(Finite field + ECC). If we implement all of them at both work factors we
end up with 4 suites which is still more than I would like.

I can see an argument for adding algorithms because they have different
properties (DSA results in more compact signatures than RSA and is thus more
appropriate for DNSSEC than RSA2048). But I cannot see a good argument for
proliferating parameters to chase marginal performance issues.

Unless a performance issue creates a difference of at least an order of
magnitude, it is not worth considering in IETF. That is a justification for
considering ECC, it is not a justification for bikeshedding digest algorithm
parameters.

Given that each set of parameters is going to create different security
properties, I can't see it being very likely that the final choice will have
optional parameters in any case. It makes sense to have parameters during
the selection process as otherwise the competition degenerates into guessing
and gaming what use cases are going to have the most weight in the selection
process.

We have to make choices and so does NIST. And if NIST does not end up making
choices for parameters then we are going to have to.

On Wed, Apr 6, 2011 at 1:56 PM, Peter Gutmann <[email-masked]>wrote:

> the

---

From: Bryan Geraghty <[email-masked]>
Date: Wed, 6 Apr 2011 09:37:27 -0500

On Wed, Apr 6, 2011 at 8:45 AM, Paul Hoffman <[email-masked]> wrote:

Correct. And that short document discusses algorithm-specific parameters in
> section 3.

Yes, but in section 4.1, it says:

This API uses a function called Init() to initialize the hashState
structure. As stated above, the
hashState structure contains the hashbitlen of this particular
instantiation, as well as any
algorithm specific parameters that are needed.

Any algorithm-specific parameters are initialized within the Init() call and
do not need to be known to the implementer. Those  parameters are meant for
extremely specific implementations and the algorithm byte-code will actually
be modified. Those parameters cannot be set at run-time, and therefore, are
not exposed by the API.

If you're talking about the Tunable Security Parameter mentioned in the
selection process, that is a separate concept and we should not confuse the
two. I'm positive that once the final algorithm is chosen, that "tunable"
parameter will become constant (number of rounds, for instance). The
security of the algorithm depends heavily on the configuration of said
parameter and to allow implementers to modify it at-will would be ludicrous.
We've seen what happens when algorithms are implemented with reduced rounds.

> We won't know about turnable parameters until NIST makes its final decision
> more than a year from now. Many (most?) of us hope that there will be no
> parameters, but designing changes in protocols based on an assumption like
> that will cause our work to be more error-prone.
>

I honestly can't see any reasonable place for external parameters that
wouldn't destroy the integrity of the algorithm. But I understand the wisdom
of getting the final word. Perhaps there is a way we can get a final answer
from NIST.

-- 
Bryan C. Geraghty
[email-masked]
Cell: (702) 715-4574

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 07 Apr 2011 03:07:15 +1200

Phillip Hallam-Baker <[email-masked]> writes:

>(Finite field + ECC). If we implement all of them at both work factors we end
>up with 4 suites which is still more than I would like.

Eventually the invisible hand of the market will decide.  From the SSL 
Observatory:

Number of deployed DSA TLS servers with certs \
  chaining to a trusted root: 25
Number "  " ECC  "  "  ": Zero
Number "  " RSA  "  "  ": Millions

So to a good approximation, for SSL/TLS use, there is only one PKC algorithm
and that's RSA.  Furthermore, pretty much everything can do either 3DES
(older) or AES (newer).  So you should be able to communicate with pretty much
anything that talks SSL/TLS with:

  SSL_RSA_WITH_3DES_EDE_CBC_SHA
  TLS_RSA_WITH_AES_128_CBC_SHA

and if you're really keen on PFS (which 99.99% of your users don't even know
exists, but anyway):

  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  TLS_DHE_RSA_WITH_AES_128_CBC_SHA

and finally if you can find anything that does TLS 1.2 you could throw in two
SHA-2 suites as well.  In practice though, for anyone but crypto-geeks, the
first two suites will talk to virtually anything out there.  SSH is similar.

(This is Grigg's (Other) Law, "There is only one cipher suite and that is
Suite #1".  I have, oh I dunno, about six million cipher suites in my code,
including smoky-bacon, and the only one I'd need in practice is #1.  I'm not
sure why I even bother advertising the others, all it does is bloat up the
handshake unnecessarily...).

>choices for parameters then we are going to have to.

Yup.

Peter.

---

From: Sean Turner <[email-masked]>
Date: Thu, 07 Apr 2011 11:43:54 -0400

On 4/6/11 1:09 AM, Peter Gutmann wrote:
> Phillip Hallam-Baker<[email-masked]>  writes:
>

My hope for this possible WG is that it would simply define the code 
points and it would not modify the required algorithm for any protocol.

spt

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Apr 2011 09:48:34 -0700

On Apr 7, 2011, at 8:43 AM, Sean Turner wrote:

> My hope for this possible WG is that it would simply define the code points and it would not modify the required algorithm for any protocol.

So, who will decide when (in the simplest cases) SHA3-256 and RSA-with-SHA3-256 become SHOULD-level or MUST-level for security protocols, and when? Defining codepoints for Shiny Objects without telling developers what they mean will sow confusion in the marketplace. We already have widely diverging views more than a year before the Shiny Objects even exist.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 12:10:41 -0500

New alg codes defined by this WG should be REQUIRED to implement for
the corresponding protocols.  Moving _old_ algorithms to HISTORIC
should be left to other WGs, except perhaps in cases where there's no
currently chartered WG that could own such work.

Addition of algorithm agility should probably be out of scope for this
putative WG.

---

From: Sean Turner <[email-masked]>
Date: Thu, 07 Apr 2011 14:13:43 -0400

> So, who will decide when (in the simplest cases) SHA3-256 and RSA-with-SHA3-256 become SHOULD-level or MUST-level for security protocols, and when? Defining codepoints for Shiny Objects without tel…

I assumed it would be up to the WGs to decide to migrate and then they'd 
use the usual IETF process to progress to RFC.

My memory might not be as good as others, but have we drawn a line in 
the sand before with other algorithms?  If we did who did it?

spt

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Apr 2011 11:19:55 -0700

On Apr 7, 2011, at 11:13 AM, Sean Turner wrote:

> I assumed it would be up to the WGs to decide to migrate and then they'd use the usual IETF process to progress to RFC.

That would be sensible.

> My memory might not be as good as others, but have we drawn a line in the sand before with other algorithms?  

Who do you mean by "we"? That's a serious question.

> If we did who did it?

Well, we already have Nico proposing one...

--Paul Hoffman

---

From: Sean Turner <[email-masked]>
Date: Thu, 07 Apr 2011 14:22:35 -0400

> Who do you mean by "we"? That's a serious question.

We = IETF ;)

I can remember some dates in PKIX about using UTF8String for names after 
a certain date ;)

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Apr 2011 19:57:48 +0100

> I can remember some dates in PKIX about using UTF8String for names after

Can't see that working really - look how well DSA deployment
spread in TLS for example:-)

I'd guess the best we can do is have the putative group define
the ciphersuites/codepoints and then as an when it makes sense
to update/obsolete other RFCs for whatever reason, then alg
choices can be updated.

S.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 08 Apr 2011 15:32:45 +1200

Paul Hoffman <[email-masked]> writes:

>So, who will decide when (in the simplest cases) SHA3-256 and 
>RSA-with-SHA3-256 become SHOULD-level or MUST-level for security protocols, 
>and when?

The people writing the code. This has been the practice for years (look at any 
protocol like TLS or S/MIME, and then the tiny subset of features that, by 
mutual unspoken agreement, everyone implements, and all the mission-critical, 
must-implement stuff that everyone simply ignores). SHA3 won't be any 
different. Create a basic common feature set that matches existing experience 
with SHA2, ready for use when SHA3 appears, and everyone can bikeshed any 
additional modes for as long as they like afterwards, and implementers can 
ignore them for even longer.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Apr 2011 12:56:02 -0400

Sean,

Yes, we mandated  support for UTF-8 in Directory Name in RFC 2459, 
with a drop dead date of 12/31/2003.  That didn't work out, so we 
relaxed the requirement in 5280.

PKIX also mandated a drop dead date for 2-digit dates in certs and CRLs, to
deal with a Y2K whoops.  That was in 2459, and 3280, and in 5280. We still have
39 years to go before we learn if this requirement will be followed :-).

Steve

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 12:21:24 -0500

On Mon, Apr 11, 2011 at 11:56 AM, Stephen Kent <[email-masked]> wrote:
> Yes, we mandated  support for UTF-8 in Directory Name in RFC 2459, with a
> drop dead date of 12/31/2003.  That didn't work out, so we relaxed the
> requirement in 5280.

For a second I read that as "relaxed the requirement to [year] 5280".

:)