Subject: [Ietf-krb-wg] move to SHA-2

From: Zhanna Tsitkova <[email-masked]>
Date: Wed, 10 Jun 2009 14:49:51 -0400

Hello!

I am writing to propose the upgrading of the Kerberos cryptosystem  
with the additional hash functions from SHA-2 family  to ensure the  
compliance with NIST's Policy on hash functions   http://csrc.nist.gov/groups/ST/hash/policy.html 
:
" Federal agencies should stop using SHA-1 for digital signatures,  
digital time stamping and other applications that require collision  
resistance as soon as practical, and must use the SHA-2 family of hash  
functions for these applications after 2010. After 2010, Federal  
agencies may use SHA-1 only for the following applications: hash-based  
message authentication codes (HMACs); key derivation functions (KDFs);  
and random number generators (RNGs). Regardless of use, NIST  
encourages application and protocol designers to use the SHA-2 family  
of hash functions for all new applications and protocols."

This work would introduce new aes128 and aes256 based encryption and  
checksum types to the existing Kerberos protocol.

Regards,
Zhanna Tsitkova

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 10 Jun 2009 22:16:57 -0400

> compliance with NIST's Policy on hash functions   http://csrc.nist.gov/groups/ST/hash/policy.html 

That's easy enough to do.  I wonder, though, if we want to go further  
and switch to GCM or some such, and punt on the SHA hash functions  
altogether.

-- 
Ken Raeburn / [email-masked] / no longer at MIT Kerberos Consortium

---

From: Luke Howard <[email-masked]>
Date: Thu, 11 Jun 2009 12:42:09 +1000

Should write up the CCM implementation in the aes-ccm branch...

Sent from my iPhone

On 11/06/2009, at 12:16 PM, Ken Raeburn <[email-masked]> wrote:

> That's easy enough to do.  I wonder, though, if we want to go  
> further and switch to GCM or some such, and punt on the SHA hash  
> functions altogether.
>
> --

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Jun 2009 01:18:47 -0500

> >further and switch to GCM or some such, and punt on the SHA hash  

Well, the crypto framework would require updating.

> Should write up the CCM implementation in the aes-ccm branch...

Yes, a write up on the changes to the crypto framework borne out by
implementation experience would be handy.

Nico

---

From: Tom Yu <[email-masked]>
Date: Thu, 11 Jun 2009 10:45:21 -0400

Ken Raeburn <[email-masked]> writes:

>> compliance with NIST's Policy on hash functions
>> http://csrc.nist.gov/groups/ST/hash/policy.html :
>

Let us consider the most expedient yet sound way to do this.  Adopting
GCM and CCM will take substantially more specification work than "add
new AES cryptosystems that use SHA-2 in place of SHA-1 everywhere", so
I prefer that we take the latter, simpler, approach.

NIST wants to phase out SHA-1 by 2010, so we should try to have a
SHA-2 solution in place by then.  I know that the 2010 timeline does
not apply to uses of SHA-1 requiring preimage resistance such as in as
the hash of an HMAC, but the simplistic message that many people not
in the cryptographic community will hear is "no SHA-1 after 2010".

We could consider AEAD-capable modes such as GCM and CCM as a
longer-term project, given that there appears to be some interest in
AEAD-capable modes.  Would people with interest in modes like GCM or
CCM please speak up so that we have some idea of how to prioritize
that work?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Jun 2009 13:11:02 -0500

> I prefer that we take the latter, simpler, approach.

I agree.  Moreover, we'll get the most benefit from AEAD cipher modes in
the context of the GSS-API, and we wouldn't have to do quite as much
work to get the Kerberos GSS mechanism to use AEAD cipher modes as we
would to get all of Kerberos to use AEAD cipher modes.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Jun 2009 16:05:26 -0400

I'm confused.  I thought NIST was phasing out SHA-1 in  digital signatures, not in HMACs.

I don't really support moving away from SHA-1 for the sake of moving
away from SHA-1.  If we run into trouble with MAC lengths, then while
fixing that I have no problem moving to SHA-2.

I agree with Ken.  If we define any new ciphers they should be CCM or
GCM.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Jun 2009 16:10:43 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, Jun 11, 2009 at 12:42:09PM +1000, Luke Howard wrote:
    >> >further and switch to GCM or some such, and punt on the SHA
    >> hash >functions altogether.

    Nicolas> Well, the crypto framework would require updating.

No.  The crypto framework would not require updating to support CCM or
GCM.  We'd ignore the simplified profile of course.

We would need to update the framework to support AEAD, but I see no
reason to tie that to new cipher modes.

However as I said in another message, I see no reason to standardize
new cipher modes because of SHA-1.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Thu, 11 Jun 2009 16:37:38 -0400

> I'm confused.  I thought NIST was phasing out SHA-1 in  digital signatures, not in HMACs.

