Subject: AES256 - import/export issue

From: Wyllys Ingersoll <[email-masked]>
Date: Mon, 02 Feb 2004 11:40:00 -0800

Section 8.1 of the clarifications document declares that
AES 256 is a "MUST" support encryption mode.

Its come to my attention recently that there are still
some countries that restrict strong crypto.  France,
in particular, has restrictions on the import of crypto
above 128 bits - this obviously includes AES256.   I
think that mandating AES 256 may is going to make it
difficult to deliver an  "RFC Compliant" Kerberos
implementation without violating import/export laws
in some countries.

I would like to suggest lowering the "MUST" support
to AES128 and leave AES256 as a "may" or "should"
cipher.

-Wyllys Ingersoll

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 02 Feb 2004 14:55:50 -0500

I would be very interested in knowing how this issue was addressed in
other protocols which have provided support for AES and made it
mandatory to implement.  I do not believe the IETF should make
decisions based upon the arbitrary policies of individual nations but
based upon what is technically correct.

- Jeff

---

From: Wyllys Ingersoll <[email-masked]>
Date: Mon, 02 Feb 2004 13:09:07 -0800

> based upon what is technically correct.

Agreed, but I would not consider AES-128 to be technically incorrect,
its just not as strong as we would like it to be.  Mandating crypto
that has legal restrictions placed upon it will not foster interoperability
no matter how technically correct the specification may be.

-Wyllys

---

From: Matt Crawford <[email-masked]>
Date: Mon, 02 Feb 2004 15:37:21 -0600

> to AES128 and leave AES256 as a "may" or "should"

That would go against the spirit of Danvers Doctrine, as codified in 
BCP 61, RFC 3365. Whether it goes against the letter depends on whether 
you consider AES128 "strong" or not.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Feb 2004 17:37:58 -0500

I think I can safely take off my chair's hat here and speak as an 
individual...

On Monday, February 02, 2004 15:37:21 -0600 Matt Crawford 
<[email-masked]> wrote:

> That would go against the spirit of Danvers Doctrine, as codified in BCP
> 61, RFC 3365. Whether it goes against the letter depends on whether you
> consider AES128 "strong" or not.

I assume the paragraph to which you refer is this one:

   The solution is that we MUST implement strong security in all
   protocols to provide for the all too frequent day when the protocol
   comes into widespread use in the global Internet.

Taken in context, this is a response to the argument that some protocols 
need not incorporate any security at all because their designers envision 
them being used only in "protected" environments.

However, I believe the following, describing the concensus reached in 
Danvers, to be both stronger and more relevant:

   The overwhelming consensus was that the IETF should standardize on
   the use of the best security available, regardless of national
   policies.  This consensus is often referred to as the "Danvers
   Doctrine".

Not just "strong", but "the best security available".  I believe this is a 
clear argument for the use of AES256, not AES128, regardless of the 
policies of the government of France.  If the French government wishes to 
limit the access of its citizens to strong crypto, I guess that's their 
right, and I'm sure glad I don't live in France.  But it is _not_ their 
right to limit the access of the citizens of the rest of the world to 
strong crypto.

We didn't make 40-bit DES the mandatory-to-implement enctype while it was 
hard to export anything stronger from the US; we certainly shouldn't make 
128-bit AES the mandatory-to-implement enctype just because it's hard to 
import anything stronger into France.  The French can lobby their vendors 
for weaker crypto, or their government for the freedom to use stronger 
crypto.

-- Jeff

---

From: Wyllys Ingersoll <[email-masked]>
Date: Mon, 02 Feb 2004 14:56:19 -0800

Jeffrey Hutzelman wrote:

> Not just "strong", but "the best security available".  I believe this 
> is a clear argument for the use of AES256, not AES128, regardless of 
> the policies of the government of France.  If the French government 
> wishes to limit the access of its citizens to strong crypto, I guess 
> that's their right, and I'm sure glad I don't live in France.  But it 
> is _not_ their right to limit the access of the citizens of the rest 
> of the world to strong crypto.
>
> We didn't make 40-bit DES the mandatory-to-implement enctype while it 
> was hard to export anything stronger from the US; we certainly 
> shouldn't make 128-bit AES the mandatory-to-implement enctype just 
> because it's hard to import anything stronger into France.  The French 
> can lobby their vendors for weaker crypto, or their government for the 
> freedom to use stronger crypto.
>
> -- Jeff

