Subject: Re: agenda items..

From: Niels Provos <[email-masked]>
Date: Wed, 13 Dec 2000 04:07:01 -0500

In message <[email-masked]>, Darren J Moffat writes:
>I'd like to back this up.  It is important for US Export compliance to
>be able to "cap" algorithms at a certain key lengths.  All algorithm
>names thus need to have the keylength included so that US domestic and
>international clients have a chance to interoperate.  eg.  A US
>domestic ssh client may support twofish-256-cbc but it is connecting
>to an ssh server that only supports twofish-128-cbc because it is
>located outside the US.
I do not think that we should concern ourselves with US Export
restrictions.  Nobody with any sense is going to run restricted US
software, there are too many better alternatives.  However, there
are other good reasons to indicate the key size.  These ciphers
have different key size modes and to keep things simple indicating
the key size in the name is the easiest.

Perhaps we can resolve this in London next year ;)
  Niels.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 13 Dec 2000 13:05:04 -0500

> restrictions.  

Correct; on the whole, the IETF does not engineer security protocols
to include weak crypto or to accomodate the regulations of specific
jurisdictions.  The documents do not need to acknowledge export
control issues, and should not specify ciphers known to be feasibly
breakable.

> However, there are other good reasons to indicate the key size.
> These ciphers have different key size modes and to keep things
> simple indicating the key size in the name is the easiest.

Agreed.  As I understand it, this should be sufficient to meet
Darren's fundamental requirements..

> Perhaps we can resolve this in London next year ;)

Assuming they don't demand copies of our private keys as a condition
of entry at Heathrow ;-)

					- Bill

---

From: Darren J Moffat <[email-masked]>
Date: Thu, 14 Dec 2000 16:48:52 -0800

> control issues, and should not specify ciphers known to be feasibly

Thats fine, I wouldn't want the text to reference anything like this
that is purely political and is subject to change.

I do however want to make sure that vendors based in countries that have
such nonsense export restrictions can actually still ship a usable
product
that is compliant and able to interoperate.

> Darren's fundamental requirements..

Thats fine, as my comment was more intended as rational than suggested
text - I could have made this clearer.

--
Darren J Moffat

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Dec 2000 18:01:17 -0500

At 19:48 14/12/00, Darren J Moffat wrote:

>I do however want to make sure that vendors based in countries 
>that have such nonsense export restrictions can actually still 
>ship a usable product that is compliant and able to interoperate.

        With all respect, **IETF MUST IGNORE** export rules when
making decisions about what the mandatory-to-implement algorithms
and key-lengths are.  IETF policy, established long ago and
repeated with ESP in the recent past, is to require good algorithms
and good key lengths -- even if that means that companies based
in countries with nonsense export restrictions (or use restrictions,
consider France or Iraq or Singapore or ...) have local problems.

<EXAMPLE>
        For example, the SSH WG could choose (hypothetical
example, not a suggestion) that 3DES with 112-bit keys was
MUST IMPLEMENT, even if that meant that a US-based firm could
not export such an implementation.  This would not necessarily
preclude the WG from also specifying other US-exportable
algorithms as either optional or mandatory to implement.
</EXAMPLE>

        The IETF is an international organisation and MUST develop
its standards on a global basis, without regard to silly local 
restrictions about crypto exportability or crypto use.  While
I am not speaking for the IAB in this note, I am confident that
they concur with this (please see RFC-1984 for official IAB
and IETF policy on this).

Regards,

Ran
[email-masked]