Much of the portion of the general public that actually has heard of
SHA-1 will likely hear "NIST says no more SHA-1 after 2010".

NIST is phasing out SHA-1 in digital signatures (which requires
collision resistance) by 2010.  You and I know that is not applicable
to the HMAC use case (which requires preimage resistance).

> fixing that I have no problem moving to SHA-2.

There appears to be consensus in the cryptographic community that
SHA-1 is weaker than its design goals.  That alone should be enough to
encourage us to consider moving away from SHA-1.  Whether the
weakening in collision resistance could translate into problems for
the HMAC use case is unknown at this time, I think.

> I agree with Ken.  If we define any new ciphers they should be CCM or

Updating our crypto framework to conceptually incorporate AEAD-capable
modes such as CCM and GCM will take a while.  It might be well past
2010 before any implementations ship the result of our work in that
area.  If you feel that we can accomplish all that in such an
aggressive timeframe, I would like to hear some details of how we are
going to do so.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Jun 2009 17:14:43 -0400

>>>>> "Tom" == Tom Yu <[email-masked]> writes:

    >> signatures, not in HMACs.

    Tom> Much of the portion of the general public that actually has
    Tom> heard of SHA-1 will likely hear "NIST says no more SHA-1
    Tom> after 2010".

I do not support the working group taking on new cipher modes based on
the reasoning you have given.  I think interoperability and
implementation testing concerns are more important than a public
perception in this instance.  So, I think it would be more harmful to
the global Kerberos community to work on new cipher modes for the sake
of avoiding sha-1 than it would be to fight the public perception
issue.

    >> I agree with Ken.  If we define any new ciphers they should be
    >> CCM or GCM.

    Tom> Updating our crypto framework to conceptually incorporate
    Tom> AEAD-capable modes such as CCM and GCM will take a while.  

I disagree any framework updates are nice.  If Luke gets around to
writing up a version of CCM that does support AEAD use that would be
fine.  I think it would also be fine to standardize a version that did
not expose AEAD.  I don't support doing that work for the reason of
getting away from sha-1, although there might be reasons for which I
would support the work.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 11 Jun 2009 17:35:05 -0400

> of avoiding sha-1 than it would be to fight the public perception

It wasn't entirely clear to me, but it sounded like the original proposal 
would have involved new variations on the existing AES-based enctypes and 
cksumtypes, replacing SHA-1 with a SHA-2 family hash.  Would you object to 
the working group taking on the work in that form?

Would you object to the WG taking on the work of specifying enctypes and 
cksumtypes using AES and a SHA-2 family hash, and leaving the question of 
which modes to use for discussion as part of that work, rather than setting 
it in stone/charter up front?

Anyone else?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Jun 2009 17:42:06 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> It wasn't entirely clear to me, but it sounded like the
    Jeffrey> original proposal would have involved new variations on
    Jeffrey> the existing AES-based enctypes and cksumtypes, replacing
    Jeffrey> SHA-1 with a SHA-2 family hash.  Would you object to the
    Jeffrey> working group taking on the work in that form?

Yes, and I believe that my objection would be independent of whatever
reasoning was used to justify the work.  I believe I understand the
issue sufficiently that discussion is unlikely to change my objection.

    Jeffrey> Would you object to the WG taking on the work of
    Jeffrey> specifying enctypes and cksumtypes using AES and a SHA-2
    Jeffrey> family hash, and leaving the question of which modes to
    Jeffrey> use for discussion as part o
I have not yet seen a justification for doing new cipher work ot all.
I would definitely push for specific modes in the charter item if we
were going to do new cipher mode work, but I'm not sure I feel
strongly enough about that to object to any proposal that left that
open.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 11 Jun 2009 15:18:52 -0700

> issue sufficiently that discussion is unlikely to change my objection.

Kerberos users seems to be slow enough to migrate to new enctypes as  
it is already.

Giving them more choices and the need to implement more Kerberos  
encryption types in kernel mode (for NFS and friends) would give us no  
more happiness.

I'm all for creating new modes if the modes have proper support in  
hardware and other software already available.

Love

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 11 Jun 2009 19:40:11 -0700

> hardware and other software already available.

I think I agree with this.  While many things negotiate to the correct  
enctype nicely, multiplying the number of choices makes managing an  
infrastructure harder.

There is still a very sizable fraction of the platforms out there that  
don't support the current AES enctypes yet.  I'm concerned that  
inventing new ones this soon will focus efforts toward simple upgrade  
deployments and away from application support.  While a lot of things  
support Kerberos now, it still lacks a lot in terms of mind-share and  
end-app polish.

I think I've worked around to Sam's position.  While the PR concerns  
w.r.t. SHA-1 are more real than I like, they aren't sufficient to  
justify new enctypes.  AEAD-capable modes seem much more interesting  
and justifiable.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]