Its not just France, its also Russia, Israel, China and probably some 
others.

However, after reading RFC 3365,  I do think that mandating AES256 is 
the correct thing to do.

Kerberos clarifications does not even mention AES-128 as a "should" 
implement algorithm in section 8.1,
though.   Is this an oversight or was it just assumed that with AES-256 
as mandatory, there should
be no need for AES-128?    I think AES-128 ought to be at least 
mentioned as a possible compromise for
those that are bound by stricter rules.

-Wyllys

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Feb 2004 10:19:58 -0500

>>>>> "Wyllys" == Wyllys Ingersoll <[email-masked]> writes:

    Wyllys> Kerberos clarifications does not even mention AES-128 as a
    Wyllys> "should" implement algorithm in section 8.1, though.  Is
    Wyllys> this an oversight or was it just assumed that with AES-256
    Wyllys> as mandatory, there should be no need for AES-128?  I
    Wyllys> think AES-128 ought to be at least mentioned as a possible
    Wyllys> compromise for those that are bound by stricter rules.

It is not an oversight; the issue was discussed.  I don't remember the
reasoning.

One question you should ask here: are we too late in the process to
address this issue?  The document currently stands before the IESG
with specific technical issues (this not among them) preventing
publication.  If we (the authors) had been a bit faster, the document
might already be approved.  Do you want to delay the process even
more?

If it were during working group last call, I could see a significant
argument for SHOULD aes-128.  But I'm not sure that argument still
holds at this point in the process.

That said, I will not object if the IETF decides to make aes-128 a
SHOULD.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 03 Feb 2004 13:07:10 -0500

>might already be approved.  Do you want to delay the process even
I don't want to further delay the process at this point.   If the 
document does
come back for further/final edits, it would be nice to insert aes-128
as a SHOULD item, but I dont think its worth calling it back just to
make that one change.

I would have noticed this during last call had I been working on the
implementation at that time.  I only recently started on the code
and realized that AES256 is not available in my environment by
default (it is easily added later, though) which led me to learn
about the import restrictions. 

Im curious to know what other vendors/implementors are doing -
Is MIT going to offer both aes-128 and aes-256?   Microsoft?
Hiemdal? 

-Wyllys

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Feb 2004 13:26:14 -0500

>>>>> "Wyllys" == Wyllys Ingersoll <[email-masked]> writes:

    Wyllys> I would have noticed this during last call had I been
    Wyllys> working on the implementation at that time.  I only
    Wyllys> recently started on the code and realized that AES256 is
    Wyllys> not available in my environment by default (it is easily
    Wyllys> added later, though) which led me to learn about the
    Wyllys> import restrictions. Im curious to know what other
    Wyllys> vendors/implementors are doing - Is MIT going to offer
    Wyllys> both aes-128 and aes-256?  Microsoft?  Hiemdal? -Wyllys

    >> If it were during working group last call, I could see a
    >> significant argument for SHOULD aes-128.  But I'm not sure that
    >> argument still holds at this point in the process.
    >> 
    >> That said, I will not object if the IETF decides to make
    >> aes-128 a SHOULD.
    >> 
    >> 
    >> 

- MIT implements both aes256 and aes128 but currently (1.3.1) only
  enables 256 by default.

I am going to commit a change to enable aes128 by default in the
client and application servers.  I'll request this change be pulled up
to the release branch.

My preference which I have not discussed with the rest of the team is
that when we get around to adding an AES enctype to the default list
of keys in the database, we only add aes256.

---

From: Love <[email-masked]>
Date: Tue, 03 Feb 2004 20:41:14 +0100

> Is MIT going to offer both aes-128 and aes-256?   Microsoft?

heimdal support both aes-128 and aes-256.

Love