From Gregory@netscreen.com Tue Jan 13 16:56:38 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i0DLuW11019706
	for <saag@jis.mit.edu>; Tue, 13 Jan 2004 16:56:37 -0500 (EST)
Received: from mail1.netscreen.com (mail1.netscreen.com [63.126.135.16] (may
	be forged))i0DLuVUA014197
	for <saag@mit.edu>; Tue, 13 Jan 2004 16:56:31 -0500 (EST)
Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35])
	i0DLu4Ya015715;	Tue, 13 Jan 2004 13:56:15 -0800 (PST)
Received: by NS-CA with Internet Mail Service (5.5.2653.19)
	id <CSB2LPVK>; Tue, 13 Jan 2004 13:56:03 -0800
Message-ID: <541402FFDC56DA499E7E13329ABFEA87039759BF@SARATOGA.netscreen.com>
From: Gregory Lebovitz <Gregory@netscreen.com>
To: "'pki4ipsec@icsalabs.com'" <pki4ipsec@icsalabs.com>,
   "'ipsec@icsalabs.com'" <ipsec@icsalabs.com>,
   "'saag@mit.edu'"
	 <saag@mit.edu>
Date: Tue, 13 Jan 2004 13:55:56 -0800
X-Message-Flag: 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.633346
Subject: [saag] FW: WG Review: Profiling Use of PKI in IPSEC (pki4ipsec)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 13 Jan 2004 21:56:38 -0000

Fyi... Pki4ipsec is in IESG WG review now.

NOTE: a small change had been submitted for the charter, which somehow did
not make it into what the IESG sent out; in SCOPE section, sentence should
read:
 
  "Gateway-to-gateway access (tunnel _and transport_ mode) and end-user..."

Mail list for the group is:
   pki4ipsec@icsalabs.com
   More info at:  www.icsalabs.com/pki4ipsec

Gregory
Chair, pki4ipsec

> -----Original Message-----
> From: Dinara Suleymanova [mailto:dinaras@cnri.reston.va.us] 
> Sent: Tuesday, January 13, 2004 11:46 AM
> Subject: WG Review: Profiling Use of PKI in IPSEC (pki4ipsec)
> 
> 
> ------- Blind-Carbon-Copy
> 
> From: The IESG <iesg-secretary@ietf.org>
> To: IETF-Announce: ;
> Cc: new-work@ietf.org
> Subject: WG Review: Profiling Use of PKI in IPSEC (pki4ipsec)
> Date: Tue, 13 Jan 2004 14:45:38 -0500
> Sender: dinaras@CNRI.Reston.VA.US
> 
> A new IETF working group has been proposed in the Security Area.  
> The IESG has not made any determination as yet.  The 
> following description 
> was submitted, and is provided for informational purposes only.  
> Please send your comments to the IESG mailing list 
> (iesg@ietf.org) by January 20.
> 
> Profiling Use of PKI in IPSEC (pki4ipsec)
> - ---------------------------
> 
> Current Status: Proposed Working Group
> 
> DESCRIPTION:
> IPsec has been standardized for over 5 years, and the use of 
> X.509 certificates have been specified within the IPsec 
> standards for the same time. However, very few IPsec 
> deployments use certificates. One reason is the lack of a 
> clear description of how X.509 certificates should be used 
> with IPsec. Another is the lack of a simple, scalable, and 
> clearly specified way for IPsec systems to obtain 
> certificates and perform other certificate lifecycle 
> operations with PKI systems.
> 
> THE WG WILL DELIVER:
> 
> 1) A standards-track document that gives specific
> instructions on how X.509 certificates should be
> handled with respect to the IKEv1 and IKEv2 protocols.
> This document will include a certificate profile, addressing 
> which fields in the certificate should have which values and 
> how those values should be handled. This effort is the WG's 
> primary priority.
> 
> 2) An informational document identifying and describing 
> requirements for a profile of a certificate management 
> protocol to handle PKI enrolment as well as certificate 
> lifecycle interactions between IPsec VPN systems and PKI 
> systems. Enrolment is defined as certificate request and 
> retrieval. Certificate lifecycle interactions is defined as 
> certificate renewals/changes, revocation, validation, and 
> repository lookups.
> 
> These requirements will be designed so that they meet
> the needs of enterprise scale IPsec VPN deployments.
> 
> Once the above to items enter WG last call, we will begin work on:
> 
> 3) A standards-track document describing a detailed
> profile of the CMC protocol that meets the requirements
> laid out in the requirements document. Profile documents for 
> other enrolment and/or management protocols may also be created.
> 
> SCOPE
> The working group will focus on the needs of enterprise scale 
> IPsec VPN deployments. Gateway-to-gateway access (tunnel
> mode) and end-user remote access to a gateway (either tunnel
> or transport mode) are both in scope.
> 
> NON-GOALS
> 
> User-to-user IPsec connections will be considered, but are
> not explicitly in scope. We will consider the requirements
> for this scenario only until doing so significantly slows the 
> progress of the explicitly scoped items, at which point it 
> will be dropped.
> 
> Specification of communications between an IPsec
> administrative function and IPsec systems is explicitly out of scope.
> 
> Purely PKI to PKI issues will not be addressed. 
> Cross-certification will not be addressed. Long term 
> non-repudiation will also not be addressed.
> 
> 
> 
> 
> ------- End of Blind-Carbon-Copy
> 
From Gregory@netscreen.com Tue Jan 13 17:21:21 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i0DMLK11020179
	for <saag@jis.mit.edu>; Tue, 13 Jan 2004 17:21:20 -0500 (EST)
Received: from mail1.netscreen.com (mail1.netscreen.com [63.126.135.16] (may
	be forged))i0DMLJ1Y001341
	for <saag@mit.edu>; Tue, 13 Jan 2004 17:21:19 -0500 (EST)
Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35])
	i0DMLBYa018395;	Tue, 13 Jan 2004 14:21:14 -0800 (PST)
Received: by NS-CA with Internet Mail Service (5.5.2653.19)
	id <CSB2LQH2>; Tue, 13 Jan 2004 14:21:11 -0800
Message-ID: <541402FFDC56DA499E7E13329ABFEA87039759C2@SARATOGA.netscreen.com>
From: Gregory Lebovitz <Gregory@netscreen.com>
To: "'Steve Bellovin'" <smb@research.att.com>,
   "'saag@mit.edu'"
	 <saag@mit.edu>
Subject: RE: [saag] 3DES vs. AES
Date: Tue, 13 Jan 2004 14:21:03 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.837345
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 13 Jan 2004 22:21:22 -0000

As a vendor...

One of the reasons people have disagreed with AES as a MUST is that "it will
take the industry time to get its hardware updated with AES."

What better way to get the industry moving than to make AES a MUST? Yes, for
some small window of time some set of vendors who haven't yet gotten to work
on AES in hardware will be "non-compliant" to some yet-to-come-protocol. But
they will tell their customers, "We are compliant with RFC NNNN, including
3DES, and excluding AES, but AES is coming in [some-near-future-date]." Once
they release the version with AES, they'll removing the disclaimer, and that
will be that.

In this discussion on IPSEC maillist I argued for:
 AES = MUST - the right thing to do cryptographically
3DES = SHOULD - a good thing to do for compatibility for some time to come

..and let people state clearly which they do in their own marketing
literature, release notes, etc.

Gregory.

> -----Original Message-----
> From: Steve Bellovin [mailto:smb@research.att.com] 
> Sent: Wednesday, December 03, 2003 11:44 AM
> To: saag@mit.edu
> Subject: [saag] 3DES vs. AES
> 
> 
> For new deployments, which cipher should be mandatory-to-implement, 
> 3DES or AES?
> 
> For protocols with an installed base, we've mandated 3DES, 
> with AES as 
> a "SHOULD".  The IPsec WG has said something stronger:  AES is a 
> "SHOULD+", meaning that it will probably become a "MUST" in the next 
> version.
> 
> But what do we tell protocol designers who are designing new 
> protocols? 
> My personal preference is AES.  For the low end, it's so much 
> more efficient in software; for the high end, its 128-bit 
> block size permits much more data to be encrypted with a single key.
> 
> On the other hand, as John Gilmore has noted, 3DES has been 
> studied for 
> about 25 years.  That's a lot of scrutiny; AES hasn't had nearly that 
> much attention.
> 
> 		--Steve Bellovin, http://www.research.att.com/~smb
> 
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 
From john@pioneer-pra.com Mon Feb  9 10:55:46 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i19Ftg11014099
	for <saag@jis.mit.edu>; Mon, 9 Feb 2004 10:55:46 -0500 (EST)
Received: from IPOfCard1.guest-tek.com ([206.48.23.226])
	i19Ftd8h009852
	for <saag@mit.edu>; Mon, 9 Feb 2004 10:55:41 -0500 (EST)
Received: from [172.17.3.155] ([172.17.3.155])
	by IPOfCard1.guest-tek.com (8.11.6/8.11.6) with ESMTP id i19FpQr28752;
	Mon, 9 Feb 2004 11:51:26 -0400
Mime-Version: 1.0 (Apple Message framework v612)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <66D12B4C-5B18-11D8-8182-000A95D04EFE@pioneer-pra.com>
Content-Transfer-Encoding: 7bit
From: John Gildred <john@pioneer-pra.com>
Date: Mon, 9 Feb 2004 07:55:36 -0800
To: saag@mit.edu
X-Mailer: Apple Mail (2.612)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.556846
Subject: [saag] PERM I-D
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 09 Feb 2004 15:55:47 -0000

I'd like to bring to the SAAG's attention the availability of a new 
Internet Draft describing a protocol for content protection and rights 
management. Details are below.

	Title		: Protected Entertainment Rights Management (PERM)
	Filename	: draft-gildred-perm-00.txt
	Pages		: 73
	Date		: 2004-2-6
	
Abstract:
This document describes the Protected Entertainment Rights Management
    (PERM) protocol for management of usage rights to digital
    entertainment content. PERM is not intended to replace existing copy
    protection and conditional access systems. Rather it is intended to
    complement such systems by providing standardized methods of device
    and user authentication, content protection and content rights
    management across heterogeneous data networks. PERM does not impose
    any content usage policy upon an implementation of the PERM protocol.
    PERM defines a common method for policy enforcement, and implementors
    are free to design and enforce their own policy by using the features
    and conventions of the PERM protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gildred-perm-00.txt

From info@caitr.org Thu Feb 19 10:46:22 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i1JFkG11029720
	for <saag@jis.mit.edu>; Thu, 19 Feb 2004 10:46:21 -0500 (EST)
Received: from web41804.mail.yahoo.com (web41804.mail.yahoo.com
	[66.218.93.138])i1JFkFlg028737
	for <saag@mit.edu>; Thu, 19 Feb 2004 10:46:15 -0500 (EST)
Message-ID: <20040219154614.40682.qmail@web41804.mail.yahoo.com>
Received: from [63.159.88.109] by web41804.mail.yahoo.com via HTTP;
	Thu, 19 Feb 2004 07:46:14 PST
Date: Thu, 19 Feb 2004 07:46:14 -0800 (PST)
From: CAITR <info@caitr.org>
To: saag@mit.edu
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1899672179-1077205574=:39013"
Spam-Alum-Prob: 0.000002
Spam-Alum-Time: 0.608326
Subject: [saag] Internetworking 2004: May 13-14, 2004, Las Vegas
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: info@caitr.org
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 19 Feb 2004 15:46:23 -0000

--0-1899672179-1077205574=:39013
Content-Type: text/plain; charset=us-ascii

CONFERENCE ANNOUNCEMENT & CALL FOR PRESENTATIONS 

------------------------------------------------------------------------------
      INTERNETWORKING 2004
Technical Program: May 13-14, 2004
          Las Vegas, Nevada
http://www.caitr.org/internetworking04/
In conjunction with NetWorld+Interop Las Vegas 2004
--------------------------------------------------------------------------------
The Internetworking 2004 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. 

Summaries not exceeding 250 words should be submitted (in plain text format) to submissions at caitr.org for review and possible inclusion in the program, no later than February 25, 2004.

Topics of interest include, but are not limited to the following: 

   Voice over IP (VoIP) 
   Virtual Private Networks 
   Routing and Quality of Service (QoS) 
   Network Processors 
   Network Security 
   Service Integration 
   Operational Support Systems 
   Transition from IPv4 to IPv6 and Interworking 
   Network Survivability and Fault Management 
   Wireless Internet 
   Next Generation Mobile Networks 
   Internetworking IP and Optical Networks 
   Internetworking MPLS with Legacy ATM and Frame Relay Networks 
   Fiber To The Home (FTTH) 
   High Speed Transport Layer Protocols 
   Unicast and Multicast Routing and Convergence 
   Storage Area Networks (SANs) 
   Peer to Peer Networking 
   Pervasive Computing 
   Grid Computing 
   IP Video Conferencing 
   High Definition Video Distribution 

For additional information, please contact info at caitr.org, or the conference technical chair, Dr. Parviz Yegani (<pyegani at cisco.com>).



--0-1899672179-1077205574=:39013
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>CONFERENCE ANNOUNCEMENT &amp; CALL FOR PRESENTATIONS <BR><BR>------------------------------------------------------------------------------<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTERNETWORKING 2004<BR>Technical Program: May 13-14, 2004<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Las Vegas, Nevada<BR><A href="http://www.caitr.org/internetworking04/" target=_blank>http://www.caitr.org/internetworking04/</A></DIV>
<DIV>In conjunction with NetWorld+Interop Las Vegas 2004</DIV>
<DIV>--------------------------------------------------------------------------------<BR>The Internetworking 2004 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. <BR><BR>Summaries not exceeding 250 words should be submitted (in plain text format) to <A href="http://lists.cs.columbia.edu/mailman/listinfo/tccc" target=_blank><FONT color=#0000ff>submissions at caitr.org</FONT></A> for review and possible inclusion in the program, no later than February 25, 2004.<BR><BR>Topics of interest include, but are not limited to the following: </DIV>
<DIV><BR>&nbsp;&nbsp; Voice over IP (VoIP) <BR>&nbsp;&nbsp; Virtual Private Networks <BR>&nbsp;&nbsp; Routing and Quality of Service (QoS) <BR>&nbsp;&nbsp; Network Processors <BR>&nbsp;&nbsp; Network Security <BR>&nbsp;&nbsp; Service Integration <BR>&nbsp;&nbsp; Operational Support Systems <BR>&nbsp;&nbsp; Transition from IPv4 to IPv6 and Interworking <BR>&nbsp;&nbsp; Network Survivability and Fault Management <BR>&nbsp;&nbsp; Wireless Internet <BR>&nbsp;&nbsp; Next Generation Mobile Networks <BR>&nbsp;&nbsp; Internetworking IP and Optical Networks <BR>&nbsp;&nbsp; Internetworking MPLS with Legacy ATM and Frame Relay Networks <BR>&nbsp;&nbsp; Fiber To The Home (FTTH) <BR>&nbsp;&nbsp; High Speed Transport Layer Protocols <BR>&nbsp;&nbsp; Unicast and Multicast Routing and Convergence <BR>&nbsp;&nbsp; Storage Area Networks (SANs) <BR>&nbsp;&nbsp; Peer to Peer Networking <BR>&nbsp;&nbsp; Pervasive Computing <BR>&nbsp;&nbsp; Grid Computing <BR>&nbsp;&nbsp; IP Video Conferencing
 <BR>&nbsp;&nbsp; High Definition Video Distribution <BR><BR>For additional information, please contact <A href="http://lists.cs.columbia.edu/mailman/listinfo/tccc" target=_blank><FONT color=#0000ff>info at caitr.org</FONT></A>, or the conference technical chair, Dr. Parviz Yegani (&lt;<A href="http://lists.cs.columbia.edu/mailman/listinfo/tccc" target=_blank><FONT color=#0000ff>pyegani at cisco.com</FONT></A>&gt;).<BR></DIV></DIV>
--0-1899672179-1077205574=:39013--
From pekkas@netcore.fi Tue Mar 16 01:48:39 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i2G6mc11008514
	for <saag@jis.mit.edu>; Tue, 16 Mar 2004 01:48:38 -0500 (EST)
Received: from netcore.fi (netcore.fi [193.94.160.1])i2G6mbQX004269
	for <saag@mit.edu>; Tue, 16 Mar 2004 01:48:37 -0500 (EST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i2G6ma014704
	for <saag@mit.edu>; Tue, 16 Mar 2004 08:48:36 +0200
Date: Tue, 16 Mar 2004 08:48:36 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: saag@mit.edu
Message-ID: <Pine.LNX.4.44.0403160835220.14004-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.692742
Subject: [saag] Using IPsec to secure v6-over-v4 tunnels -- questions
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 16 Mar 2004 06:48:40 -0000

Hi,

At v6ops, sometimes people has flashed the idea of using IPsec to 
secure IPv6-over-IPv4 tunneling (or some part of it).  This note looks 
at this in a bit more detail, and tries to raise a few questions (look 
at the end.)

background
----------

How do we set up secure v6-over-v4 tunnels (in the control & data
plane security sense) for client <-> tunnel-server communication? How
feasible is this?

I'm mostly interested in investigating whether IPsec could be used as
a "transport mechanism" for traversing NATs or managing the
"configured tunnel end-point setup" when the address is dynamic.  
IPsec may not be feasible in all the scenarios, but if IPsec could be
used to simplify a number of different cases, and security would come
in as bonus, I guess it wouldn't hurt.. :)

Basically, if you need data plane security (i.e., transport security),
we go down to IPsec.  Some control plane security might be manageable 
with ad-hoc mechanisms, such as hashing/keying methods or return 
routability.

Now, as for IPsec, there seem to be two ways to deal with this.

approaches
----------

These would only secure the IPv6-in-IPv4 tunnel link, not give any
kind of end-to-end encryption.  In a "road-warrior" -like case,
tunneling back home, this could be enough.

1) IPv4 IPsec tunnel mode with IPv6 payload transform, resulting to:

(In both, I'm excluding the authentication part, or ESP padding.)

IPv4 header - 20 bytes
  ESP header - 8 bytes
    IPv6 header - 40 bytes
      [IPv6 payload]

2) IPv4 IPsec in transport mode with IPv4 transform, resulting to:

IPv4 header - 20 bytes [next-header set to 41: implicit v6-over-v4]
  ESP header - 8 bytes
    IPv6 header - 40 bytes
       [IPv6 payload]

So, both the approaches seem to be equivalent.  Only, the mixed-IP
version transforms, 1), is only supported by a couple of
implementations, while I think 2) is more commonplace.  

2) would additionally require a co-located configured tunnel
management to the IPsec endpoints. If the method was used with dynamic
addresses, this could be quite problematic, unless IPsec provides some
triggers to "reconfigure" the configured tunnel to accommodate new
tunnel-endpoint.  A different approach is having some kind of 
pseudo-interface which would not have these issues, but I think we 
already got out of those... :)

So, the overhead of about 28 bytes compared to 20 of v6-over-v4 
tunnel in IP.

If you encapsulate IPsec in UDP for NAT traversal, that's 8 additional
bytes.  That part is commonly implemented.  Note that NAT traversal
obviously only works when the other end-point has a public address.

It seems a simple deployment for client <-> tunnel-server
communication could be obtained using either mechanism, with 2)
requiring zero implementation, only (rather complex) management for
the tunnel-end point (if dynamic/NAT-traversed) in configured
tunneling.  So, in a sense 1) gives you simplicity when ÍPsec has to
deal with that particular dynamicity complexity.

Are there any flaws or missing points in this analysis?  Thoughts?

questions
---------

Procedural questions:

  1) Do you think this work (i.e., documenting the possibilities, 
fleshing them out a bit) is useful, and should be done?  [if you want 
to work on it, feel free to say so as well :)]

  2) Do you believe this is operationally sufficiently feasible to be 
worth exploring?  (I.e., would there be users which might use this 
mechanism if fleshed out.)

Technical questions:

 1) What is the implementation status of "mixed protocol transforms"?  
(option 1 above).  This has several advantages, but has worse
implementation status and may be more difficult from policy POV as
well.

 2) is there fundamental implementation (or otherwise) difference 
between tunnel and transport mode ESP especially at the VPN 
concentrators? (transport is not mandatory, but as for the rest, I 
don't know.)

 3) are there any policy setup/IKE issues if trying to set up policies
for either mixed-protocol transforms or the transport mode issue,
below?

 4) How well does IPsec deal with dynamic IPv4 addresses for one
end-point (with or without NAT).  Does it provide triggers to the
lower layers when the addresses change?

Feel free to respond off-list if you feel like it -- if there are 
sufficiently many replies, I'll summarize on the list.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings





From mcr@sandelman.ottawa.on.ca Tue Mar 16 18:08:59 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i2GN8w11027043
	for <saag@jis.mit.edu>; Tue, 16 Mar 2004 18:08:58 -0500 (EST)
Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca
	[205.150.200.166])i2GN8rGT018134
	for <saag@mit.edu>; Tue, 16 Mar 2004 18:08:57 -0500 (EST)
Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca
	[205.150.200.247])i2GMx6n18314verified OK);
	Tue, 16 Mar 2004 17:59:12 -0500 (EST)
Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1])
	i2GMx6lQ020182
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 16 Mar 2004 17:59:06 -0500
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	i2GMx4OU020179;	Tue, 16 Mar 2004 17:59:05 -0500
To: Pekka Savola <pekkas@netcore.fi>
Subject: Re: [saag] Using IPsec to secure v6-over-v4 tunnels -- questions 
In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> 
	<Pine.LNX.4.44.0403160835220.14004-100000@netcore.fi> 
References: <Pine.LNX.4.44.0403160835220.14004-100000@netcore.fi> 
X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6)
Date: Tue, 16 Mar 2004 17:59:04 -0500
Message-ID: <20178.1079477944@marajade.sandelman.ottawa.on.ca>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.669855
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 16 Mar 2004 23:08:59 -0000

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Pekka" == Pekka Savola <pekkas@netcore.fi> writes:
    Pekka> These would only secure the IPv6-in-IPv4 tunnel link, not give any
    Pekka> kind of end-to-end encryption.  In a "road-warrior" -like case,
    Pekka> tunneling back home, this could be enough.

    Pekka> 1) IPv4 IPsec tunnel mode with IPv6 payload transform,
    Pekka> resulting to: 
    Pekka> (In both, I'm excluding the authentication part, or ESP padding.)

    Pekka> IPv4 header - 20 bytes
    Pekka> ESP header - 8 bytes
    Pekka> IPv6 header - 40 bytes
    Pekka> [IPv6 payload]

    Pekka> 2) IPv4 IPsec in transport mode with IPv4 transform,
    Pekka> resulting to: 

    Pekka> IPv4 header - 20 bytes [next-header set to 41: implicit v6-over-v4]
    Pekka> ESP header - 8 bytes

  (Surely you mean "next-header" is set on the ESP)

    Pekka> IPv6 header - 40 bytes
    Pekka> [IPv6 payload]

  Uh, I don't understand.
  The only way that I think one could have "IPv4 IPsec tunnel mode" 
would be if one in fact had:

      IPv4 header  (protocol = ESP)
        ESP header (protocol = IPIP,4)
	  IPv4 header (protocol = 41)
	    IPv6 header

  That's a silly waste of 20 bytes in my opinion.
  Other than that, whether we call it tunnel or transport isn't very
important, except at the key exchange level, where we have to have some
agreement for the traffic selectors.

    Pekka> 2) would additionally require a co-located configured tunnel
    Pekka> management to the IPsec endpoints. If the method was used
    Pekka> with dynamic addresses, this could be quite problematic,
    Pekka> unless IPsec provides some triggers to "reconfigure" the
    Pekka> configured tunnel to accommodate new tunnel-endpoint.  A

  I don't see a problem with that.

    Pekka> Procedural questions:

    Pekka> 1) Do you think this work (i.e., documenting the possibilities, 
    Pekka> fleshing them out a bit) is useful, and should be done?  [if
    Pekka> you want to work on it, feel free to say so as well :)]

  Yes, it would be useful to flesh this out.
  I regret that I don't have the resources to do this.

    Pekka> 2) Do you believe this is operationally sufficiently feasible to be 
    Pekka> worth exploring?  (I.e., would there be users which might use this 
    Pekka> mechanism if fleshed out.)

  Yes.

    Pekka> Technical questions:

    Pekka> 1) What is the implementation status of "mixed protocol
    Pekka> transforms"?   

  Poor. I'm not aware of any stack that can do it at present, although
I know that many stacks provide for the descriptive capability, just not
the implementation.

    Pekka> 2) is there fundamental implementation (or otherwise) difference 
    Pekka> between tunnel and transport mode ESP especially at the VPN 
    Pekka> concentrators? (transport is not mandatory, but as for the rest, I 
    Pekka> don't know.)

  Tunnel mode is easier to offload to a blade, because once you get a
new packet out, you can just "route" it. Transport requires that you
pass it carefully up to the upper layer.

    Pekka> 3) are there any policy setup/IKE issues if trying to set up
    Pekka> policies for either mixed-protocol transforms or the
    Pekka> transport mode issue, below?

  At the IKE level, I think that one would have to propose transport
mode with IP protocol = 41 in today's implementation.
  There is no descriptive reason why the "phase 1" IDs can't be IPv4
while the "phase 2" IDs are IPv6, except that many implementations would
not have code to accept this.
  The outer IPv4s are implicitely used (in most cases) to signal what
the src/dest for the outer IPv4/ESP packet. 

    Pekka> 4) How well does IPsec deal with dynamic IPv4 addresses for one
    Pekka> end-point (with or without NAT).  Does it provide triggers to the
    Pekka> lower layers when the addresses change?

  You mean if the IPv4 address changes?
  None. See MOBIKE WG.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQFeGt4qHRg3pndX9AQGE2AP+IK+wexrEDCK0znXv403vsN6yy7E4ywCF
E2ERqj4s5E9CieeEWFTEBg/mRQ9+hGEKgahSrRZz5wKJwrGVxSc1xtVx79/QUOPS
0ehQsg2EXK+URJmmqM+uSzPRXV7bRg6wSQp7d/hBmV49O3jS32lO6TW2O2MpLia+
qy+HoN7UpBQ=
=kCTl
-----END PGP SIGNATURE-----
From pekkas@netcore.fi Wed Mar 17 08:26:49 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i2HDQm11012338
	for <saag@jis.mit.edu>; Wed, 17 Mar 2004 08:26:48 -0500 (EST)
Received: from netcore.fi (netcore.fi [193.94.160.1])i2HDQkWY020785
	for <saag@mit.edu>; Wed, 17 Mar 2004 08:26:47 -0500 (EST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i2HDQd309075;
	Wed, 17 Mar 2004 15:26:40 +0200
Date: Wed, 17 Mar 2004 15:26:39 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Subject: Re: [saag] Using IPsec to secure v6-over-v4 tunnels -- questions 
In-Reply-To: <20178.1079477944@marajade.sandelman.ottawa.on.ca>
Message-ID: <Pine.LNX.4.44.0403171519550.8411-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.613462
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 17 Mar 2004 13:26:49 -0000

On Tue, 16 Mar 2004, Michael Richardson wrote:
>     Pekka> IPv4 header - 20 bytes [next-header set to 41: implicit v6-over-v4]
>     Pekka> ESP header - 8 bytes
> 
>   (Surely you mean "next-header" is set on the ESP)

Correct, with next-header set to 41 in ESP.

>     Pekka> IPv6 header - 40 bytes
>     Pekka> [IPv6 payload]
> 
>   Uh, I don't understand.
>   The only way that I think one could have "IPv4 IPsec tunnel mode" 
> would be if one in fact had:
> 
>       IPv4 header  (protocol = ESP)
>         ESP header (protocol = IPIP,4) 
> 	  IPv4 header (protocol = 41)
> 	    IPv6 header

Why not protocol = 41 in ESP header, and omit the second IPv4 header?

I think this is supported by the spec.

>   Other than that, whether we call it tunnel or transport isn't very
> important, except at the key exchange level, where we have to have some
> agreement for the traffic selectors.

True enough -- I was mainly interested of the fact whether tunnel 
might be more widely implemented by VPN concentrators, compared to 
transport.

>     Pekka> 3) are there any policy setup/IKE issues if trying to set up
>     Pekka> policies for either mixed-protocol transforms or the
>     Pekka> transport mode issue, below?
> 
>   At the IKE level, I think that one would have to propose transport
> mode with IP protocol = 41 in today's implementation.
>   There is no descriptive reason why the "phase 1" IDs can't be IPv4
> while the "phase 2" IDs are IPv6, except that many implementations would
> not have code to accept this.
>   The outer IPv4s are implicitely used (in most cases) to signal what
> the src/dest for the outer IPv4/ESP packet. 

OK.

>     Pekka> 4) How well does IPsec deal with dynamic IPv4 addresses for one
>     Pekka> end-point (with or without NAT).  Does it provide triggers to the
>     Pekka> lower layers when the addresses change?
> 
>   You mean if the IPv4 address changes?

Yes -- the outmost IPv4 address changes at the host side; the "VPN 
concentrator's" address would be stable.

>   None. See MOBIKE WG.

Crap.  NAT traversal works, though, but gives no IP mobility.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


From kent@bbn.com Wed Mar 17 11:12:05 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i2HGC411015714
	for <saag@jis.mit.edu>; Wed, 17 Mar 2004 11:12:04 -0500 (EST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i2HGC3QM015456
	for <saag@mit.edu>; Wed, 17 Mar 2004 11:12:03 -0500 (EST)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i2HGBxMD017161;
	Wed, 17 Mar 2004 11:12:02 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06020402bc7e1d8c98f2@[128.89.89.75]>
In-Reply-To: <Pine.LNX.4.44.0403160835220.14004-100000@netcore.fi>
References: <Pine.LNX.4.44.0403160835220.14004-100000@netcore.fi>
Date: Wed, 17 Mar 2004 10:59:08 -0500
To: Pekka Savola <pekkas@netcore.fi>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] Using IPsec to secure v6-over-v4 tunnels -- questions
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.745344
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id
	i2HGC411015714
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 17 Mar 2004 16:12:06 -0000

At 8:48 AM +0200 3/16/04, Pekka Savola wrote:
>Hi,
>
>At v6ops, sometimes people has flashed the idea of using IPsec to
>secure IPv6-over-IPv4 tunneling (or some part of it).  This note looks
>at this in a bit more detail, and tries to raise a few questions (look
>at the end.)
>
>background
>----------
>
>How do we set up secure v6-over-v4 tunnels (in the control & data
>plane security sense) for client <-> tunnel-server communication? How
>feasible is this?

2401 does not require the inner and outer IP 
headers to be the same version of IP, so in 
principle one can do this now. Note 1 on page 32 
of RFC 2401 says this explicitly.

>I'm mostly interested in investigating whether IPsec could be used as
>a "transport mechanism" for traversing NATs or managing the
>"configured tunnel end-point setup" when the address is dynamic. 
>IPsec may not be feasible in all the scenarios, but if IPsec could be
>used to simplify a number of different cases, and security would come
>in as bonus, I guess it wouldn't hurt.. :)
>
>Basically, if you need data plane security (i.e., transport security),
>we go down to IPsec.  Some control plane security might be manageable
>with ad-hoc mechanisms, such as hashing/keying methods or return
>routability.
>
>Now, as for IPsec, there seem to be two ways to deal with this.
>
>approaches
>----------
>
>These would only secure the IPv6-in-IPv4 tunnel link, not give any
>kind of end-to-end encryption.  In a "road-warrior" -like case,
>tunneling back home, this could be enough.
>
>1) IPv4 IPsec tunnel mode with IPv6 payload transform, resulting to:
>
>(In both, I'm excluding the authentication part, or ESP padding.)
>
>IPv4 header - 20 bytes
>   ESP header - 8 bytes
>     IPv6 header - 40 bytes
>       [IPv6 payload]

yes, this is OK.

>2) IPv4 IPsec in transport mode with IPv4 transform, resulting to:
>
>IPv4 header - 20 bytes [next-header set to 41: implicit v6-over-v4]
>   ESP header - 8 bytes
>     IPv6 header - 40 bytes
>        [IPv6 payload]

Under 2401 this is not a legal layering, since we 
talk in terms of a "higher layer protocol" being 
the next protocol after an IP header, and IP 
doesn't meet that definition. The examples we 
give are TCP and UDP.

In 2401bis we have broadened the definition and 
talk about the "next layer protocol" instead. so 
it would be OK to have this layering.

>So, both the approaches seem to be equivalent.  Only, the mixed-IP
>version transforms, 1), is only supported by a couple of
>implementations, while I think 2) is more commonplace. 
>
>2) would additionally require a co-located configured tunnel
>management to the IPsec endpoints. If the method was used with dynamic
>addresses, this could be quite problematic, unless IPsec provides some
>triggers to "reconfigure" the configured tunnel to accommodate new
>tunnel-endpoint.  A different approach is having some kind of
>pseudo-interface which would not have these issues, but I think we
>already got out of those... :)
>
>So, the overhead of about 28 bytes compared to 20 of v6-over-v4
>tunnel in IP.
>
>If you encapsulate IPsec in UDP for NAT traversal, that's 8 additional
>bytes.  That part is commonly implemented.  Note that NAT traversal
>obviously only works when the other end-point has a public address.
>
>It seems a simple deployment for client <-> tunnel-server
>communication could be obtained using either mechanism, with 2)
>requiring zero implementation, only (rather complex) management for
>the tunnel-end point (if dynamic/NAT-traversed) in configured
>tunneling.  So, in a sense 1) gives you simplicity when ÍPsec has to
>deal with that particular dynamicity complexity.
>
>Are there any flaws or missing points in this analysis?  Thoughts?
>
>questions
>---------
>
>Procedural questions:
>
>   1) Do you think this work (i.e., documenting the possibilities,
>fleshing them out a bit) is useful, and should be done?  [if you want
>to work on it, feel free to say so as well :)]
>
>   2) Do you believe this is operationally sufficiently feasible to be
>worth exploring?  (I.e., would there be users which might use this
>mechanism if fleshed out.)
>
>Technical questions:
>
>  1) What is the implementation status of "mixed protocol transforms"? 
>(option 1 above).  This has several advantages, but has worse
>implementation status and may be more difficult from policy POV as
>well.
>
>  2) is there fundamental implementation (or otherwise) difference
>between tunnel and transport mode ESP especially at the VPN
>concentrators? (transport is not mandatory, but as for the rest, I
>don't know.)

tunnel mode, not transport, is what is generally 
implemented for VPNs. there is a significant 
security functionality difference between the two 
modes, because of the difference in what header 
info is examined re the SPD.

>  3) are there any policy setup/IKE issues if trying to set up policies
>for either mixed-protocol transforms or the transport mode issue,
>below?
>
>  4) How well does IPsec deal with dynamic IPv4 addresses for one
>end-point (with or without NAT).  Does it provide triggers to the
>lower layers when the addresses change?
>
>Feel free to respond off-list if you feel like it -- if there are
>sufficiently many replies, I'll summarize on the list.
>
>--
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>
>
>
>_______________________________________________
>saag mailing list
>saag@mit.edu
>https://jis.mit.edu/mailman/listinfo/saag


From mcr@sandelman.ottawa.on.ca Wed Mar 17 12:16:25 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i2HHGO11017588
	for <saag@jis.mit.edu>; Wed, 17 Mar 2004 12:16:24 -0500 (EST)
Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca
	[205.150.200.166])i2HHGJQM022001
	for <saag@mit.edu>; Wed, 17 Mar 2004 12:16:23 -0500 (EST)
Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca
	[205.150.200.247])i2HH6Sn23687verified OK);
	Wed, 17 Mar 2004 12:06:33 -0500 (EST)
Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1])
	i2HH6SlQ002222
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Wed, 17 Mar 2004 12:06:28 -0500
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	i2HH6Rfj002219;	Wed, 17 Mar 2004 12:06:27 -0500
To: Pekka Savola <pekkas@netcore.fi>
Subject: Re: [saag] Using IPsec to secure v6-over-v4 tunnels -- questions 
In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> 
	<Pine.LNX.4.44.0403171519550.8411-100000@netcore.fi> 
References: <Pine.LNX.4.44.0403171519550.8411-100000@netcore.fi> 
X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6)
Date: Wed, 17 Mar 2004 12:06:27 -0500
Message-ID: <2217.1079543187@marajade.sandelman.ottawa.on.ca>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.660700
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 17 Mar 2004 17:16:26 -0000

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Pekka" == Pekka Savola <pekkas@netcore.fi> writes:
    >> (Surely you mean "next-header" is set on the ESP)

    Pekka> Correct, with next-header set to 41 in ESP.

    Pekka> IPv6 header - 40 bytes
    Pekka> [IPv6 payload]
    >> 
    >> Uh, I don't understand.
    >> The only way that I think one could have "IPv4 IPsec tunnel mode" 
    >> would be if one in fact had:
    >> 
    >> IPv4 header  (protocol = ESP)
    >> ESP header (protocol = IPIP,4) 
    >> IPv4 header (protocol = 41)
    >> IPv6 header

    Pekka> Why not protocol = 41 in ESP header, and omit the second IPv4
    Pekka> header? 

    Pekka> I think this is supported by the spec.

  You miss the point.
  The distinction between transport and tunnel mode, when the thing
being transported is some kind of IP protocol is pretty fine. Some
would say that there is no difference between two - there isn't on the
wire. 
  There is, and it has has to do with how the traffic selectors are
chosen. (i.e. what's in the SPD).

  So, yes, putting protocol=41 in the ESP is the desired thing.
  (E.F.G.H / W.X.Y.Z are IPv4 addresses)

  This would essentially be tunnel mode, with mixed families:

    The selectors on the end-system side might look like:
     2002:c08b:2e21:3:2c0:4fff:fe96:430f/128 -> ::/0 => tunnel E.F.G.H->W.X.Y.Z

    the selectors on the gateway would be:
     :/0 -> 2002:c08b:2e21:3:2c0:4fff:fe96:430f/128  => tunnel W.X.Y.Z->E.F.G.H

  However, some might want to use a notion of transport mode, where they
write:

	E.F.G.H  -> W.X.Y.Z   (protocol=41)		=> transport to E
	W.X.Y.Z  -> E.F.G.H   (protocol=41)		=> transport to G

  and use some other mechanism to pick what is going to get encapsulated
into protocol 41 addressed to E/G.

  I think, that on a well integrated system, that these two things are
the same as well, but in too many cases, the IPsec SPD is seperate from
the policy routing table (is seperate from the firewall table).

    >> Other than that, whether we call it tunnel or transport isn't very
    >> important, except at the key exchange level, where we have to have some
    >> agreement for the traffic selectors.

    Pekka> True enough -- I was mainly interested of the fact whether tunnel 
    Pekka> might be more widely implemented by VPN concentrators, compared to 
    Pekka> transport.

  yes, it is. More widely tested for sure.

    Pekka> OK.

    Pekka> 4) How well does IPsec deal with dynamic IPv4 addresses for one
    Pekka> end-point (with or without NAT).  Does it provide triggers to the
    Pekka> lower layers when the addresses change?
    >> 
    >> You mean if the IPv4 address changes?

    Pekka> Yes -- the outmost IPv4 address changes at the host side; the "VPN 
    Pekka> concentrator's" address would be stable.

    >> None. See MOBIKE WG.

    Pekka> Crap.  NAT traversal works, though, but gives no IP mobility.

  And Francois Dupont has argued (correctly I think), that if one
permits the NAT-Traveral of IPsec to float to new IP addresses too
easily then it looks too much like a remote controlled DOS.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQFiFkYqHRg3pndX9AQFR8wQA76MDtVUs4bpFwey1yLJfGqIYxnq2maEI
qTr7qj6atXeyFb1sHtWYyABe85UvD+FvNlFhCPkSrVeVyw/hAaOtWLjYerTHUFMR
obD+XIA9PaSBspuAlTN8S2Vzv4LKgL6cghmF7xra/gPZXPtxGcHwJqCAauHGhGt2
0cm+Hh6aiCE=
=7d5w
-----END PGP SIGNATURE-----
From smb@research.att.com Wed Mar 31 14:13:30 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i2VJDT11001388
	for <saag@jis.mit.edu>; Wed, 31 Mar 2004 14:13:29 -0500 (EST)
Received: from mail-white.research.att.com (mail-red.research.att.com
	[192.20.225.110])i2VJDP2d018181
	for <saag@mit.edu>; Wed, 31 Mar 2004 14:13:25 -0500 (EST)
Received: from mail-green.research.att.com (mail-green.research.att.com
	[135.207.30.103])
	by mail-white.research.att.com (Postfix) with ESMTP id 6422B664134;
	Wed, 31 Mar 2004 14:13:22 -0500 (EST)
Received: from bigmail.research.att.com (bigmail.research.att.com
	[135.207.30.101])
	by mail-green.research.att.com (Postfix) with ESMTP id 546BDF3A91;
	Wed, 31 Mar 2004 14:13:22 -0500 (EST)
Received: from berkshire.research.att.com (guard.research.att.com
	[135.207.1.20])i2VJDLZ19291;	Wed, 31 Mar 2004 14:13:21 -0500 (EST)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 4BE787B44; Wed, 31 Mar 2004 14:13:30 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: Steve Bellovin <smb@research.att.com>
To: saag@mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 31 Mar 2004 14:13:30 -0500
Message-Id: <20040331191330.4BE787B44@berkshire.research.att.com>
Spam-Alum-Prob: 0.003247
Spam-Alum-Time: 0.523312
cc: zinin@psg.com
Subject: [saag] draft-iesg-tcpmd5app-00.txt 
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 31 Mar 2004 19:13:31 -0000

We'd like comments from the security community on draft-iesg-tcpmd5app-00.txt.
As things stand now, we're going to make a minor change to better 
describe the situation with respect to LDP; other than that, we're 
ready to progress the document.  Are there other issues?

		--Steve Bellovin, http://www.research.att.com/~smb


From mcr@sandelman.ottawa.on.ca Wed Mar 31 14:57:37 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i2VJvZ11002492
	for <saag@jis.mit.edu>; Wed, 31 Mar 2004 14:57:36 -0500 (EST)
Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca
	[205.150.200.166])i2VJvUUj015043
	for <saag@mit.edu>; Wed, 31 Mar 2004 14:57:32 -0500 (EST)
Received: from lox.sandelman.ottawa.on.ca
	(IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178])i2VJvEg28430
	verified OK)
	for <saag@mit.edu>; Wed, 31 Mar 2004 14:57:16 -0500 (EST)
Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca
	[205.150.200.247])i2VK0Wr05095verified OK)
	for <saag@mit.edu>; Wed, 31 Mar 2004 15:00:38 -0500 (EST)
Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1])
	i2VJt98o007557
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <saag@mit.edu>; Wed, 31 Mar 2004 14:55:09 -0500
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	i2VJt5Wi007554	for <saag@mit.edu>; Wed, 31 Mar 2004 14:55:09 -0500
To: saag@mit.edu
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt 
In-reply-to: Your message of "Wed, 31 Mar 2004 14:13:30 EST."
             <20040331191330.4BE787B44@berkshire.research.att.com> 
X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6)
Date: Wed, 31 Mar 2004 14:55:05 -0500
Message-ID: <7553.1080762905@marajade.sandelman.ottawa.on.ca>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Spam-Alum-Prob: 0.000079
Spam-Alum-Time: 0.552072
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 31 Mar 2004 19:57:38 -0000


okay, if I understood everything right:
      1) tcp-md5 is bad, do not advance it as general mechanism.
      2) BGP is good, even with tcp-md5.
      3) BGP needs security, can't advance without it.

Would an alternative to the variance be to include tcp-md5 into the BGP
document itself, and claim that it is for BGP use only?

How will BGP4 manage to get better security?

--
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

From kent@bbn.com Wed Mar 31 16:36:01 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i2VLa011004735
	for <saag@jis.mit.edu>; Wed, 31 Mar 2004 16:36:00 -0500 (EST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i2VLZv2d015151
	for <saag@mit.edu>; Wed, 31 Mar 2004 16:35:57 -0500 (EST)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i2VLZq7b026398;
	Wed, 31 Mar 2004 16:35:55 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0602040cbc90e23f7aee@[128.89.89.75]>
In-Reply-To: <20040331191330.4BE787B44@berkshire.research.att.com>
References: <20040331191330.4BE787B44@berkshire.research.att.com>
Date: Wed, 31 Mar 2004 16:34:47 -0500
To: Steve Bellovin <smb@research.att.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.625141
cc: zinin@psg.com
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 31 Mar 2004 21:36:01 -0000

Steve,

The text explaining why the MD5 checksum is not a good candidate for 
use in broader IETF protocol contexts is very well written.

The discussion of why BGP-4 can't easily change at this time to 
another integrity mechanism is also very good. However, when I looked 
quickly at the new BGP draft (intended to replace the extant RFC) I 
was unable to find any discussion of using the MD5 option. There are 
references to RFC 2385 in the discussion of what has changed, and in 
the security considerations section, and the normative references 
section. But a search on "MD5," "RFC 2385," "authentication," 
"integrity," or "security" does not point a reader to any text that 
says in any detail how to use this TCP option in the BGP context. The 
section entitled "TCP Options that may be used with BGP" makes no 
reference to it. Can someone point me to where the new BGP document 
actually says how this TCP option is used?

Also, I note that the document abstract says:

"Routing information exchanged via BGP supports only the destination-
    based forwarding paradigm, which assumes that a router forwards a
    packet based solely on the destination address carried in the IP
    header of the packet. This, in turn, reflects the set of policy
    decisions that can (and can not) be enforced using BGP. BGP can
    support only the policies conforming to the destination-based
    forwarding paradigm."

The term "solely" seems inappropriate, since it ignores the role that 
local policy plays in route selection, right? I think I know what the 
authors meant to say, but the text does not seem to be correct in 
this regard.

LDP is a much newer protocol and so there is less of a "large 
installed base that has been using this for years" sense. I am also 
disturbed that the LDP spec (RFC 3036) refers to this as a signature 
as well, and incorporates bad text from the old BGP RFC, e.g., "... 
acts like a signature for that segment .." further perpetuating the 
confusion between message authentication codes and digital 
signatures. Any chance we can get this fixed in both the BGP document 
before it progresses and in the next rev of 3036?


Steve

From kent@bbn.com Mon Apr  5 11:42:14 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i35FgD9V020439
	for <saag@jis.mit.edu>; Mon, 5 Apr 2004 11:42:13 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i35Fg8QW021182
	for <saag@mit.edu>; Mon, 5 Apr 2004 11:42:08 -0400 (EDT)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i35FfY7Z015027;
	Mon, 5 Apr 2004 11:41:35 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06020401bc97117f9c13@[128.89.89.75]>
In-Reply-To: <14514817.20040402190302@psg.com>
References: <20040331191330.4BE787B44@berkshire.research.att.com>
 <p0602040cbc90e23f7aee@[128.89.89.75]> <14514817.20040402190302@psg.com>
Date: Mon, 5 Apr 2004 09:49:49 -0400
To: Alex Zinin <zinin@psg.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt
Content-Type: multipart/alternative;
	boundary="============_-1130942848==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.783855
cc: Stephen Kent <kent@bbn.com>
cc: idr@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 05 Apr 2004 15:42:15 -0000

--============_-1130942848==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 7:03 PM -0800 4/2/04, Alex Zinin wrote:
>Steve-
>
>Thanks for looking at this. My comments inline below.
>
>I've added the IDR mailing list, since your comments cover the base spec as
>well.
>
>Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
>>  Steve,
>
>>  The text explaining why the MD5 checksum is not a good candidate for
>>  use in broader IETF protocol contexts is very well written.
>
>>  The discussion of why BGP-4 can't easily change at this time to
>>  another integrity mechanism is also very good. However, when I looked
>>  quickly at the new BGP draft (intended to replace the extant RFC) I
>>  was unable to find any discussion of using the MD5 option. There are
>>  references to RFC 2385 in the discussion of what has changed, and in
>>  the security considerations section, and the normative references
>>  section. But a search on "MD5," "RFC 2385," "authentication,"
>>  "integrity," or "security" does not point a reader to any text that
>>  says in any detail how to use this TCP option in the BGP context.
>
>As you said, the spec refers to the RFC 2385. RFC 2385 titled 
>"Protection of BGP
>Sessions via the TCP MD5 Signature Option", in turn, describes how the option
>can be used to secure a TCP sessions, for BGP in particular. Is 
>there something
>specific you were looking for?

the BGP document cites mandatory use of RFC 2385 as one of the 
changes, up front, but then never makes any reference to the RFC in 
the text. That's not a good way to communicate the intent of the 
change, i.e., the intent of the change has not been integrated into 
the body of the spec.

in the context of Steve Bellovin's document there is no reason to 
perpetuate the error of the RFC 2385 title, i.e., to continue to 
refer to the message authentication code created by the use of a 
shared secret and a hash function as a "signature."  One might even 
take this opportunity to point out that the title of the RFC is 
misleading and should not be confused with digital signature 
technologies.

>  > The
>>  section entitled "TCP Options that may be used with BGP" makes no
>>  reference to it. Can someone point me to where the new BGP document
>>  actually says how this TCP option is used?
>
>Appendix E "TCP options that may be used with BGP" could indeed 
>mention that the
>MD5 option can be used for BGP sessions. Yakov, please log this.
>
>>  Also, I note that the document abstract says:
>
>>  "Routing information exchanged via BGP supports only the destination-
>>      based forwarding paradigm, which assumes that a router forwards a
>>      packet based solely on the destination address carried in the IP
>>      header of the packet. This, in turn, reflects the set of policy
>>      decisions that can (and can not) be enforced using BGP. BGP can
>>      support only the policies conforming to the destination-based
>>      forwarding paradigm."
>
>>  The term "solely" seems inappropriate, since it ignores the role that
>>  local policy plays in route selection, right? I think I know what the
>>  authors meant to say, but the text does not seem to be correct in
>>  this regard.
>
>It seems that the abstract is correct, actually. Routers indeed _forward_
>packets using solely the destination address from the packet, as opposed to
>using say destination and source address, or even more granular forwarding
>decisions. Policies are taken into consideration when the RIB and FIB are
>constructed, which is not part of forwarding.

Good point.

>  > LDP is a much newer protocol and so there is less of a "large
>>  installed base that has been using this for years" sense.
>
>We do have quite considerable installed base for LDP and strictly speaking it
>has been there for a few years. So, though the statement may not 
>sound as strong
>when applied to LDP, it is correct.

then the text should say that LDP represents as big an installed base 
as BGP's use of MD5, if that is the case. If not, then find some 
accurate but similarly persuasive characterization that justifies 
this use. For contrast, RFC xxxx specifies use of MD5 in the same 
fashion for OSPF security, but nobody is suggesting that this be 
approved, presumably because there is no large, installed base, right?

>
>>   I am also
>>  disturbed that the LDP spec (RFC 3036) refers to this as a signature
>>  as well, and incorporates bad text from the old BGP RFC, e.g., "...
>>  acts like a signature for that segment .." further perpetuating the
>>  confusion between message authentication codes and digital
>>  signatures. Any chance we can get this fixed in both the BGP document
>>  before it progresses and in the next rev of 3036?
>
>The BGP spec (neither old nor new) does not include this 
>terminology, so I don't
>think we need to fix it from this perspective.
>
>Improvement of the LDP spec could be considered by the MPLS WG when it starts
>working on a new revision of the spec.
>
>Thank you.
>
>Alex

you are right that the primary focus of this discussion is 
progression of BGP. But, since you argued that LDP is appropriately 
included in the rationale discussion for this document, I assume you 
will want to progress that RFC too,
otherwise why bother mentioning it now?  I would rather not have to 
revisit this at that time, so I suggest you ask the MPLS WG to make a 
note of this error now.

Steve
--============_-1130942848==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [saag]
draft-iesg-tcpmd5app-00.txt</title></head><body>
<div>At 7:03 PM -0800 4/2/04, Alex Zinin wrote:</div>
<blockquote type="cite" cite>Steve-<br>
<br>
Thanks for looking at this. My comments inline below.<br>
<br>
I've added the IDR mailing list, since your comments cover the base
spec as<br>
well.<br>
<br>
Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:<br>
&gt; Steve,<br>
<br>
&gt; The text explaining why the MD5 checksum is not a good candidate
for<br>
&gt; use in broader IETF protocol contexts is very well written.<br>
<br>
&gt; The discussion of why BGP-4 can't easily change at this time
to<br>
&gt; another integrity mechanism is also very good. However, when I
looked<br>
&gt; quickly at the new BGP draft (intended to replace the extant RFC)
I<br>
&gt; was unable to find any discussion of using the MD5 option. There
are<br>
&gt; references to RFC 2385 in the discussion of what has changed, and
in<br>
&gt; the security considerations section, and the normative
references<br>
&gt; section. But a search on &quot;MD5,&quot; &quot;RFC 2385,&quot;
&quot;authentication,&quot;<br>
&gt; &quot;integrity,&quot; or &quot;security&quot; does not point a
reader to any text that<br>
&gt; says in any detail how to use this TCP option in the BGP
context.<br>
<br>
As you said, the spec refers to the RFC 2385. RFC 2385 titled
&quot;Protection of BGP<br>
Sessions via the TCP MD5 Signature Option&quot;, in turn, describes
how the option<br>
can be used to secure a TCP sessions, for BGP in particular. Is there
something</blockquote>
<blockquote type="cite" cite>specific you were looking
for?</blockquote>
<div><br></div>
<div>the BGP document cites mandatory use of RFC 2385 as one of the
changes, up front, but then never makes any reference to the RFC in
the text. That's not a good way to communicate the intent of the
change, i.e., the intent of the change has not been integrated into
the body of the spec.</div>
<div><br></div>
<div>in the context of Steve Bellovin's document there is no reason to
perpetuate the error of the RFC 2385 title, i.e., to continue to refer
to the message authentication code created by the use of a shared
secret and a hash function as a &quot;signature.&quot;&nbsp; One might
even take this opportunity to point out that the title of the RFC is
misleading and should not be confused with digital signature
technologies.</div>
<div><br></div>
<blockquote type="cite" cite>&gt; The<br>
&gt; section entitled &quot;TCP Options that may be used with BGP&quot;
makes no<br>
&gt; reference to it. Can someone point me to where the new BGP
document<br>
&gt; actually says how this TCP option is used?<br>
<br>
Appendix E &quot;TCP options that may be used with BGP&quot; could
indeed mention that the<br>
MD5 option can be used for BGP sessions. Yakov, please log this.<br>
<br>
&gt; Also, I note that the document abstract says:<br>
<br>
&gt; &quot;Routing information exchanged via BGP supports only the
destination-<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; based forwarding paradigm, which assumes
that a router forwards a<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; packet based solely on the destination
address carried in the IP<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; header of the packet. This, in turn,
reflects the set of policy<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; decisions that can (and can not) be
enforced using BGP. BGP can<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; support only the policies conforming to
the destination-based<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; forwarding paradigm.&quot;<br>
<br>
&gt; The term &quot;solely&quot; seems inappropriate, since it ignores
the role that<br>
&gt; local policy plays in route selection, right? I think I know what
the<br>
&gt; authors meant to say, but the text does not seem to be correct
in<br>
&gt; this regard.<br>
<br>
It seems that the abstract is correct, actually. Routers indeed
_forward_<br>
packets using solely the destination address from the packet, as
opposed to<br>
using say destination and source address, or even more granular
forwarding<br>
decisions. Policies are taken into consideration when the RIB and FIB
are<br>
constructed, which is not part of forwarding.</blockquote>
<div><br></div>
<div>Good point.</div>
<div><br></div>
<blockquote type="cite" cite>&gt; LDP is a much newer protocol and so
there is less of a &quot;large<br>
&gt; installed base that has been using this for years&quot;
sense.<br>
<br>
We do have quite considerable installed base for LDP and strictly
speaking it<br>
has been there for a few years. So, though the statement may not sound
as strong<br>
when applied to LDP, it is correct.</blockquote>
<div><br></div>
<div>then the text should say that LDP represents as big an installed
base as BGP's use of MD5, if that is the case. If not, then find some
accurate but similarly persuasive characterization that justifies this
use. For contrast, RFC xxxx specifies use of MD5 in the same fashion
for OSPF security, but nobody is suggesting that this be approved,
presumably because there is no large, installed base, right?</div>
<div><br></div>
<blockquote type="cite" cite><br>
&gt;&nbsp; I am also<br>
&gt; disturbed that the LDP spec (RFC 3036) refers to this as a
signature<br>
&gt; as well, and incorporates bad text from the old BGP RFC, e.g.,
&quot;...<br>
&gt; acts like a signature for that segment ..&quot; further
perpetuating the<br>
&gt; confusion between message authentication codes and digital<br>
&gt; signatures. Any chance we can get this fixed in both the BGP
document<br>
&gt; before it progresses and in the next rev of 3036?<br>
<br>
The BGP spec (neither old nor new) does not include this terminology,
so I don't</blockquote>
<blockquote type="cite" cite>think we need to fix it from this
perspective.
<blockquote><br></blockquote>
</blockquote>
<blockquote type="cite" cite>Improvement of the LDP spec could be
considered by the MPLS WG when it starts<br>
working on a new revision of the spec.<br>
<br>
Thank you.<br>
<br>
Alex</blockquote>
<div><br></div>
<div>you are right that the primary focus of this discussion is
progression of BGP. But, since you argued that LDP is appropriately
included in the rationale discussion for this document, I assume you
will want to progress that RFC too,</div>
<div>otherwise why bother mentioning it now?&nbsp; I would rather not
have to revisit this at that time, so I suggest you ask the MPLS WG to
make a note of this error now.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1130942848==_ma============--
From kent@bbn.com Wed Apr  7 11:10:59 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i37FAvAw025915
	for <saag@jis.mit.edu>; Wed, 7 Apr 2004 11:10:58 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i37FAuwu027494
	for <saag@mit.edu>; Wed, 7 Apr 2004 11:10:56 -0400 (EDT)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i37FAt7Z004992;
	Wed, 7 Apr 2004 11:10:56 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06020401bc99b101fea7@[128.89.89.75]>
In-Reply-To: <184815294.20040406162638@psg.com>
References: <20040331191330.4BE787B44@berkshire.research.att.com>
 <p0602040cbc90e23f7aee@[128.89.89.75]> <14514817.20040402190302@psg.com>
 <p06020401bc97117f9c13@[128.89.89.75]> <184815294.20040406162638@psg.com>
Date: Wed, 7 Apr 2004 11:09:53 -0400
To: Alex Zinin <zinin@psg.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.705464
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 07 Apr 2004 15:10:59 -0000

At 4:26 PM -0700 4/6/04, Alex Zinin wrote:
>Steve-
>
>>  the BGP document cites mandatory use of RFC 2385 as one of the
>>  changes, up front, but then never makes any reference to the RFC in
>>  the text. That's not a good way to communicate the intent of the
>>  change, i.e., the intent of the change has not been integrated into
>>  the body of the spec.
>
>It seems that you simply have missed the following reference in the "Security
>Considerations" section:
>
>  draft-ietf-idr-bgp4-23.txt:
>
>     The authentication mechanism that an implementation of BGP MUST sup-
>     port is specified in [RFC2385]. The authentication provided by this
>     mechanism could be done on a per peer basis.
>
>     BGP vulnerabilities analysis is discussed in [BGP_VULN].

No, I didn't miss it, Alex. I consider it a trivial reference that 
fails to do an adequate job. The Security Considerations section of a 
document is not where one first specifies a requirement for a 
protocol. It is a place to comment upon what has already been 
specified, putting it in context relative to security.

>  > in the context of Steve Bellovin's document there is no reason to
>>  perpetuate the error of the RFC 2385 title, i.e., to continue to
>>  refer to the message authentication code created by the use of a
>>  shared secret and a hash function as a "signature."  One might even
>>  take this opportunity to point out that the title of the RFC is
>>  misleading and should not be confused with digital signature
>>  technologies.
>
>My understanding is that Steve used the wording from the 2385's title on
>purpose, since we're talking about a specific document with a specific title,
>plus about a TCP option with a specific name (though now considered 
>misleading).

Alex, the terminology was always wrong, and I pointed that out to the 
IESG when the RFC was out for last call years ago. But Jeff Schiller 
apparently didn't think the terminology error was worth fixing, and I 
doubt that the rest of the IESG was concerned back then. Don't phrase 
this as though we're in the realm of revisionist political 
correctness. It was wrong then, and it's still wrong.

>	<SNIP>
>
>>  For contrast, RFC xxxx specifies use of MD5 in the same
>>  fashion for OSPF security, but nobody is suggesting that this be
>>  approved, presumably because there is no large, installed base, right?
>
>RFC 2328 includes the OSPF MD5 authentication option (similar to 
>TCP-MD5 in its
>transport nature). It's widely deployed and is a full IETF Standard. 
>If you mean
>"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of
>only one or two implementations.

Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, 
I was referring to 2238. We have a slightly odd situation here. 
Steve's document explains why BGP is being progressed even though it 
contains a normative reference to an RFC (TCP MD5 ...) that will not 
be progressed. The argument is that the latter RFC is technically 
poor, but it's not so awful to use it with BGP considering the 
context, because it is widely deployed, and because it is the only 
point-to-point authentication mechanism defined for BGP.  Then there 
is the minor mention of LDP at te end.

You suggest, above, that OSPF's use of MD5 is also widely deployed, 
something of which I was not aware. (Or did you just mean that many 
OSPF implementations support the feature, but you don't know if it is 
tuend on?) OSPF does not use the TCP MD5 option, but rather uses MD5 
in the same marginal way internally. So, in one sense there is no 
need to mention this in Steve's document, because it is just 
explaining why the IESG is making an exception for BGP, and LDP in 
the future. But, in a more fundamental sense, we have already 
endorsed the inappropriate use of MD5 in routing protocols in terms 
of OSPF, and we're merely continuing the tradition with BGP and LDP 
:-).

	<SNIP>

>  > you are right that the primary focus of this discussion is
>  > progression of BGP. But, since you argued that LDP is appropriately
>  > included in the rationale discussion for this document, I assume you
>  > will want to progress that RFC too,
>  > otherwise why bother mentioning it now?  I would rather not have to
>  > revisit this at that time, so I suggest you ask the MPLS WG to make a
>  > note of this error now.
>
>Looking at the LDP spec, it uses the word "signature" as part of the reference
>to the "TCP MD5 Signature Option", specified in 2385. While it could be argued
>that 2385 uses incorrect terminology, it would be confusing to refer to it as
>something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication
>Option", as this is not what 2385 specifies.


If you look at Steve's document, he uses the right terminology 
throughout, while referring to the document via its RFC number. 
That's a good model for any document that wants to avoid perpetuating 
the terminology error inherent in the title of 2385.

Steve

From smb@research.att.com Wed Apr  7 11:13:37 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i37FDaAw026029
	for <saag@jis.mit.edu>; Wed, 7 Apr 2004 11:13:37 -0400 (EDT)
Received: from mail-dark.research.att.com (mail-dark.research.att.com
	[192.20.225.112])i37FDPfR006530
	for <saag@mit.edu>; Wed, 7 Apr 2004 11:13:26 -0400 (EDT)
Received: from mail-blue.research.att.com (mail-blue.research.att.com
	[135.207.30.102])
	by mail-dark.research.att.com (Postfix) with ESMTP id 34C0BE80EF;
	Wed,  7 Apr 2004 11:13:24 -0400 (EDT)
Received: from bigmail.research.att.com (bigmail.research.att.com
	[135.207.30.101])
	by mail-blue.research.att.com (Postfix) with ESMTP id 2F15FF3A87;
	Wed,  7 Apr 2004 11:13:24 -0400 (EDT)
Received: from berkshire.research.att.com (guard.research.att.com
	[135.207.1.20])i37FDNZ17437;	Wed, 7 Apr 2004 11:13:23 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 9FA417B44; Wed,  7 Apr 2004 11:13:11 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt 
In-Reply-To: Your message of "Wed, 07 Apr 2004 11:09:53 EDT."
             <p06020401bc99b101fea7@[128.89.89.75]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 07 Apr 2004 11:13:10 -0400
Message-Id: <20040407151311.9FA417B44@berkshire.research.att.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.553184
cc: saag@mit.edu
cc: Alex Zinin <zinin@psg.com>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 07 Apr 2004 15:13:38 -0000

In message <p06020401bc99b101fea7@[128.89.89.75]>, Stephen Kent writes:

>If you look at Steve's document, he uses the right terminology 
>throughout, while referring to the document via its RFC number. 
>That's a good model for any document that wants to avoid perpetuating 
>the terminology error inherent in the title of 2385.
>

It's probably worth putting a note in my document noting the erroneous 
terminology in the title of 2385.  It's not a bad idea having a similar 
parenthetical note in the bgp document.

		--Steve Bellovin, http://www.research.att.com/~smb


From rja@extremenetworks.com Thu Apr  8 20:43:06 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i390h0Aw012834
	for <saag@jis.mit.edu>; Thu, 8 Apr 2004 20:43:05 -0400 (EDT)
Received: from gnat.inet.org (rrcs-midsouth-24-172-58-252.biz.rr.com
	[24.172.58.252])i390gxpe003075
	for <saag@mit.edu>; Thu, 8 Apr 2004 20:42:59 -0400 (EDT)
Received: from [10.0.8.132] (unknown [10.0.8.132])
	by gnat.inet.org (Postfix) with ESMTP
	id 96DCC67109; Thu,  8 Apr 2004 21:08:44 -0400 (EDT)
In-Reply-To: <p06020401bc99b101fea7@[128.89.89.75]>
References: <20040331191330.4BE787B44@berkshire.research.att.com>
	<p0602040cbc90e23f7aee@[128.89.89.75]> <14514817.20040402190302@psg.com>
	<p06020401bc97117f9c13@[128.89.89.75]> <184815294.20040406162638@psg.com>
	<p06020401bc99b101fea7@[128.89.89.75]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D7301DA2-89BE-11D8-95C9-00039357A82A@extremenetworks.com>
Content-Transfer-Encoding: 7bit
From: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt
Date: Thu, 8 Apr 2004 20:42:55 -0400
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.613)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.583549
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 09 Apr 2004 00:43:06 -0000


On Apr 07, 2004, at 11:09, Stephen Kent wrote:
> You suggest, above, that OSPF's use of MD5 is also widely deployed, 
> something of which I was not aware. (Or did you just mean that many 
> OSPF implementations support the feature, but you don't know if it is 
> tuend on?)

I believe that most shipping OSPF implementations have supported
its MD5 authentication option for some years now.  I also believe
that OSPF MD5 is reasonably widely, though not universally,
deployed, both now and for the past several years.

Absent something that is both better and practical to implement/deploy
(NB: OSPF with Digital Signatures has proven to be impractical to
implement or deploy in commercial IP networks), OSPF MD5 provides
significant very useful risk reduction.

Some few of us here are focused on ways that we can reduce operational
risk today, rather than ignore the current risk.  Other folks mileage
might well vary.

Cheers,

Ran
rja@extremenetworks.com

From kent@bbn.com Fri Apr  9 11:48:30 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i39FmPAw001142
	for <saag@jis.mit.edu>; Fri, 9 Apr 2004 11:48:29 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i39FmOKj000108
	for <saag@mit.edu>; Fri, 9 Apr 2004 11:48:24 -0400 (EDT)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i39Fll7X028058;
	Fri, 9 Apr 2004 11:47:47 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0602040bbc9c72e16f3d@[128.89.89.75]>
In-Reply-To: <1653165747.20040408171556@psg.com>
References: <20040331191330.4BE787B44@berkshire.research.att.com>
 <p0602040cbc90e23f7aee@[128.89.89.75]> <14514817.20040402190302@psg.com>
 <p06020401bc97117f9c13@[128.89.89.75]> <184815294.20040406162638@psg.com>
 <p06020401bc99b101fea7@[128.89.89.75]> <1653165747.20040408171556@psg.com>
Date: Fri, 9 Apr 2004 11:40:58 -0400
To: Alex Zinin <zinin@psg.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.680170
cc: idr@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 09 Apr 2004 15:48:31 -0000

Alex,

>	<SNIP>
>
>
>Steve, would you mind making a suggestion on how the text could be improved?
>E.g., would a separate section in the main body of the document specifying
>the requirement for TCP-MD5 support be useful?

A reasonable approach would be to have a section of the document that 
describes the use of this TCP option. It should explain why/when one 
would use the option in the context of BGP links and what protection 
it offers. Somewhere there should be a discussion of precautions 
should be taken re selection and use of keys, but maybe this is more 
of a BCP matter than a protocol standards matter.

>	<SNIP>
>
>I didn't mean to argue whether the terminology is right or wrong, 
>I'll leave up
>to you guys. My point was that we have to use the actual title of the document
>when referring to it, even though the title may not accurately describe what's
>inside. Anyway, Steve suggested that a clarifying note is put in the docs...

actually, one often refers to an RFC by number in the text, and 
includes the title only in the references section.

>	<SNIP>
>  > But, in a more fundamental sense, we have already
>>  endorsed the inappropriate use of MD5 in routing protocols in terms
>>  of OSPF, and we're merely continuing the tradition with BGP and LDP
>>  :-).
>
>It seems a discussion on why MD5 is inappropriate or insufficient in
>routing protocols would be interesting if we take it to RPSEC.
>

of course the issue is not MD5 per se, but the use of MD5 plus a 
secret bit string as a message authentication code, instead of HMAC, 
in any context.

Steve
From kent@bbn.com Fri Apr  9 11:48:33 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i39FmWAw001146
	for <saag@jis.mit.edu>; Fri, 9 Apr 2004 11:48:32 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i39FmVKj000233
	for <saag@mit.edu>; Fri, 9 Apr 2004 11:48:31 -0400 (EDT)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i39Fll7b028058;
	Fri, 9 Apr 2004 11:47:50 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0602040dbc9c7531f9ec@[128.89.89.75]>
In-Reply-To: <D7301DA2-89BE-11D8-95C9-00039357A82A@extremenetworks.com>
References: <20040331191330.4BE787B44@berkshire.research.att.com>
 <p0602040cbc90e23f7aee@[128.89.89.75]> <14514817.20040402190302@psg.com>
 <p06020401bc97117f9c13@[128.89.89.75]> <184815294.20040406162638@psg.com>
 <p06020401bc99b101fea7@[128.89.89.75]>
 <D7301DA2-89BE-11D8-95C9-00039357A82A@extremenetworks.com>
Date: Fri, 9 Apr 2004 11:46:57 -0400
To: RJ Atkinson <rja@extremenetworks.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.547031
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 09 Apr 2004 15:48:34 -0000

At 8:42 PM -0400 4/8/04, RJ Atkinson wrote:
>	<SNIP>
>
>Absent something that is both better and practical to implement/deploy
>(NB: OSPF with Digital Signatures has proven to be impractical to
>implement or deploy in commercial IP networks), OSPF MD5 provides
>significant very useful risk reduction.
>
>Some few of us here are focused on ways that we can reduce operational
>risk today, rather than ignore the current risk.  Other folks mileage
>might well vary.
>
>Cheers,
>
>Ran
>rja@extremenetworks.com

Ran,

here are some questions relevant to the reducing operational risk 
focus of your comments:

	-  how do you think operators choose the keys used with MD5 in OSPF?

	- how often are those keys changed

	- are they unique for each link, or common for all links in a net?


Steve
From smb@research.att.com Fri Apr  9 14:38:47 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i39IckAw005206
	for <saag@jis.mit.edu>; Fri, 9 Apr 2004 14:38:46 -0400 (EDT)
Received: from mail-dark.research.att.com (mail-dark.research.att.com
	[192.20.225.112])i39IcjCL029761
	for <saag@mit.edu>; Fri, 9 Apr 2004 14:38:45 -0400 (EDT)
Received: from mail-blue.research.att.com (mail-blue.research.att.com
	[135.207.30.102])
	by mail-dark.research.att.com (Postfix) with ESMTP id 5A606E80DB;
	Fri,  9 Apr 2004 14:38:45 -0400 (EDT)
Received: from bigmail.research.att.com (bigmail.research.att.com
	[135.207.30.101])
	by mail-blue.research.att.com (Postfix) with ESMTP id 48779F3A88;
	Fri,  9 Apr 2004 14:38:45 -0400 (EDT)
Received: from berkshire.research.att.com (raptor.research.att.com
	[135.207.23.32])i39IciZ00505;	Fri, 9 Apr 2004 14:38:44 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 96EF67B44; Fri,  9 Apr 2004 14:38:25 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt 
In-Reply-To: Your message of "Fri, 09 Apr 2004 11:46:57 EDT."
             <p0602040dbc9c7531f9ec@[128.89.89.75]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 09 Apr 2004 14:38:25 -0400
Message-Id: <20040409183825.96EF67B44@berkshire.research.att.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.553392
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 09 Apr 2004 18:38:47 -0000

In message <p0602040dbc9c7531f9ec@[128.89.89.75]>, Stephen Kent writes:
>At 8:42 PM -0400 4/8/04, RJ Atkinson wrote:
>>	<SNIP>
>>
>>Absent something that is both better and practical to implement/deploy
>>(NB: OSPF with Digital Signatures has proven to be impractical to
>>implement or deploy in commercial IP networks), OSPF MD5 provides
>>significant very useful risk reduction.
>>
>>Some few of us here are focused on ways that we can reduce operational
>>risk today, rather than ignore the current risk.  Other folks mileage
>>might well vary.
>>
>>Cheers,
>>
>>Ran
>>rja@extremenetworks.com
>
>Ran,
>
>here are some questions relevant to the reducing operational risk 
>focus of your comments:
>
>	-  how do you think operators choose the keys used with MD5 in OSPF?
>
>	- how often are those keys changed
>
>	- are they unique for each link, or common for all links in a net?
>

There's some relevant discussion in RFC 3562.


		--Steve Bellovin, http://www.research.att.com/~smb


From kent@bbn.com Fri Apr  9 16:03:25 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i39K3OAw007316
	for <saag@jis.mit.edu>; Fri, 9 Apr 2004 16:03:24 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i39K3NF8014573
	for <saag@mit.edu>; Fri, 9 Apr 2004 16:03:24 -0400 (EDT)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i39K2h7Z014011;
	Fri, 9 Apr 2004 16:02:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0602041abc9ca0c43051@[128.89.89.75]>
In-Reply-To: <20040409183825.96EF67B44@berkshire.research.att.com>
References: <20040409183825.96EF67B44@berkshire.research.att.com>
Date: Fri, 9 Apr 2004 14:52:18 -0400
To: "Steven M. Bellovin" <smb@research.att.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.572428
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 09 Apr 2004 20:03:26 -0000

At 2:38 PM -0400 4/9/04, Steven M. Bellovin wrote:
>In message <p0602040dbc9c7531f9ec@[128.89.89.75]>, Stephen Kent writes:
>>At 8:42 PM -0400 4/8/04, RJ Atkinson wrote:
>>>	<SNIP>
>>>
>>>Absent something that is both better and practical to implement/deploy
>>>(NB: OSPF with Digital Signatures has proven to be impractical to
>>>implement or deploy in commercial IP networks), OSPF MD5 provides
>>>significant very useful risk reduction.
>>>
>>>Some few of us here are focused on ways that we can reduce operational
>>>risk today, rather than ignore the current risk.  Other folks mileage
>>>might well vary.
>>>
>>>Cheers,
>>>
>>>Ran
>>>rja@extremenetworks.com
>>
>>Ran,
>>
>>here are some questions relevant to the reducing operational risk
>>focus of your comments:
>>
>>	-  how do you think operators choose the keys used with MD5 in OSPF?
>>
>>	- how often are those keys changed
>>
>>	- are they unique for each link, or common for all links in a net?
>>
>
>There's some relevant discussion in RFC 3562.

That RFC focuses on BGP, and there is is potentially harder to 
manages the keys because different parties are at each of of E-BGP 
links. But, my question to Ran was what he believed practice to be in 
OSPF, relative to the reduced operational risk criteria he cited.

Steve
From rja@extremenetworks.com Sat Apr 10 10:47:45 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i3AEldAw029278
	for <saag@jis.mit.edu>; Sat, 10 Apr 2004 10:47:44 -0400 (EDT)
Received: from gnat.inet.org (rrcs-midsouth-24-172-58-252.biz.rr.com
	[24.172.58.252])i3AElc12008214
	for <saag@mit.edu>; Sat, 10 Apr 2004 10:47:38 -0400 (EDT)
Received: from [10.38.0.86] (unknown [10.38.0.86])
	by gnat.inet.org (Postfix) with ESMTP
	id 4E4E367106; Sat, 10 Apr 2004 11:13:41 -0400 (EDT)
In-Reply-To: <20040409183825.96EF67B44@berkshire.research.att.com>
References: <20040409183825.96EF67B44@berkshire.research.att.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F5F907D2-8AFD-11D8-8DC2-00039357A82A@extremenetworks.com>
Content-Transfer-Encoding: 7bit
From: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt 
Date: Sat, 10 Apr 2004 10:47:16 -0400
To: "Steven M. Bellovin" <smb@research.att.com>
X-Mailer: Apple Mail (2.613)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.620113
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 10 Apr 2004 14:47:46 -0000

In message <p0602040dbc9c7531f9ec@[128.89.89.75]>, Stephen Kent writes:
> here are some questions relevant to the reducing operational risk
> focus of your comments:
>
> 	-  how do you think operators choose the keys used with MD5 in OSPF?
>
> 	- how often are those keys changed
>
> 	- are they unique for each link, or common for all links in a net?

(The original of Steve Kent's note never reached me, so I'm replying
to the bits that were quoted in smb's subsequent note.)

Not being omniscient myself, I can't speak for the whole world.
Within my own first-hand knowledge, there are a range of practices.
	- Key change frequency varies and depends on the practices
		of the given organisation/network.  I know of networks
		where the keys change daily or more frequently.  I also
		know of networks where key change is far less frequent.
	- Key choice methodology also varies.  Some folks use PRNG
		or RNG techniques, while others choose passwords and
		run them through a cryptographic hash to create a key;
		no doubt other techniques are also used in some places.
	- Whether keying is per-link or per-net also varies.  I've
		seen both deployed in real networks.

An important fact though, even if one uses a single poorly-chosen
key, never changes keys, and uses a single-key per-network (which
are not choices I would make myself), is that OSPF with MD5 
authentication
is protected against passive eavesdropping attacks.  The only other
deployable OSPF authentication choices today are (1) no authentication
or (2) clear-text password authentication.  No authentication is 
obviously
bogon.  While clear-text password authentication is widely known to be
vulnerable to simple passive attacks.

In a world where OSPF with Digital Signatures were deployable, that
would clearly be a better choice, but we don't seem to be in that world
right now.

And I'd encourage anyone with free time to see if they can't devise
something that is both better than OSPF MD5 and still practical to
deploy today and then get (whichever IETF WG applies) to consider
openly specifying that method for the community.  There will always
be room for improvement.

And by the way, RIP MD5 and RSVP MD5 have largely the same issues
and limitations of OSPF MD5 -- along with the same fundamental
benefits.  So if folks have free time, those are also areas where
someone might well be able to come up with a better approach and
get it through (whichever IETF WG applies) respectively.

Ran
rja@extremenetworks.com

From kent@bbn.com Fri Apr 16 18:52:34 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i3GMqXAw019518
	for <saag@jis.mit.edu>; Fri, 16 Apr 2004 18:52:33 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i3GMqMBg014609
	for <saag@mit.edu>; Fri, 16 Apr 2004 18:52:24 -0400 (EDT)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3GMpn7X007020;
	Fri, 16 Apr 2004 18:51:50 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06100500bca613b43bd1@[128.89.89.75]>
In-Reply-To: <200404142038.i3EKcHJ88016@merlot.juniper.net>
References: <200404142038.i3EKcHJ88016@merlot.juniper.net>
Date: Fri, 16 Apr 2004 18:50:54 -0400
To: Yakov Rekhter <yakov@juniper.net>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.530636
cc: Alex Zinin <zinin@psg.com>
cc: idr@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 16 Apr 2004 22:52:35 -0000

At 1:38 PM -0700 4/14/04, Yakov Rekhter wrote:
>Steve,
>
>>  >	<SNIP>
>>  >
>>  >
>>  >Steve, would you mind making a suggestion on how the text could 
>>be improved?
>>  >E.g., would a separate section in the main body of the document specifying
>>  >the requirement for TCP-MD5 support be useful?
>>
>>  A reasonable approach would be to have a section of the document that
>>  describes the use of this TCP option. It should explain why/when one
>>  would use the option in the context of BGP links and what protection
>>  it offers.
>
>Would you please produce the appropriate text for this section.
>
>Thanks in advance.
>
>Yakov.

I'll try to provide some text when I return from vacation, in early May.

Steve
From zinin@psg.com Fri Apr  2 22:03:07 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i333369V011853
	for <saag@jis.mit.edu>; Fri, 2 Apr 2004 22:03:06 -0500 (EST)
Received: from psg.com (psg.com [147.28.0.62])i333351g002839
	for <saag@mit.edu>; Fri, 2 Apr 2004 22:03:05 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1])
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1B9bR2-000LIY-CX; Sat, 03 Apr 2004 03:03:04 +0000
From: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <14514817.20040402190302@psg.com>
To: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt
In-Reply-To: <p0602040cbc90e23f7aee@[128\.89\.89\.75]>
References: <20040331191330.4BE787B44@berkshire.research.att.com>
 <p0602040cbc90e23f7aee@[128.89.89.75]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.670008
X-Mailman-Approved-At: Tue, 04 May 2004 00:05:11 -0400
cc: idr@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Alex Zinin <zinin@psg.com>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Sat, 03 Apr 2004 03:03:07 -0000
X-Original-Date: Fri, 2 Apr 2004 19:03:02 -0800
X-List-Received-Date: Sat, 03 Apr 2004 03:03:07 -0000

Steve-

Thanks for looking at this. My comments inline below.

I've added the IDR mailing list, since your comments cover the base spec as
well.

Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
> Steve,

> The text explaining why the MD5 checksum is not a good candidate for 
> use in broader IETF protocol contexts is very well written.

> The discussion of why BGP-4 can't easily change at this time to 
> another integrity mechanism is also very good. However, when I looked 
> quickly at the new BGP draft (intended to replace the extant RFC) I 
> was unable to find any discussion of using the MD5 option. There are 
> references to RFC 2385 in the discussion of what has changed, and in 
> the security considerations section, and the normative references 
> section. But a search on "MD5," "RFC 2385," "authentication," 
> "integrity," or "security" does not point a reader to any text that
> says in any detail how to use this TCP option in the BGP context.

As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP
Sessions via the TCP MD5 Signature Option", in turn, describes how the option
can be used to secure a TCP sessions, for BGP in particular. Is there something
specific you were looking for?

> The
> section entitled "TCP Options that may be used with BGP" makes no 
> reference to it. Can someone point me to where the new BGP document 
> actually says how this TCP option is used?

Appendix E "TCP options that may be used with BGP" could indeed mention that the
MD5 option can be used for BGP sessions. Yakov, please log this.

> Also, I note that the document abstract says:

> "Routing information exchanged via BGP supports only the destination-
>     based forwarding paradigm, which assumes that a router forwards a
>     packet based solely on the destination address carried in the IP
>     header of the packet. This, in turn, reflects the set of policy
>     decisions that can (and can not) be enforced using BGP. BGP can
>     support only the policies conforming to the destination-based
>     forwarding paradigm."

> The term "solely" seems inappropriate, since it ignores the role that 
> local policy plays in route selection, right? I think I know what the 
> authors meant to say, but the text does not seem to be correct in 
> this regard.

It seems that the abstract is correct, actually. Routers indeed _forward_
packets using solely the destination address from the packet, as opposed to
using say destination and source address, or even more granular forwarding
decisions. Policies are taken into consideration when the RIB and FIB are
constructed, which is not part of forwarding.

> LDP is a much newer protocol and so there is less of a "large 
> installed base that has been using this for years" sense.

We do have quite considerable installed base for LDP and strictly speaking it
has been there for a few years. So, though the statement may not sound as strong
when applied to LDP, it is correct.

>  I am also 
> disturbed that the LDP spec (RFC 3036) refers to this as a signature 
> as well, and incorporates bad text from the old BGP RFC, e.g., "... 
> acts like a signature for that segment .." further perpetuating the 
> confusion between message authentication codes and digital 
> signatures. Any chance we can get this fixed in both the BGP document 
> before it progresses and in the next rev of 3036?

The BGP spec (neither old nor new) does not include this terminology, so I don't
think we need to fix it from this perspective.

Improvement of the LDP spec could be considered by the MPLS WG when it starts
working on a new revision of the spec.

Thank you.

Alex

From zinin@psg.com Tue Apr  6 19:26:44 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i36NQh9V002988
	for <saag@jis.mit.edu>; Tue, 6 Apr 2004 19:26:43 -0400 (EDT)
Received: from psg.com (psg.com [147.28.0.62])i36NQfcP017310
	for <saag@mit.edu>; Tue, 6 Apr 2004 19:26:41 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1])
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BAzxo-0005Vo-8j; Tue, 06 Apr 2004 23:26:40 +0000
From: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <184815294.20040406162638@psg.com>
To: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt
In-Reply-To: <p06020401bc97117f9c13@[128\.89\.89\.75]>
References: <20040331191330.4BE787B44@berkshire.research.att.com>
 <p0602040cbc90e23f7aee@[128.89.89.75]> <14514817.20040402190302@psg.com>
 <p06020401bc97117f9c13@[128.89.89.75]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.663426
X-Mailman-Approved-At: Tue, 04 May 2004 00:05:11 -0400
cc: idr@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Alex Zinin <zinin@psg.com>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Tue, 06 Apr 2004 23:26:44 -0000
X-Original-Date: Tue, 6 Apr 2004 16:26:38 -0700
X-List-Received-Date: Tue, 06 Apr 2004 23:26:44 -0000

Steve-

> the BGP document cites mandatory use of RFC 2385 as one of the 
> changes, up front, but then never makes any reference to the RFC in 
> the text. That's not a good way to communicate the intent of the 
> change, i.e., the intent of the change has not been integrated into 
> the body of the spec.

It seems that you simply have missed the following reference in the "Security
Considerations" section:

 draft-ietf-idr-bgp4-23.txt:

    The authentication mechanism that an implementation of BGP MUST sup-
    port is specified in [RFC2385]. The authentication provided by this
    mechanism could be done on a per peer basis.

    BGP vulnerabilities analysis is discussed in [BGP_VULN].

> in the context of Steve Bellovin's document there is no reason to
> perpetuate the error of the RFC 2385 title, i.e., to continue to 
> refer to the message authentication code created by the use of a 
> shared secret and a hash function as a "signature."  One might even 
> take this opportunity to point out that the title of the RFC is 
> misleading and should not be confused with digital signature 
> technologies.

My understanding is that Steve used the wording from the 2385's title on
purpose, since we're talking about a specific document with a specific title,
plus about a TCP option with a specific name (though now considered misleading).

>>  > LDP is a much newer protocol and so there is less of a "large
>>>  installed base that has been using this for years" sense.
>>
>>We do have quite considerable installed base for LDP and strictly speaking it
>>has been there for a few years. So, though the statement may not 
>>sound as strong
>>when applied to LDP, it is correct.

> then the text should say that LDP represents as big an installed base 
> as BGP's use of MD5, if that is the case. If not, then find some 
> accurate but similarly persuasive characterization that justifies 
> this use.

OK. We'll see if the wording can be improved.

> For contrast, RFC xxxx specifies use of MD5 in the same 
> fashion for OSPF security, but nobody is suggesting that this be 
> approved, presumably because there is no large, installed base, right?

RFC 2328 includes the OSPF MD5 authentication option (similar to TCP-MD5 in its
transport nature). It's widely deployed and is a full IETF Standard. If you mean
"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of
only one or two implementations.

>>>   I am also
>>>  disturbed that the LDP spec (RFC 3036) refers to this as a signature
>>>  as well, and incorporates bad text from the old BGP RFC, e.g., "...
>>>  acts like a signature for that segment .." further perpetuating the
>>>  confusion between message authentication codes and digital
>>>  signatures. Any chance we can get this fixed in both the BGP document
>>>  before it progresses and in the next rev of 3036?
>>
>>The BGP spec (neither old nor new) does not include this 
>>terminology, so I don't
>>think we need to fix it from this perspective.
>>
>>Improvement of the LDP spec could be considered by the MPLS WG when it starts
>>working on a new revision of the spec.
>>
>>Thank you.
>>
>>Alex

> you are right that the primary focus of this discussion is 
> progression of BGP. But, since you argued that LDP is appropriately 
> included in the rationale discussion for this document, I assume you 
> will want to progress that RFC too,
> otherwise why bother mentioning it now?  I would rather not have to 
> revisit this at that time, so I suggest you ask the MPLS WG to make a 
> note of this error now.

Looking at the LDP spec, it uses the word "signature" as part of the reference
to the "TCP MD5 Signature Option", specified in 2385. While it could be argued
that 2385 uses incorrect terminology, it would be confusing to refer to it as
something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication
Option", as this is not what 2385 specifies.

Thanks

Alex

From zinin@psg.com Thu Apr  8 20:16:00 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i390FxAw012385
	for <saag@jis.mit.edu>; Thu, 8 Apr 2004 20:15:59 -0400 (EDT)
Received: from psg.com (psg.com [147.28.0.62])i390Fwpe013736
	for <saag@mit.edu>; Thu, 8 Apr 2004 20:15:58 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1])
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1BBjgb-000J8k-1f; Fri, 09 Apr 2004 00:15:57 +0000
From: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <1653165747.20040408171556@psg.com>
To: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] draft-iesg-tcpmd5app-00.txt
In-Reply-To: <p06020401bc99b101fea7@[128\.89\.89\.75]>
References: <20040331191330.4BE787B44@berkshire.research.att.com>
 <p0602040cbc90e23f7aee@[128.89.89.75]> <14514817.20040402190302@psg.com>
 <p06020401bc97117f9c13@[128.89.89.75]> <184815294.20040406162638@psg.com>
 <p06020401bc99b101fea7@[128.89.89.75]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.754146
X-Mailman-Approved-At: Tue, 04 May 2004 00:05:12 -0400
cc: idr@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Alex Zinin <zinin@psg.com>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Fri, 09 Apr 2004 00:16:01 -0000
X-Original-Date: Thu, 8 Apr 2004 17:15:56 -0700
X-List-Received-Date: Fri, 09 Apr 2004 00:16:01 -0000

Steve-

 [putting IDR back on the Cc: list--I'd like the WG to be in the loop]

Wednesday, April 7, 2004, 8:09:53 AM, Stephen Kent wrote:
> At 4:26 PM -0700 4/6/04, Alex Zinin wrote:
>>Steve-
>>
>>>  the BGP document cites mandatory use of RFC 2385 as one of the
>>>  changes, up front, but then never makes any reference to the RFC in
>>>  the text. That's not a good way to communicate the intent of the
>>>  change, i.e., the intent of the change has not been integrated into
>>>  the body of the spec.
>>
>>It seems that you simply have missed the following reference in the "Security
>>Considerations" section:
>>
>>  draft-ietf-idr-bgp4-23.txt:
>>
>>     The authentication mechanism that an implementation of BGP MUST sup-
>>     port is specified in [RFC2385]. The authentication provided by this
>>     mechanism could be done on a per peer basis.
>>
>>     BGP vulnerabilities analysis is discussed in [BGP_VULN].

> No, I didn't miss it, Alex. I consider it a trivial reference that 
> fails to do an adequate job. The Security Considerations section of a 
> document is not where one first specifies a requirement for a 
> protocol. It is a place to comment upon what has already been 
> specified, putting it in context relative to security.

Steve, would you mind making a suggestion on how the text could be improved?
E.g., would a separate section in the main body of the document specifying
the requirement for TCP-MD5 support be useful?

>>  > in the context of Steve Bellovin's document there is no reason to
>>>  perpetuate the error of the RFC 2385 title, i.e., to continue to
>>>  refer to the message authentication code created by the use of a
>>>  shared secret and a hash function as a "signature."  One might even
>>>  take this opportunity to point out that the title of the RFC is
>>>  misleading and should not be confused with digital signature
>>>  technologies.
>>
>>My understanding is that Steve used the wording from the 2385's title on
>>purpose, since we're talking about a specific document with a specific title,
>>plus about a TCP option with a specific name (though now considered 
>>misleading).

> Alex, the terminology was always wrong, and I pointed that out to the 
> IESG when the RFC was out for last call years ago. But Jeff Schiller 
> apparently didn't think the terminology error was worth fixing, and I 
> doubt that the rest of the IESG was concerned back then. Don't phrase 
> this as though we're in the realm of revisionist political 
> correctness. It was wrong then, and it's still wrong.

I didn't mean to argue whether the terminology is right or wrong, I'll leave up
to you guys. My point was that we have to use the actual title of the document
when referring to it, even though the title may not accurately describe what's
inside. Anyway, Steve suggested that a clarifying note is put in the docs...

>>	<SNIP>
>>
>>>  For contrast, RFC xxxx specifies use of MD5 in the same
>>>  fashion for OSPF security, but nobody is suggesting that this be
>>>  approved, presumably because there is no large, installed base, right?
>>
>>RFC 2328 includes the OSPF MD5 authentication option (similar to 
>>TCP-MD5 in its
>>transport nature). It's widely deployed and is a full IETF Standard. 
>>If you mean
>>"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of
>>only one or two implementations.

> Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, 
> I was referring to 2238. We have a slightly odd situation here. 
> Steve's document explains why BGP is being progressed even though it 
> contains a normative reference to an RFC (TCP MD5 ...) that will not 
> be progressed. The argument is that the latter RFC is technically 
> poor, but it's not so awful to use it with BGP considering the 
> context, because it is widely deployed, and because it is the only 
> point-to-point authentication mechanism defined for BGP.  Then there 
> is the minor mention of LDP at te end.

> You suggest, above, that OSPF's use of MD5 is also widely deployed, 
> something of which I was not aware. (Or did you just mean that many 
> OSPF implementations support the feature, but you don't know if it is 
> tuend on?)

All more-or-less mature OSPF implementations I know of certainly support the
feature. As for deployment, OSPF MD5 _is_ being used in both SP and enterprise
networks. I do not have numbers for you, but even as of 3-4 years ago (when I
worked close with operators on a regular basis), it was not uncommon to see it
configured.

> OSPF does not use the TCP MD5 option, but rather uses MD5 
> in the same marginal way internally. So, in one sense there is no 
> need to mention this in Steve's document, because it is just 
> explaining why the IESG is making an exception for BGP, and LDP in 
> the future.

Agreed.

> But, in a more fundamental sense, we have already 
> endorsed the inappropriate use of MD5 in routing protocols in terms 
> of OSPF, and we're merely continuing the tradition with BGP and LDP 
> :-).

It seems a discussion on why MD5 is inappropriate or insufficient in
routing protocols would be interesting if we take it to RPSEC.

Thanks.

Alex


> 	<SNIP>

>>  > you are right that the primary focus of this discussion is
>>  > progression of BGP. But, since you argued that LDP is appropriately
>>  > included in the rationale discussion for this document, I assume you
>>  > will want to progress that RFC too,
>>  > otherwise why bother mentioning it now?  I would rather not have to
>>  > revisit this at that time, so I suggest you ask the MPLS WG to make a
>>  > note of this error now.
>>
>>Looking at the LDP spec, it uses the word "signature" as part of the reference
>>to the "TCP MD5 Signature Option", specified in 2385. While it could be argued
>>that 2385 uses incorrect terminology, it would be confusing to refer to it as
>>something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication
>>Option", as this is not what 2385 specifies.


> If you look at Steve's document, he uses the right terminology 
> throughout, while referring to the document via its RFC number. 
> That's a good model for any document that wants to avoid perpetuating 
> the terminology error inherent in the title of 2385.

> Steve


From yakov@juniper.net Wed Apr 14 16:20:53 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i3EKKqAw005093
	for <saag@jis.mit.edu>; Wed, 14 Apr 2004 16:20:52 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net (colo-dns-ext1.juniper.net
	[207.17.137.57])i3EKKhiD021578
	for <saag@mit.edu>; Wed, 14 Apr 2004 16:20:44 -0400 (EDT)
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	i3EKK8l80756;	Wed, 14 Apr 2004 13:20:08 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKK3J85908;
	Wed, 14 Apr 2004 13:20:03 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Message-Id: <200404142020.i3EKK3J85908@merlot.juniper.net>
To: Alex Zinin <zinin@psg.com>
Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt 
In-Reply-To: Your message of "Fri, 02 Apr 2004 19:03:02 PST."
             <14514817.20040402190302@psg.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <39377.1081974003.1@juniper.net>
From: Yakov Rekhter <yakov@juniper.net>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.575818
X-Mailman-Approved-At: Tue, 04 May 2004 00:05:11 -0400
cc: Stephen Kent <kent@bbn.com>
cc: idr@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Wed, 14 Apr 2004 20:20:53 -0000
X-Original-Date: Wed, 14 Apr 2004 13:20:03 -0700
X-List-Received-Date: Wed, 14 Apr 2004 20:20:53 -0000

Alex,

> Thanks for looking at this. My comments inline below.
> 
> I've added the IDR mailing list, since your comments cover the base spec as
> well.
> 
> Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
> > Steve,
> 
> > The text explaining why the MD5 checksum is not a good candidate for 
> > use in broader IETF protocol contexts is very well written.
> 
> > The discussion of why BGP-4 can't easily change at this time to 
> > another integrity mechanism is also very good. However, when I looked 
> > quickly at the new BGP draft (intended to replace the extant RFC) I 
> > was unable to find any discussion of using the MD5 option. There are 
> > references to RFC 2385 in the discussion of what has changed, and in 
> > the security considerations section, and the normative references 
> > section. But a search on "MD5," "RFC 2385," "authentication," 
> > "integrity," or "security" does not point a reader to any text that
> > says in any detail how to use this TCP option in the BGP context.
> 
> As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of 
BGP
> Sessions via the TCP MD5 Signature Option", in turn, describes how the option
> can be used to secure a TCP sessions, for BGP in particular. Is there somethi
ng
> specific you were looking for?
> 
> > The
> > section entitled "TCP Options that may be used with BGP" makes no 
> > reference to it. Can someone point me to where the new BGP document 
> > actually says how this TCP option is used?
> 
> Appendix E "TCP options that may be used with BGP" could indeed mention that 
> the MD5 option can be used for BGP sessions. Yakov, please log this.

Sure.

Yakov.
From yakov@juniper.net Wed Apr 14 16:39:07 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i3EKd6Aw005604
	for <saag@jis.mit.edu>; Wed, 14 Apr 2004 16:39:06 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net (colo-dns-ext2.juniper.net
	[207.17.137.64])i3EKd4h7025391
	for <saag@mit.edu>; Wed, 14 Apr 2004 16:39:04 -0400 (EDT)
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	i3EKcHBm050895;	Wed, 14 Apr 2004 13:38:17 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3EKcHJ88016;
	Wed, 14 Apr 2004 13:38:17 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Message-Id: <200404142038.i3EKcHJ88016@merlot.juniper.net>
To: Stephen Kent <kent@bbn.com>
Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt 
In-Reply-To: Your message of "Fri, 09 Apr 2004 11:40:58 EDT."
             <p0602040bbc9c72e16f3d@[128.89.89.75]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <42356.1081975097.1@juniper.net>
From: Yakov Rekhter <yakov@juniper.net>
Spam-Alum-Prob: 0.000004
Spam-Alum-Time: 0.533624
X-Mailman-Approved-At: Tue, 04 May 2004 00:05:11 -0400
cc: Alex Zinin <zinin@psg.com>
cc: idr@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Wed, 14 Apr 2004 20:39:08 -0000
X-Original-Date: Wed, 14 Apr 2004 13:38:17 -0700
X-List-Received-Date: Wed, 14 Apr 2004 20:39:08 -0000

Steve,

> >	<SNIP>
> >
> >
> >Steve, would you mind making a suggestion on how the text could be improved?
> >E.g., would a separate section in the main body of the document specifying
> >the requirement for TCP-MD5 support be useful?
> 
> A reasonable approach would be to have a section of the document that 
> describes the use of this TCP option. It should explain why/when one 
> would use the option in the context of BGP links and what protection 
> it offers. 

Would you please produce the appropriate text for this section.

Thanks in advance.

Yakov.
From yakov@juniper.net Tue Apr 20 09:55:24 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i3KDtNAw001104
	for <saag@jis.mit.edu>; Tue, 20 Apr 2004 09:55:23 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net (colo-dns-ext2.juniper.net
	[207.17.137.64])i3KDtLAW011641
	for <saag@mit.edu>; Tue, 20 Apr 2004 09:55:22 -0400 (EDT)
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	i3KDsfBm078422;	Tue, 20 Apr 2004 06:54:41 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3KDsbJ39849;
	Tue, 20 Apr 2004 06:54:41 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Message-Id: <200404201354.i3KDsbJ39849@merlot.juniper.net>
To: Stephen Kent <kent@bbn.com>
Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt 
In-Reply-To: Your message of "Fri, 16 Apr 2004 18:50:54 EDT."
             <p06100500bca613b43bd1@[128.89.89.75]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <42557.1082469277.1@juniper.net>
Date: Tue, 20 Apr 2004 06:54:37 -0700
From: Yakov Rekhter <yakov@juniper.net>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.542529
X-Mailman-Approved-At: Tue, 04 May 2004 00:05:11 -0400
cc: Alex Zinin <zinin@psg.com>
cc: idr@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 20 Apr 2004 13:55:24 -0000

Steve,

> >>  >Steve, would you mind making a suggestion on how the text could 
> >>be improved?
> >>  >E.g., would a separate section in the main body of the document specifyi
ng
> >>  >the requirement for TCP-MD5 support be useful?
> >>
> >>  A reasonable approach would be to have a section of the document that
> >>  describes the use of this TCP option. It should explain why/when one
> >>  would use the option in the context of BGP links and what protection
> >>  it offers.
> >
> >Would you please produce the appropriate text for this section.
> >
> >Thanks in advance.
> >
> >Yakov.
> 
> I'll try to provide some text when I return from vacation, in early May.

Thanks !!! Looking forward to get the text.

Yakov.
From paul.hoffman@vpnc.org Fri May  7 12:33:09 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i47GX83a023121
	for <saag@jis.mit.edu>; Fri, 7 May 2004 12:33:08 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	i47GX4CM011234
	for <saag@mit.edu>; Fri, 7 May 2004 12:33:04 -0400 (EDT)
Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com
	[63.249.109.252])	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i47GWws6048786
	for <saag@mit.edu>; Fri, 7 May 2004 09:32:59 -0700 (PDT)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p06100514bcc16a6e3046@[10.20.30.249]>
Date: Fri, 7 May 2004 09:33:00 -0700
To: saag@mit.edu
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.625526
Subject: [saag] 
 Fwd: Last Call: 'SEcure Neighbor Discovery (SEND)' to Proposed
 Standard
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 07 May 2004 16:33:09 -0000

This is probably of interest to many folks in the IETF security 
community. The abstract says:

    IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
    other nodes on the link, to determine the link-layer addresses of
    other nodes on the link, to find routers, and to maintain
    reachability information about the paths to active neighbors. If not
    secured, NDP is vulnerable to various attacks.  This document
    specifies security mechanisms for NDP. Unlike to the original NDP
    specifications, these mechanisms do not make use of IPsec.


>X-test-idtracker: no
>To: IETF-Announce :;
>From: The IESG <iesg-secretary@ietf.org>
>Subject: Last Call: 'SEcure Neighbor Discovery (SEND)' to Proposed Standard
>Reply-to: iesg@ietf.org
>Date: Mon, 03 May 2004 13:15:17 -0400
>X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
>	ietf-mx.ietf.org
>X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no
>	version=2.60
>Sender: ietf-announce-admin@ietf.org
>X-BeenThere: ietf-announce@ietf.org
>X-Mailman-Version: 2.0.12
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
>List-Id: <ietf-announce.ietf.org>
>List-Post: <mailto:ietf-announce@ietf.org>
>List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:ietf-announce-request@ietf.org?subject=subscribe>
>
>The IESG has received a request from the Securing Neighbor Discovery WG to
>consider the following document:
>
>- 'SEcure Neighbor Discovery (SEND) '
>    <draft-ietf-send-ndopt-05.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>iesg@ietf.org or ietf@ietf.org mailing lists by 2004-05-17.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-send-ndopt-05.txt
>
>
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce

From housley@vigilsec.com Fri May  7 13:56:40 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i47Hud3a025293
	for <saag@jis.mit.edu>; Fri, 7 May 2004 13:56:40 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i47Hubh4017147
	for <saag@mit.edu>; Fri, 7 May 2004 13:56:37 -0400 (EDT)
Received: (qmail 12135 invoked by uid 0); 7 May 2004 17:45:54 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.157.153)
  by woodstock.binhost.com with SMTP; 7 May 2004 17:45:54 -0000
Message-Id: <5.2.0.9.2.20040507134636.0420b980@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 07 May 2004 13:49:42 -0400
To: saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.783936
Subject: [saag] Security Area review please: draft-ietf-capwap-arch-02.txt
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 07 May 2004 17:56:41 -0000

This document is now ready for review.  Please take a look, and post 
comments here.

The document title in the attached announcement is a bit confusing. It is a 
Taxonomy off all submitted existing architectures in this space. The real 
document title is much better.

Thanks,
   Russ

-----Original Message-----
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-capwap-arch-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Control And Provisioning of Wireless 
Access Points Working Group of the IETF.

	Title		: Architecture for Control and Provisioning of Wireless
		                       Access Points(CAPWAP)
	Author(s)	: L. Yang, et al.
	Filename	: draft-ietf-capwap-arch-02.txt
	Pages		: 89
	Date		: 2004-4-16
	
This document provides a taxonomy of the architectures employed in
    the existing IEEE 802.11 products in the market, by analyzing WLAN
    (Wireless LAN) functions and services and describing the different
    variants in distributing these functions and services among the
    architectural entities. This taxonomy may be utilized by the IEEE
    802.11 Working Group as input to their task of defining the Access
    Point (AP) functional architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-02.txt

From jaltman@columbia.edu Tue May 18 15:29:54 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i4IJTr3a013395
	for <saag@jis.mit.edu>; Tue, 18 May 2004 15:29:53 -0400 (EDT)
Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu
	[128.59.59.238])i4IJTotX022242
	for <saag@mit.edu>; Tue, 18 May 2004 15:29:50 -0400 (EDT)
Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55])
	(user=jaltman mech=PLAIN bits=0)i4IJTUSx006315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 18 May 2004 15:29:31 -0400 (EDT)
Message-ID: <40AA6422.2040309@columbia.edu>
Date: Tue, 18 May 2004 15:29:38 -0400
From: Jeffrey Altman <jaltman@columbia.edu>
Organization: No Longer Affiliated with Columbia University in the City of
 New York
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-cat-wg@lists.stanford.edu
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="------------ms030601060907060305020601"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.40
Spam-Alum-Prob: 0.000697
Spam-Alum-Time: 0.685371
cc: security-wg@ggf.org
cc: nfsv4@ietf.org
cc: saag@mit.edu
cc: Kerberos WG <ietf-krb-wg@anl.gov>
cc: ietf-kitten@central.org
Subject: [saag] Please review proposed letter to the IESG regarding the
	creation of the KITTEN Working Group with the IETF Security Area
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: ietf-cat-wg@lists.stanford.edu
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 18 May 2004 19:29:54 -0000

This is a cryptographically signed message in MIME format.

--------------ms030601060907060305020601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

My apologies ahead of time for the cross-posting to multiple lists. 

Following up on the recent discussions regarding GSSAPI v2 extensions 
which have taken
place within the Global Grid Forum Security Working Group; on the IETF 
CAT Working
Group mailing list; the IETF Kerberos Working Group mailing list; and 
many Zephyr and
Jabber chat sessions, it appears to be time to form a working group as a 
follow up to CAT
(aka KITTEN) to complete the necessary work.

Prior to sending a formal request to the IESG I would like to obtain 
feedback from
the interested parties.  I have posted to:

    /afs/athena.mit.edu/user/j/a/jaltman/Public/kitten-iesg-letter.html
    http://web.mit.edu/~jaltman/Public/kitten-iesg-letter.html

a proposed letter to the IESG providing the justification for the
creation of the KITTEN working group.  This letter includes a
proposed charter as well as a set of milestones.

Please read the proposal letter and send feedback to 
ietf-cat-wg@lists.stanford.edu.
Replies to this e-mail will be redirected to the CAT mailing list.

Thank you.

Jeffrey Altman



--------------ms030601060907060305020601
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC
AvgwggJhoAMCAQICAwwjmjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDE2MDIxODM0WhcNMDUwNDE2MDIxODM0
WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq
YWx0bWFuQGNvbHVtYmlhLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKyS
7eWrak81hbARkTT+lqX+uujXLK3tDmCn/6IQH9tDKYtf5A8/llZJdPYHUA9p1FH9hwk23iGY
scSkJq84FJenlWKOOqOsT6BlueWsrlKuseJCdMf9uhN28p+UnZvrcVhcLLTYfRvQT9OUw/k3
h4TzNdyAXbBJ3LnL1ySbFRaNVkq7cW/2ircAWpcyqHH4ZKstdSLbo6axsDHWRZL8yHUsI1Gz
esRSYQf2aUeUqvmGbEKEKFwbfqgfLwlBLiv1Lqib/++J3s5g3syhqWe3T8tUffmhdibUdX2W
umT2uiWl/WGEBvc1+o5k0T2JqWMNR9VgzPyk8P+iZRHl76Yb49ECAwEAAaNUMFIwDgYDVR0P
AQH/BAQDAgP4MBEGCWCGSAGG+EIBAQQEAwIFoDAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVt
YmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGXYUcZvaLEqctXUsgt0
fUMFXukM3E5fpLBkk3+BbcY457WQE38ZM1AOvcYOHqB1xhJCxP1U0pSJu2Xfe9Z1M2mU4C4V
2w4sDcWkZteM9EW7VYbXzSCKCw0TKKp3Wl9TFIWFdiFwPvhOzhXUonGTdYbOvRuAXQuJdNQW
O4v2sQg1MIIC+DCCAmGgAwIBAgIDDCOaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB
MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA0MTYwMjE4MzRaFw0wNTA0
MTYwMjE4MzRaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG
9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEArJLt5atqTzWFsBGRNP6Wpf666Ncsre0OYKf/ohAf20Mpi1/kDz+WVkl09gdQD2nU
Uf2HCTbeIZixxKQmrzgUl6eVYo46o6xPoGW55ayuUq6x4kJ0x/26E3byn5Sdm+txWFwstNh9
G9BP05TD+TeHhPM13IBdsEncucvXJJsVFo1WSrtxb/aKtwBalzKocfhkqy11ItujprGwMdZF
kvzIdSwjUbN6xFJhB/ZpR5Sq+YZsQoQoXBt+qB8vCUEuK/UuqJv/74nezmDezKGpZ7dPy1R9
+aF2JtR1fZa6ZPa6JaX9YYQG9zX6jmTRPYmpYw1H1WDM/KTw/6JlEeXvphvj0QIDAQABo1Qw
UjAOBgNVHQ8BAf8EBAMCA/gwEQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdEQQYMBaBFGphbHRt
YW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZdhRxm9o
sSpy1dSyC3R9QwVe6QzcTl+ksGSTf4FtxjjntZATfxkzUA69xg4eoHXGEkLE/VTSlIm7Zd97
1nUzaZTgLhXbDiwNxaRm14z0RbtVhtfNIIoLDRMoqndaX1MUhYV2IXA++E7OFdSicZN1hs69
G4BdC4l01BY7i/axCDUwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD
VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY
BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp
Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp
BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw
MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv
bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o
wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv
PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe
ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0
hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4
MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot
nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V
2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs
MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwjmjAJBgUr
DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
NDA1MTgxOTI5MzhaMCMGCSqGSIb3DQEJBDEWBBSAVDJZEgpmdZ6fNs1nJt4E5G8mmjBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDCOaMHoGCyqGSIb3DQEJEAIL
MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwj
mjANBgkqhkiG9w0BAQEFAASCAQAShZrDgRGagIfPEAb8JNm5sLcJjRUQQiaP9hgW3zUJXyQ3
QRyg7D+kxFNTW7776TG1U1Ui+F5+XKcqoiOfENKQZb7dq0woGvctwn3K5r5sfcv6DJLRWKjj
uMrP+R4JUsMRpj9HaFTGiqQMb3FHULkRwANwfoSbP0cMzCqrpzkOM2R3inHzhG2/sdjZKlkr
SNN+msYgEVVV99bK7yRo/ZPL8BJibVHRk5stmYJlvSNYEEEzV3FCfNz7akBz8AdQhwb58pT+
WzkDDUmr8VvrH3Cp6JkU7zbiaME5LwT+fu4oCNvJU3IYz+w69gjU1q3mXCjLUGNTlhPQzUzA
UVtlqVQdAAAAAAAA
--------------ms030601060907060305020601--
From deengert@anl.gov Wed May 19 14:57:09 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i4JIv83a014078
	for <saag@jis.mit.edu>; Wed, 19 May 2004 14:57:08 -0400 (EDT)
Received: from hermes.ctd.anl.gov (hermes.ctd.anl.gov [130.202.113.27])
	i4JIv4Yb029920
	for <saag@mit.edu>; Wed, 19 May 2004 14:57:04 -0400 (EDT)
Received: from hermes.ctd.anl.gov (localhost [127.0.0.1])
	by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA15336
	for <saag@mit.edu>; Wed, 19 May 2004 13:57:03 -0500 (CDT)
Received: from anl.gov (atalanta.ctd.anl.gov [146.137.194.4])
	by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA15309;
	Wed, 19 May 2004 13:56:59 -0500 (CDT)
Message-ID: <40ABADE6.8276197B@anl.gov>
Date: Wed, 19 May 2004 13:56:38 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-cat-wg@lists.stanford.edu
References: <40AA6422.2040309@columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.582780
cc: security-wg@ggf.org
cc: nfsv4@ietf.org
cc: saag@mit.edu
cc: Kerberos WG <ietf-krb-wg@anl.gov>
cc: ietf-kitten@central.org
Subject: [saag] Re: Please review proposed letter to the IESG regarding the
 creationof  the KITTEN Working Group with the IETF Security Area
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 19 May 2004 18:57:10 -0000

Jeff, 
This look very good. 

I know I have requested the GGF and IETF to review the situation of extensions 
to GSSAPI, and I am sure many of the active GGF members (who also attend the 
IETF) will participate in the BOF and join the new WG. 

And thanks for volunteering to lead this effort.
 


Jeffrey Altman wrote:
> 
> My apologies ahead of time for the cross-posting to multiple lists.
> 
> Following up on the recent discussions regarding GSSAPI v2 extensions
> which have taken
> place within the Global Grid Forum Security Working Group; on the IETF
> CAT Working
> Group mailing list; the IETF Kerberos Working Group mailing list; and
> many Zephyr and
> Jabber chat sessions, it appears to be time to form a working group as a
> follow up to CAT
> (aka KITTEN) to complete the necessary work.
> 
> Prior to sending a formal request to the IESG I would like to obtain
> feedback from
> the interested parties.  I have posted to:
> 
>     /afs/athena.mit.edu/user/j/a/jaltman/Public/kitten-iesg-letter.html
>     http://web.mit.edu/~jaltman/Public/kitten-iesg-letter.html
> 
> a proposed letter to the IESG providing the justification for the
> creation of the KITTEN working group.  This letter includes a
> proposed charter as well as a set of milestones.
> 
> Please read the proposal letter and send feedback to
> ietf-cat-wg@lists.stanford.edu.
> Replies to this e-mail will be redirected to the CAT mailing list.
> 
> Thank you.
> 
> Jeffrey Altman

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
From pekkas@netcore.fi Wed Jun  2 06:42:17 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i52AgG3a021556
	for <saag@jis.mit.edu>; Wed, 2 Jun 2004 06:42:17 -0400 (EDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])i52AgEJR027742
	for <saag@mit.edu>; Wed, 2 Jun 2004 06:42:14 -0400 (EDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i52AgCr06271
	for <saag@mit.edu>; Wed, 2 Jun 2004 13:42:12 +0300
Date: Wed, 2 Jun 2004 13:42:12 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: saag@mit.edu
Message-ID: <Pine.LNX.4.44.0406021341010.6229-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Spam-Alum-Prob: 0.000002
Spam-Alum-Time: 0.536686
Subject: [saag] WG Last Call: draft-ietf-v6ops-6to4-security-02.txt (fwd)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 02 Jun 2004 10:42:18 -0000

FYI -- feedback would be very much appreciated from SAAG community.

---------- Forwarded message ----------
Date: Wed, 2 Jun 2004 13:40:49 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Cc: jonne.soininen@nokia.com
Subject: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt

Hi all,

(co-chair hat on)

This is the WG Last Call for comments on sending
draft-ietf-v6ops-6to4-security-02.txt, "Security Considerations for
6to4" to the IESG for consideration as Informational:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-02.txt

Please review the document carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this
document is ready to go to the IESG.

The last call will end in 2 weeks, on 16th June.

Thanks!




From jari.arkko@piuha.net Sat Jun 12 15:05:21 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i5CJ5K3a015410
	for <saag@jis.mit.edu>; Sat, 12 Jun 2004 15:05:21 -0400 (EDT)
Received: from p2.piuha.net (p2.piuha.net [131.160.192.2])
	i5CJ5Jp1018405
	for <saag@mit.edu>; Sat, 12 Jun 2004 15:05:20 -0400 (EDT)
Received: from piuha.net (p2.piuha.net [131.160.192.2])
	by p2.piuha.net (Postfix) with ESMTP id 22F2989890
	for <saag@mit.edu>; Sat, 12 Jun 2004 22:05:18 +0300 (EEST)
Message-ID: <40CB52F3.5070202@piuha.net>
Date: Sat, 12 Jun 2004 22:01:07 +0300
From: Jari Arkko <jari.arkko@piuha.net>
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: saag@mit.edu
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.711142
Spam-Alum-Time: 0.507023
Subject: [saag] studies on the deployment of ingress filtering?
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: jari.arkko@piuha.net
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 12 Jun 2004 19:05:22 -0000


Hi,

Does anyone happen to know of any public studies about
how widely ingress filtering is currently deployed in
the Internet?

--Jari

From uri@lucent.com Wed Jun 16 18:13:29 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i5GMDS3a017302
	for <saag@jis.mit.edu>; Wed, 16 Jun 2004 18:13:28 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com
	[192.11.223.161])i5GMDQqu026404
	for <saag@mit.edu>; Wed, 16 Jun 2004 18:13:26 -0400 (EDT)
Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100])
	ESMTP id i5GMDMj23175
	for <saag@mit.edu>; Wed, 16 Jun 2004 17:13:22 -0500 (CDT)
Received: by nwmail.wh.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2)
	id i5GM9ZX25767; Wed, 16 Jun 2004 18:09:35 -0400 (EDT)
Received: from lucent.com by nwmail.wh.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2)
	id i5GM9YH25757; Wed, 16 Jun 2004 18:09:34 -0400 (EDT)
Message-ID: <40D0C510.9070705@lucent.com>
Date: Wed, 16 Jun 2004 18:09:20 -0400
From: Uri Blumenthal <uri@lucent.com>
Organization: Lucent Technologies / Bell Labs
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES)
X-Accept-Language: en-us, en, ru
MIME-Version: 1.0
To: saag <saag@mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000001
Spam-Alum-Time: 0.547307
Subject: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 16 Jun 2004 22:13:30 -0000

Folks, the following question came up at 3GPP2 TSG-X. They use MIPv6 and
consider how to key it for bootstrapping and subsequent Binding Updates.
Some people push for manual keying (no IKE). Since it's for wireless,
stream cipher is likely to be used.

Please help me to supply normative arguments (RFCs that describe why it is
stupid to use manual key with stream ciphers, official prohibitions, etc).

Thanks!

-------- Original Message --------
Subject: Re: [tsgxswg31] MIP6 and manual IPsec
Date: Tue, 15 Jun 2004 13:04:24 -0700
From: <hidden to protect the guilty>
To: uri@lucent.com

hi Uri,

can you give me a reference to the following?

> 4. For security reasons (since generating the same keystream twice is an
> absolute disaster), IETF forbade using manual keying (using the same key
> for multiple sessions) for stream ciphers at all. Better safe than sorry.

Vijay


From housley@vigilsec.com Wed Jun 16 19:36:19 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i5GNaI3a019049
	for <saag@jis.mit.edu>; Wed, 16 Jun 2004 19:36:18 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i5GNaHMh007522
	for <saag@mit.edu>; Wed, 16 Jun 2004 19:36:17 -0400 (EDT)
Received: (qmail 22969 invoked by uid 0); 16 Jun 2004 23:22:33 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.244.158)
  by woodstock.binhost.com with SMTP; 16 Jun 2004 23:22:33 -0000
Message-Id: <6.1.0.6.2.20040616193430.03811548@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6
Date: Wed, 16 Jun 2004 19:36:15 -0400
To: Uri Blumenthal <uri@lucent.com>, saag <saag@mit.edu>
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
In-Reply-To: <40D0C510.9070705@lucent.com>
References: <40D0C510.9070705@lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.579357
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 16 Jun 2004 23:36:19 -0000

These two articles talk about the problems that came up with WEP when they 
used a stream cipher without automated key management.  Of course, WEP made 
a plethora of other errors too.

    Housley, Russ, and William Arbaugh.  "Security Problems in 802.11-based 
Networks."
    Communications of the ACM, Vol 46, No 5 (May 2003): 31-34.

    Cam-Winget, Nancy, Russ Housley, David Wagner, and Jesse 
Walker.  "Security Flaws in
    802.11 Data Link Protocols."  Communications of the ACM, Vol 46, No 5 
(May 2003): 35-39.

Russ

At 06:09 PM 6/16/2004, Uri Blumenthal wrote:
>Folks, the following question came up at 3GPP2 TSG-X. They use MIPv6 and
>consider how to key it for bootstrapping and subsequent Binding Updates.
>Some people push for manual keying (no IKE). Since it's for wireless,
>stream cipher is likely to be used.
>
>Please help me to supply normative arguments (RFCs that describe why it is
>stupid to use manual key with stream ciphers, official prohibitions, etc).
>
>Thanks!
>
>-------- Original Message --------
>Subject: Re: [tsgxswg31] MIP6 and manual IPsec
>Date: Tue, 15 Jun 2004 13:04:24 -0700
>From: <hidden to protect the guilty>
>To: uri@lucent.com
>
>hi Uri,
>
>can you give me a reference to the following?
>
> > 4. For security reasons (since generating the same keystream twice is an
> > absolute disaster), IETF forbade using manual keying (using the same key
> > for multiple sessions) for stream ciphers at all. Better safe than sorry.
>
>Vijay
>
>
>_______________________________________________
>saag mailing list
>saag@mit.edu
>https://jis.mit.edu/mailman/listinfo/saag

From Black_David@emc.com Wed Jun 16 19:38:35 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i5GNcY3a019159
	for <saag@jis.mit.edu>; Wed, 16 Jun 2004 19:38:34 -0400 (EDT)
Received: from mailhub.lss.emc.com (mailhub.emc.com [168.159.2.31] (may be
	forged))i5GNcYMh009584
	for <saag@mit.edu>; Wed, 16 Jun 2004 19:38:34 -0400 (EDT)
Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9])
	i5GNcRW02352;	Wed, 16 Jun 2004 19:38:27 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <MZCH5YQP>; Wed, 16 Jun 2004 19:38:27 -0400
Message-ID: <B459CE1AFFC52D4688B2A5B842CA35EA7A5B68@corpmx14.corp.emc.com>
From: Black_David@emc.com
To: uri@lucent.com
Subject: RE: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
Date: Wed, 16 Jun 2004 19:38:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data:
	2004.6.16.104045
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.641311
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 16 Jun 2004 23:38:36 -0000

Uri,

RFC 3686 (AES Counter Mode) says it twice, and the author is one
of our current Security Area Directors.

Section 2.1 (bottom of p.3):

   When used correctly, AES-CTR provides a high level of
   confidentiality.  Unfortunately, AES-CTR is easy to use incorrectly.
   Being a stream cipher, any reuse of the per-packet value, called the
   IV, with the same nonce and key is catastrophic.  An IV collision
   immediately leaks information about the plaintext in both packets.
   For this reason, it is inappropriate to use this mode of operation
   with static keys.  Extraordinary measures would be needed to prevent
   reuse of an IV value with the static key across power cycles.  To be
   safe, implementations MUST use fresh keys with AES-CTR.  The Internet
   Key Exchange (IKE) [IKE] protocol can be used to establish fresh
   keys.  IKE can also provide the nonce value.

Section 7 (top of p.13):

   Therefore, stream ciphers, including AES-CTR, should not be used with
   static keys.  It is inappropriate to use AES-CTR with static keys.
   Extraordinary measures would be needed to prevent reuse of a counter
   block value with the static key across power cycles.  To be safe, ESP
   implementations MUST use fresh keys with AES-CTR.  The Internet Key
   Exchange (IKE) protocol [IKE] can be used to establish fresh keys.
   IKE can also be used to establish the nonce at the beginning of the
   security association.

This Section 7 text comes after a walkthrough of the catastrophic
vulnerability from using the same IV twice with the same key.  Manual
keys are static keys by definition as exhortations to change them on
a regular basis will be ignored by many - how many of us voluntarily
change our password when we should?

Enjoy,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On 
> Behalf Of Uri Blumenthal
> Sent: Wednesday, June 16, 2004 6:09 PM
> To: saag
> Subject: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
> 
> 
> Folks, the following question came up at 3GPP2 TSG-X. They 
> use MIPv6 and
> consider how to key it for bootstrapping and subsequent 
> Binding Updates.
> Some people push for manual keying (no IKE). Since it's for wireless,
> stream cipher is likely to be used.
> 
> Please help me to supply normative arguments (RFCs that 
> describe why it is
> stupid to use manual key with stream ciphers, official 
> prohibitions, etc).
> 
> Thanks!
> 
> -------- Original Message --------
> Subject: Re: [tsgxswg31] MIP6 and manual IPsec
> Date: Tue, 15 Jun 2004 13:04:24 -0700
> From: <hidden to protect the guilty>
> To: uri@lucent.com
> 
> hi Uri,
> 
> can you give me a reference to the following?
> 
> > 4. For security reasons (since generating the same 
> keystream twice is an
> > absolute disaster), IETF forbade using manual keying (using 
> the same key
> > for multiple sessions) for stream ciphers at all. Better 
> safe than sorry.
> 
> Vijay
> 
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 
From vijayd@iprg.nokia.com Wed Jun 16 20:02:18 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i5H02I3a019678
	for <saag@jis.mit.edu>; Wed, 16 Jun 2004 20:02:18 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com
	[205.226.5.69])i5H02GZp029040
	for <saag@mit.edu>; Wed, 16 Jun 2004 20:02:17 -0400 (EDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i5H02B701326;
	Wed, 16 Jun 2004 17:02:11 -0700
X-mProtect: <200406170002> Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14178.americas.nokia.com (172.18.141.78, claiming to be
	"iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdTjrnyr; Wed, 16 Jun 2004 17:02:09 PDT
Message-ID: <40D0DF77.9070002@iprg.nokia.com>
Date: Wed, 16 Jun 2004 17:01:59 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Uri Blumenthal <uri@lucent.com>
Subject: Re: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
References: <40D0C510.9070705@lucent.com>
In-Reply-To: <40D0C510.9070705@lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.604881
cc: saag <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 17 Jun 2004 00:02:19 -0000

Uri,

you dont have to keep my name hidden.

I need to set something right here. I was *not* arguing
for using manual keying when a stream cipher algorithm
is used. I was saying if manual keying is used for
Mobile IPv6 use a block cipher algorithm.

I dont have anything against IKE personally. just want
Mobile IPv6 adopted as widely as possible. if you insist
on mandating IKE for Mobile IPv6, then it might turn out
that IPsec is not used at all. people might use the
mechanism described in 
http://www.ietf.org/internet-drafts/draft-patel-mipv6-auth-protocol-01.txt.
3GPP2 has already indicated to the IETF that they would
like to see this draft standardized in IETF.

so mandating IKE might actually work against using IPsec
for Mobile IPv6 in 3GPP2. :)

Vijay

Uri Blumenthal wrote:

> Folks, the following question came up at 3GPP2 TSG-X. They use MIPv6 and
> consider how to key it for bootstrapping and subsequent Binding Updates.
> Some people push for manual keying (no IKE). Since it's for wireless,
> stream cipher is likely to be used.
> 
> Please help me to supply normative arguments (RFCs that describe why it is
> stupid to use manual key with stream ciphers, official prohibitions, etc).
> 
> Thanks!
> 
> -------- Original Message --------
> Subject: Re: [tsgxswg31] MIP6 and manual IPsec
> Date: Tue, 15 Jun 2004 13:04:24 -0700
> From: <hidden to protect the guilty>
> To: uri@lucent.com
> 
> hi Uri,
> 
> can you give me a reference to the following?
> 
> 
>>4. For security reasons (since generating the same keystream twice is an
>>absolute disaster), IETF forbade using manual keying (using the same key
>>for multiple sessions) for stream ciphers at all. Better safe than sorry.
> 
> 
> Vijay
> 
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

From mouse@Sparkle.Rodents.Montreal.QC.CA Thu Jun 17 00:06:57 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i5H46u3a024448
	for <saag@jis.mit.edu>; Thu, 17 Jun 2004 00:06:56 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i5H46sdd002821
	for <saag@mit.edu>; Thu, 17 Jun 2004 00:06:55 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA01350;
	Thu, 17 Jun 2004 00:06:51 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200406170406.AAA01350@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Wed, 16 Jun 2004 23:45:21 -0400 (EDT)
To: saag@mit.edu
Subject: Re: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
In-Reply-To: <40D0C510.9070705@lucent.com>
References: <40D0C510.9070705@lucent.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.543028
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 17 Jun 2004 04:06:57 -0000

> Please help me to supply normative arguments (RFCs that describe why
> it is stupid to use manual key with stream ciphers, official
> prohibitions, etc).

I don't know about RFCs, but then, RFCs often don't describe
rudimentary knowledge in various fields.  You likely won't, for
example, find an RFC describing why extending a 40-bit key to 128 bits
by copying it over and over still gives you only 40 bits' worth of
security.

Basic crypto references will explain why reusing key settings for
stream ciphers should _never_ be done.  For example, Applied
Cryptography section 9.4 explains it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From pekkas@netcore.fi Fri Jun 18 01:56:38 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i5I5ub3a028066
	for <saag@jis.mit.edu>; Fri, 18 Jun 2004 01:56:38 -0400 (EDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])i5I5uZI5000633
	for <saag@mit.edu>; Fri, 18 Jun 2004 01:56:36 -0400 (EDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i5I5uYH03596;
	Fri, 18 Jun 2004 08:56:35 +0300
Date: Fri, 18 Jun 2004 08:56:34 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: saag@mit.edu
Message-ID: <Pine.LNX.4.44.0406180853370.3388-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.626945
cc: Tschofenig Hannes <hannes.tschofenig@siemens.com>
Subject: [saag] I-D ACTION:draft-tschofenig-v6ops-secure-tunnels-00.txt (fwd)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 18 Jun 2004 05:56:39 -0000

FYI -- 

There was lively discussion of this a couple of months back, and now
we have something on paper.  There's a lot of work to be done still,
but we'd appreciate further review (and other help)!

Especially the situation of mixed-mode transforms in RFC2401 (not
-bis, that's clear!) was a bit fuzzy.

---------- Forwarded message ----------
Date: Mon, 14 Jun 2004 15:28:01 -0400
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-tschofenig-v6ops-secure-tunnels-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Using IPsec to Secure IPv6-over-IPv4 Tunnels
	Author(s)	: H. Tschofenig, et al.
	Filename	: draft-tschofenig-v6ops-secure-tunnels-00.txt
	Pages		: 23
	Date		: 2004-6-14
	
   This document gives guidance on securing IPv6-in-IPv4 tunnels using
   IPsec.  No additional protocol extensions are described beyond those
   available with the revised IPsec framework.  IKEv2 is extensively
   used as an authentication and key exchange protocol to cover address
   configuration procedures, and the usage of the Extensible
   Authentication Procotol and NAT traversal capabilities is also
   described.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-tschofenig-v6ops-secure-tunnels-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-tschofenig-v6ops-secure-tunnels-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-tschofenig-v6ops-secure-tunnels-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


From pbaker@verisign.com Mon Jul 19 18:11:24 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6JMBN3a022513
	for <saag@jis.mit.edu>; Mon, 19 Jul 2004 18:11:23 -0400 (EDT)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71])
	i6JMBMKA022230
	for <saag@mit.edu>; Mon, 19 Jul 2004 18:11:22 -0400 (EDT)
Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (verisign.com [65.205.251.33]
	(may be forged))
	by pigeon.verisign.com (8.12.10/) with ESMTP id i6JMBLO7015084
	for <saag@mit.edu>; Mon, 19 Jul 2004 15:11:21 -0700
Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <38A01R1M>; Mon, 19 Jul 2004 15:11:21 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BE966@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: saag <saag@mit.edu>
Subject: RE: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
Date: Mon, 19 Jul 2004 15:11:18 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.554621
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 19 Jul 2004 22:11:24 -0000

Manual keying is practically impossible for consumers to do
safely regardless of the cipher used. 

The advantage in using a key exchange protocol is that the
complexity can all be hidden from the end user.

Managing a WEP network is a pain, and would be even if the
protocol was secure. Every device needs to share a single key.
This inevitably ends up written on a board somewhere. In
order to withdraw credentials from one machine I have to 
renew them everywhere.


I do not understand how to parse statements such as "if you 
insist on mandating IKE for Mobile IPv6, then it might turn out
that IPsec is not used at all". If you are not going to do
a key exchange then you are much better off rethinking the
whole security stack altogether. If you are not going to do
the key exchange you might as well save yourself the bother
of IPSEC altogether, the key exchange is where the value lies.

If it is not possible to do IPSEC right then better to design 
a protocol that meets the real world constraints than do it 
wrong than create an IPSEC-lite.

From vijayd@iprg.nokia.com Mon Jul 19 19:20:21 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6JNKK3a024230
	for <saag@jis.mit.edu>; Mon, 19 Jul 2004 19:20:20 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com
	[205.226.5.69])i6JNKJBN018562
	for <saag@mit.edu>; Mon, 19 Jul 2004 19:20:19 -0400 (EDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6JNKGx05948;
	Mon, 19 Jul 2004 16:20:16 -0700
X-mProtect: <200407192320> Nokia Silicon Valley Messaging Protection
Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be
	"iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdYU94fI; Mon, 19 Jul 2004 16:20:14 PDT
Message-ID: <40FC58A8.2030008@iprg.nokia.com>
Date: Mon, 19 Jul 2004 16:26:32 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: Re: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
References: <C6DDA43B91BFDA49AA2F1E473732113E010BE966@mou1wnexm05.vcorp.ad.vrsn.com>
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BE966@mou1wnexm05.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.591252
cc: saag <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 19 Jul 2004 23:20:21 -0000

Hallam-Baker, Phillip wrote:

> I do not understand how to parse statements such as "if you 
> insist on mandating IKE for Mobile IPv6, then it might turn out
> that IPsec is not used at all". 

there are other key negotiation mechanisms. AAA based mechanisms
can be used to generate IPsec security associations. they are not
standardized in the IETF. it should be possible to use IPsec
without using IKE. if not, people start using something similar
to ESP without calling it IPsec. for example, I have seen the
following used by an SDO.

AES CTR is used for encryption. they pick a pre-defined SPI. then
they derive a key (from some shared key material). then they pick
a nonce and IV. encrypt a part of the message. include the nonce
and IV in the IP message and send it to the receiver. the receiving
node uses the NAI and SPI to pick the right key, and uses the nonce
and IV to decrypt the message. AES CTR is the default algorithm,
until the standard is *revised*. :(

the above is equivalent to using ESP in transport mode. now why
doesnt the SDO use ESP? the implementations of the specifications
produced by this SDO use IPv6. but not IPsec.

IMHO, it is generally percieved that IPsec cannot be used without
IKE. I dont know if IETF is responsible for this perception.

there are deployments, very small, where manual keying can be
used. I am not talking about a single shared key for everyone.
for example, in Mobile IPv6, you can have a shared key per Mobile
Node. the Home Agent knows the shared keys for all mobile nodes.
it should be possible to use IPsec (basically ESP in transport
mode) without IKE just for Mobile IPv6 signaling messages. the
Mobile IPv6 signaling messages have a replay protection built
into them. (ofcourse this doesnt mean Mobile IPv6 works only with
manual keying and not with IKE. RFC 3776 describes the use of
IPsec and IKEv1 with Mobile IPv6).

Vijay
From aboba@internaut.com Tue Jul 20 10:02:40 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6KE2d3a015505
	for <saag@jis.mit.edu>; Tue, 20 Jul 2004 10:02:39 -0400 (EDT)
Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net
	[66.167.171.107])i6KE2UZL011792
	for <saag@mit.edu>; Tue, 20 Jul 2004 10:02:31 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id i6KDxsc19662;
	Tue, 20 Jul 2004 06:59:54 -0700
Date: Tue, 20 Jul 2004 06:59:54 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: RE: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BE966@mou1wnexm05.vcorp.ad.vrsn.com>
Message-ID: <Pine.LNX.4.56.0407200646020.18448@internaut.com>
References: <C6DDA43B91BFDA49AA2F1E473732113E010BE966@mou1wnexm05.vcorp.ad.vrsn.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.585186
cc: saag <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 20 Jul 2004 14:02:40 -0000

> Manual keying is practically impossible for consumers to do
> safely regardless of the cipher used.

It appears that the intent of at least some implementers is to ship a
manual key embedded in the device (e.g. a phone).

> The advantage in using a key exchange protocol is that the
> complexity can all be hidden from the end user.

Actually, reading the MIPv6/IPsec specification, the attempt to adapt IKE
to MIPv6 appears to add a great deal of complexity, some of which probably
can't be hidden from the end user.

> Every device needs to share a single key.

The implicit assumption seems to be that the IPv6 Identifier will be
used to identify the appropriate key -- thus the requirement that
Identifiers be unique, not just *addresses*.

> I do not understand how to parse statements such as "if you
> insist on mandating IKE for Mobile IPv6, then it might turn out
> that IPsec is not used at all".

Parse it as: "Everyone is building their own flavor of this protocol, so
don't expect interoperation".  Reading the MIPv6/IPsec specification,
it's easy to see how two compliant implementations might not interoperate.
And with new key exchange specifications on the horizon, the situation is
will probably get more complex going forward, as various "profiles"
emerge.

> If it is not possible to do IPSEC right then better to design
> a protocol that meets the real world constraints than do it
> wrong than create an IPSEC-lite.

It would appear that MIPv6 is headed towards design of a customized key
exchange protocol, following in the footsteps of MIPv4.  Unlike MIPv4,
where security review only occurred after the fact, I'd suggest that it
might be wise to encourage early review so as to avoid long delays.
From mcr@sandelman.ottawa.on.ca Tue Jul 20 11:11:14 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6KFBD3a017515
	for <saag@jis.mit.edu>; Tue, 20 Jul 2004 11:11:13 -0400 (EDT)
Received: from noxmail.sandelman.ottawa.on.ca
	(cyphermail.sandelman.ottawa.on.ca [205.150.200.161])i6KFB6sO006774
	for <saag@mit.edu>; Tue, 20 Jul 2004 11:11:07 -0400 (EDT)
Received: from lox.sandelman.ottawa.on.ca
	(IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178])i6KFB1X21858
	verified FAIL);	Tue, 20 Jul 2004 11:11:01 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca
	[205.150.200.247])i6KFG7o14776verified FAIL);
	Tue, 20 Jul 2004 11:16:13 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1])
	i6KF93tA029630
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 20 Jul 2004 11:09:04 -0400
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	i6KF91To029627;	Tue, 20 Jul 2004 11:09:02 -0400
To: Vijay Devarapalli <vijayd@iprg.nokia.com>
Subject: Re: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec] 
In-Reply-To: Message from Vijay Devarapalli <vijayd@iprg.nokia.com> 
   of "Mon, 19 Jul 2004 16:26:32 PDT." <40FC58A8.2030008@iprg.nokia.com> 
References:
	<C6DDA43B91BFDA49AA2F1E473732113E010BE966@mou1wnexm05.vcorp.ad.vrsn.com>
	<40FC58A8.2030008@iprg.nokia.com> 
X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6)
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 20 Jul 2004 11:09:01 -0400
Message-ID: <29625.1090336141@marajade.sandelman.ottawa.on.ca>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.558340
cc: saag <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 20 Jul 2004 15:11:14 -0000

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Vijay" == Vijay Devarapalli <vijayd@iprg.nokia.com> writes:
    Vijay> IMHO, it is generally percieved that IPsec cannot be used
    Vijay> without IKE. I dont know if IETF is responsible for this
    Vijay> perception.

  This is because too many other WG said "use IPsec" in the past,
without giving ANY thought as to how key the SAs, just assuming that
it was either trivial, or that IKE was easy.

  Even saying use "IPsec + IKE" can be non-trivial due to very few
implementations doing RSA keys without X.509, so one either gets into
PKIX stuff, which REALLY scares people, or one gets back to a pre-shared
key, which if you had, you could just key IPsec directly.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQP01jIqHRg3pndX9AQGCCwP6A9MJUI7oLaN6ddBSpp6Rq7JJcrg0xt/v
Tq6Pl9i4eE2suuEN9icg56gJ42c01Ncu5RiGrSAZy89RCcoCOAXCIQHWOHprLZQQ
Z7PyctY+eOFICUU5EcxGDfJlVsyHNAeP6hf9cgL64PKqnqWYzONIsr/6doUX8ZTU
4S0Bqc/MSu8=
=6UrX
-----END PGP SIGNATURE-----
From pbaker@verisign.com Tue Jul 20 11:34:19 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6KFYH3a018183
	for <saag@jis.mit.edu>; Tue, 20 Jul 2004 11:34:18 -0400 (EDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73])
	i6KFYAnQ021977
	for <saag@mit.edu>; Tue, 20 Jul 2004 11:34:10 -0400 (EDT)
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]
	(may be forged))i6KFY8GN029744;
	Tue, 20 Jul 2004 08:34:08 -0700
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <NQBAB583>; Tue, 20 Jul 2004 08:34:08 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BE96F@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Bernard Aboba'" <aboba@internaut.com>,
   "Hallam-Baker, Phillip"
	 <pbaker@verisign.com>
Subject: RE: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
Date: Tue, 20 Jul 2004 08:34:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.625215
cc: saag <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 20 Jul 2004 15:34:19 -0000

> > Manual keying is practically impossible for consumers to do
> > safely regardless of the cipher used.
> 
> It appears that the intent of at least some implementers is to ship a
> manual key embedded in the device (e.g. a phone).

It is probably not a bad idea if there is some embedded key in the
device.

What I am concerned at here is that I see signs of security 
perfectionism leading to no security at all or bad security. Or
perhaps what I am seeing is the game of try to make someone else
deliver a killer app for a protocol that is not succeeding on
its own - and yes that is the case with IPSEC, the VPN usage is
currently shrinking because tunnelling over SSL is empirically
much more robust.


> Parse it as: "Everyone is building their own flavor of this 
> protocol, so
> don't expect interoperation".  Reading the MIPv6/IPsec specification,
> it's easy to see how two compliant implementations might not 
> interoperate.

Plus ca change.

> And with new key exchange specifications on the horizon, the 
> situation is
> will probably get more complex going forward, as various "profiles"
> emerge.

That does not worry me very much. Commercial pressures are going
to pull the specs together. The only way you can get interop between
implementations is if the vendors set up an interop forum.

And that interop forum better be testing devices that are viable
at the consumer level rather than some intermediate layer in the stack.

In the real world it really does matter if you implement a scheme
to allow users to specify passphrase or make them type in a raw 
random key. 


> It would appear that MIPv6 is headed towards design of a 
> customized key
> exchange protocol, following in the footsteps of MIPv4.  Unlike MIPv4,
> where security review only occurred after the fact, I'd 
> suggest that it
> might be wise to encourage early review so as to avoid long delays.

The best way to encourage early review would be to make it clear
that its not IKE or nothing...
From jaltman@columbia.edu Tue Jul 27 14:22:50 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6RIMn3a015859
	for <saag@jis.mit.edu>; Tue, 27 Jul 2004 14:22:49 -0400 (EDT)
Received: from pecan.cc.columbia.edu (pecan.cc.columbia.edu [128.59.59.178])
	i6RIMkXe011521
	for <saag@mit.edu>; Tue, 27 Jul 2004 14:22:47 -0400 (EDT)
Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55])
	(user=jaltman mech=PLAIN bits=0)i6RIMNs9003667
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 27 Jul 2004 14:22:26 -0400 (EDT)
Message-ID: <41069D5E.9010403@columbia.edu>
Date: Tue, 27 Jul 2004 14:22:22 -0400
From: Jeffrey Altman <jaltman@columbia.edu>
Organization: No Longer Affiliated with Columbia University in the City of
 New York
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7) Gecko/20040608
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-cat-wg@lists.Stanford.EDU
X-Enigmail-Version: 0.84.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.40
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.569991
cc: security-wg@ggf.org
cc: nfsv4@ietf.org
cc: SASL WG <ietf-sasl@imc.org>
cc: Kerberos WG <ietf-krb-wg@anl.gov>
cc: saag@mit.edu
Subject: [saag] 
 Kitten (Common Authentication Technologies - Next Generation) at
 IETF 60
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 27 Jul 2004 18:22:51 -0000

The Common Authentication Technologies Next Generation (Kitten) BOF will 
be meeting at IETF 60:

1530-1730 Afternoon Sessions II
Grande B    SEC   kitten    Kitten (Daughter of CAT) BOF 

The agenda of the meeting is as follows:
_
Kitten BOF Agenda for IETF 60_

 * Introduction and Welcome [5 minutes]  - Jeffrey Altman
 * Discussion of the Global Grid Forum GSS requirements [15 minutes] - 
Doug Engert
 * Discussion of channel bindings portability issues (C struct et all)  
[10 minutes] - Sam Hartman
 * Discussion of GSSAPI naming [15 minutes] - Sam Hartman
 * Discussion of need for cryptographic channel bindings and CCM  [10 
minutes] - Nicolas Williams
 * Discussion of Stackable Psuedo Mechanisms [10 minutes] - Nicolas Williams
 * Discussion of the SPNEGO issues [10 minutes] - Wyllys Ingersol
 * Discussion of the C# Bindings for GSSAPI [10 minutes] - Microsoft
 * Charter discussion [15 minutes] - Jeffrey Altman

An introduction to the purpose of the Kitten Working Group and a 
proposed charter
may be found at:

   http://www.ietf.org/ietf/04aug/kitten.txt

We encourage anyone interested in the future of GSSAPI (applications 
which use GSSAPI
or mechanisms implementing GSSAPI); those concerned with authenticated 
name portability;
and those participating in the Cryptographic Channel Bindings work to 
attend this BOF
and participate in the discussions.  For the most part the Kitten 
participants have identified
problem areas; have presented some potential incomplete solutions; and 
there is much work
to be done.

I hope to see you there.

Jeffrey Altman

From smb@research.att.com Wed Jul 28 13:43:55 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6SHhs3a019340
	for <saag@jis.mit.edu>; Wed, 28 Jul 2004 13:43:54 -0400 (EDT)
Received: from machshav.com (machshav.com [147.28.0.16])
	i6SHhgss005463
	for <saag@mit.edu>; Wed, 28 Jul 2004 13:43:42 -0400 (EDT)
Received: by machshav.com (Postfix, from userid 512)
	id 40981FB4DA; Wed, 28 Jul 2004 13:43:39 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 50EF9FB4D8
	for <saag@mit.edu>; Wed, 28 Jul 2004 13:43:38 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP id 3C8211AE89
	for <saag@mit.edu>; Wed, 28 Jul 2004 13:43:37 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: Steve Bellovin <smb@research.att.com>
To: saag@mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 28 Jul 2004 13:43:37 -0400
Message-Id: <20040728174337.3C8211AE89@berkshire.research.att.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.797051
Subject: [saag] DES: Now 'really most sincerely dead' (Forwarded)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 28 Jul 2004 17:43:56 -0000


------- Forwarded Message


Subject: DES: Now 'really most sincerely dead'
Date: Tue, 27 Jul 2004 10:28:09 -0400
From: "Trei, Peter" <ptrei@rsasecurity.com>
To: <cypherpunks@minder.net>, <cryptography@metzdowd.com>


Back in late 1996, I wrote to Jim Bidzos, proposing an RSA
Challenge to break single DES by brute force computation. 

Later in 1997, the first DES Challenge was successfully
completed.

Its taken another 7 years, but NIST has finally pulled 
single DES as a supported mode. 

Favorite line: "DES is now vulnerable to key exhaustion 
using massive, parallel computations."

Triple DES is still a supported mode, as it
should be.

So, if a product claims to use DES for
protection, you can now officially diss 
them for it.

Peter Trei
- ------------------------------------------

http://edocket.access.gpo.gov/2004/04-16894.htm

[Federal Register: July 26, 2004 (Volume 69, Number 142)]
[Notices]               
[Page 44509-44510]
>From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr26jy04-31]                         

- -----------------------------------------------------------------------

DEPARTMENT OF COMMERCE

National Institute of Standards and Technology

[Docket No. 040602169-4169-01]

 
Announcing Proposed Withdrawal of Federal Information Processing 
Standard (FIPS) for the Data Encryption Standard (DES) and Request for 
Comments

AGENCY: National Institute of Standards and Technology (NIST), 
Commerce.

ACTION: Notice; request for comments.

- -----------------------------------------------------------------------

SUMMARY: The Data Encryption Standard (DES), currently specified in 
Federal Information Processing Standard (FIPS) 46-3, was evaluated 
pursuant to its scheduled review. At the conclusion of this review, 
NIST determined that the strength of the DES algorithm is no longer 
sufficient to adequately protect Federal government information. As a 
result, NIST proposes to withdraw FIPS 46-3, and the associated FIPS 74 
and FIPS 81.
    Future use of DES by Federal agencies is to be permitted only as a 
component function of the Triple Data Encryption Algorithm (TDEA). TDEA 
may be used for the protection of Federal information; however, NIST 
encourages agencies to implement the faster and stronger algorithm 
specified by FIPS 197, Advanced Encryption Standard (AES) instead. NIST 
proposes issuing TDEA implementation guidance as a NIST Recommendation 
via its ``Special Publication'' series (rather than as a FIPS) as 
Special Publication 800-67, Recommendation for Implementation of the 
Triple Data Encryption Algorithm (TDEA).

DATES: Comments on the proposed withdrawal of DES must be received on 
or before September 9, 2004.

ADDRESSES: Official comments on the proposed withdrawal of DES may 
either be sent electronically to  DEScomments@nist.gov  or by regular 
mail to: Chief, Computer Security Division, Information Technology 
Laboratory, ATTN: Comments on Proposed Withdrawal of DES, 100 Bureau 
Drive, Stop 8930, National Institute of Standards and Technology, 
Gaithersburg, MD 20899-8930.

FOR FURTHER INFORMATION CONTACT: Mr. William Barker (301) 975-8443, 
wbarker@nist.gov, National Institute of Standards and Technology, 100 
Bureau Drive, STOP 8930, Gaithersburg, MD 20899-8930.

SUPPLEMENTARY INFORMATION: In 1977, the Federal government determined 
that, while the DES algorithm was adequate to protect against any 
practical attack for the anticipated 15-year life of the standard, DES 
would be reviewed for adequacy every five years. DES is now vulnerable 
to key exhaustion using massive, parallel computations.
    The current Data Encryption Standard (FIPS 46-3) still permits the 
use of DES to protect Federal government information. Since the 
strength of the original DES algorithm is no longer sufficient to 
adequately protect Federal government information, it is necessary to 
withdraw the standard.
    In addition, NIST proposes the simultaneous withdrawal of FIPS 74, 
Guidelines for Implementing and Using the NBS Data Encryption Standard 
and FIPS 81, DES Modes of Operation. FIPS 74 is an implementation 
guideline specific to the DES. An updated NIST Special Publication 800-
21, Guideline for Implementing Cryptography in the Federal Government, 
will provide generic implementation and use guidance for NIST-approved 
block cipher algorithms (e.g., TDEA and AES). Because it is DES-
specific, and DES is being withdrawn, the simultaneous withdrawal of 
FIPS 74 is proposed.
    FIPS 81 defines four modes of operation for the DES that have been 
used in a wide variety of applications. The modes specify how data is 
to be encrypted (cryptographically protected)

[[Page 44510]]

and decrypted (returned to original form) using DES. The modes included 
in FIPS 81 are the Electronic Codebook (ECB) mode, the Cipher Block 
Chaining (CBC) mode, the Cipher Feedback (CFB) mode, and the Output 
Feedback (OFB) mode. NIST Special Publication 800-38A, Recommendation 
for Block Cipher Modes of Operation, specifies modes of operation for 
generic block ciphers. Together with an upcoming message authentication 
code recommendation, SP 800-38B, SP 800-38A is a functional replacement 
for FIPS 81. FIPS 81 is DES-specific and is proposed for withdrawal 
along with FIPS 46-3 and FIPS 74.
    NIST invites public comments on the proposed withdrawal of FIPS 46-
3, FIPS 74 and FIPS 81. After the comment period closes, NIST will 
analyze the comments and make appropriate recommendations for action to 
the Secretary of Commerce.
    Future use of FIPS 46-3 by Federal agencies is proposed to be 
permitted only as a component function of the Triple Data Encryption 
Algorithm or ``TDEA.'' TDEA encrypts each block three times with the 
DES algorithm, using either two or three different 56-bit keys. This 
approach yields effective key lengths of 112 or 168 bits. TDEA is 
considered a very strong algorithm. The original 56-bit DES algorithm 
can be modified to be interoperable with TDEA.
    Though TDEA may be used for several more years to encourage 
widespread interoperability, NIST instead encourages agencies to 
implement the stronger and more efficient algorithm specified by FIPS 
197, Advanced Encryption Standard (AES) when building new systems. TDEA 
implementation guidance will be issued as a NIST Recommendation rather 
than as a FIPS. NIST plans to issue TDEA as Special Publication 800-67, 
Recommendation for Implementation of the Triple Data Encryption 
Algorithm (TDEA).

    Authority: Federal Information Processing Standards Publications 
(FIPS PUBS) are issued by the National Institute of Standards and 
Technology after approval by the Secretary of Commerce pursuant to 
section 5131 of the Information Technology Management Reform Act of 
1996 and the Federal Information Security Management Act of 2002, 
Public Law 107-347.

    E.O. 12866: This notice has been determined not to be 
significant for purposes of E.O. 12866.

    Dated: July 18, 2004.
Hratch Semerjian,
Acting Director, NIST.
[FR Doc. 04-16894 Filed 7-23-04; 8:45 am]

- ---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com


------- End of Forwarded Message



		--Steve Bellovin, http://www.research.att.com/~smb


From mbaugher@cisco.com Fri Jul 30 17:22:36 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6ULMY3a016245
	for <saag@jis.mit.edu>; Fri, 30 Jul 2004 17:22:34 -0400 (EDT)
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72])
	i6ULMWQt018799
	for <saag@mit.edu>; Fri, 30 Jul 2004 17:22:32 -0400 (EDT)
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 30 Jul 2004 14:24:06 +0000
X-BrightmailFiltered: true
Received: from [128.107.163.48] (dhcp-128-107-163-48.cisco.com
	[128.107.163.48])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6ULMN8H002338;
	Fri, 30 Jul 2004 14:22:28 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8BF0B07C-E26E-11D8-8472-000A95DC10F2@cisco.com>
Content-Transfer-Encoding: 7bit
From: Mark Baugher <mbaugher@cisco.com>
Date: Fri, 30 Jul 2004 14:22:22 -0700
To: list@perm-wg.org
X-Mailer: Apple Mail (2.618)
Spam-Alum-Prob: 0.000007
Spam-Alum-Time: 0.511135
cc: Thomas Hardjono <thardjono@verisign.com>
cc: discuss@apps.ietf.org
cc: saag@mit.edu
Subject: [saag] revised PERM BOF Overview slides are posted
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 30 Jul 2004 21:22:36 -0000

hi
   http://www.rdrop.com/users/mbaugher/PERMBOF.pdf is the revised 
slideset for the PERM BOF containing the agenda, overview and proposed 
WG charter.  
http://www.ietf.org/internet-drafts/draft-gildred-perm-01.txt is the 
current version of the PERM specification.

   The PERM BOF is scheduled for Monday, 1-3pm, see 
http://www.ietf.org/meetings/agenda_60.html

Mark

From housley@vigilsec.com Sat Jul 31 20:49:25 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i710nO3a020840
	for <saag@jis.mit.edu>; Sat, 31 Jul 2004 20:49:24 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i710nNuq005554
	for <saag@mit.edu>; Sat, 31 Jul 2004 20:49:23 -0400 (EDT)
Received: (qmail 12979 invoked by uid 0); 1 Aug 2004 00:39:54 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.135.249)
  by woodstock.binhost.com with SMTP; 1 Aug 2004 00:39:54 -0000
Message-Id: <6.1.1.1.2.20040731204722.037e1ec0@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Sat, 31 Jul 2004 20:49:51 -0400
To: saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.547194
Subject: [saag] DES Withdrawal
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 01 Aug 2004 00:49:25 -0000

The following recent announcement is of interest to the members of the mail 
list.

Russ

= = = = = = = =

July 27, 2004 -- NIST has determined that the strength of the (single) Data 
Encryption Standard (DES) algorithm is no longer sufficient to adequately 
protect Federal government information. As a result, NIST proposes 
withdrawing FIPS 46-3, which specifies the DES, and two related standards 
(see http://csrc.nist.gov/Federal-register/July26-2004-FR-DES-Notice.pdf). 
Future use of DES by Federal agencies is to be permitted only as a 
component function of the Triple Data Encryption Algorithm (TDEA; see NIST 
Special Publication 800-67 at 
http://csrc.nist.gov/publications/nistpubs/800-67/SP800-67.pdf). TDEA may 
be used for the protection of Federal information; however, NIST encourages 
agencies to implement the faster and stronger algorithm specified by FIPS 
197, Advanced Encryption Standard (AES) instead. Comments must be received 
on or before September 9, 2004.

To submit comments, concerns or questions please forward them to:
descomments@nist.gov.

From housley@vigilsec.com Mon Aug  2 23:50:25 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i733oO3a026426
	for <saag@jis.mit.edu>; Mon, 2 Aug 2004 23:50:24 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i733oNKQ011718
	for <saag@mit.edu>; Mon, 2 Aug 2004 23:50:23 -0400 (EDT)
Received: (qmail 17173 invoked by uid 0); 3 Aug 2004 03:40:24 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.131.87)
  by woodstock.binhost.com with SMTP; 3 Aug 2004 03:40:24 -0000
Message-Id: <6.1.1.1.2.20040802234803.03773ec0@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Mon, 02 Aug 2004 23:50:56 -0400
To: Vijay Devarapalli <vijayd@iprg.nokia.com>
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec] 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.523512
cc: saag <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 03 Aug 2004 03:50:25 -0000

Vijay Devarapalli <vijayd@iprg.nokia.com> writes:
 > IMHO, it is generally percieved that IPsec cannot be used
 > without IKE. I dont know if IETF is responsible for this
 > perception.

The IESG routinely approves documents that include MUST statements for 
IPsec ESP and AH with manual key management.  Most of them have SHOULD or 
MAY statements about IKE.  This is a recognition that manual key management 
is the solution that people will actually use in the near-term.

Russ

From vijayd@iprg.nokia.com Tue Aug  3 00:27:31 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i734RU3a027247
	for <saag@jis.mit.edu>; Tue, 3 Aug 2004 00:27:30 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com
	[205.226.5.69])i734RTdl016522
	for <saag@mit.edu>; Tue, 3 Aug 2004 00:27:29 -0400 (EDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i734RQ100439;
	Mon, 2 Aug 2004 21:27:26 -0700
X-mProtect: <200408030427> Nokia Silicon Valley Messaging Protection
Received: from danira-pool054186.americas.nokia.com (10.241.54.186, claiming
	to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdiuM1DT; Mon, 02 Aug 2004 21:27:24 PDT
Message-ID: <410F1422.70806@iprg.nokia.com>
Date: Mon, 02 Aug 2004 21:27:14 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] [Fwd: Re: [tsgxswg31] MIP6 and manual IPsec]
References: <6.1.1.1.2.20040802234803.03773ec0@mail.binhost.com>
In-Reply-To: <6.1.1.1.2.20040802234803.03773ec0@mail.binhost.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.545631
cc: saag <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 03 Aug 2004 04:27:32 -0000

ok. thanks for the clarification.

Vijay

Russ Housley wrote:
> Vijay Devarapalli <vijayd@iprg.nokia.com> writes:
>  > IMHO, it is generally percieved that IPsec cannot be used
>  > without IKE. I dont know if IETF is responsible for this
>  > perception.
> 
> The IESG routinely approves documents that include MUST statements for 
> IPsec ESP and AH with manual key management.  Most of them have SHOULD 
> or MAY statements about IKE.  This is a recognition that manual key 
> management is the solution that people will actually use in the near-term.
> 
> Russ
> 

From jordi.palet@consulintel.es Thu Aug  5 19:38:37 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i75Nca3a007598
	for <saag@jis.mit.edu>; Thu, 5 Aug 2004 19:38:36 -0400 (EDT)
Received: from consulintel.es (mail.consulintel.es [213.172.48.142])
	i75NcTSh018876
	for <saag@mit.edu>; Thu, 5 Aug 2004 19:38:34 -0400 (EDT)
Received: from consulintel02 by consulintel.es
	(MDaemon.PRO.v7.1.2.R)
	with ESMTP id md50000180637.msg
	for <saag@mit.edu>; Fri, 06 Aug 2004 01:41:47 +0200
Message-ID: <002d01c47b45$484c5b20$14848182@consulintel.es>
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: "saag" <saag@mit.edu>
Date: Thu, 5 Aug 2004 16:38:09 -0700
Organization: Consulintel
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Fri, 06 Aug 2004 01:41:47 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 130.129.132.20
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: saag@mit.edu
X-MDAV-Processed: consulintel.es, Fri, 06 Aug 2004 01:41:52 +0200
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.542666
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id
	i75Nca3a007598
cc: Jonne.Soininen@nokia.com
Subject: [saag] IPv6 Distributed Security - inputs and review needed
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 05 Aug 2004 23:38:38 -0000

Hi all,

While this IETF meeting proceedings are officially published, we have uploaded the slides that I just introduced at:
http://www.netcore.fi/pekkas/ietf/60/17_distributed.pdf

The documents related to this work are:
http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-vives-v6ops-ipv6-security-ps-01
http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-palet-v6ops-ipv6security-01
http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-kondo-quarantine-overview-01

Please let me know any inputs you may have.

Regards,
Jordi




**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.




From BonattiC@ieca.com Thu Aug  5 20:30:22 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i760UM3a008935
	for <saag@jis.mit.edu>; Thu, 5 Aug 2004 20:30:22 -0400 (EDT)
Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com
	[66.163.175.81])i760ULSh024368
	for <saag@mit.edu>; Thu, 5 Aug 2004 20:30:21 -0400 (EDT)
Received: from unknown (HELO Vagabond) (BonattiC@ieca.com@130.129.130.79 with
	login)  by smtp004.bizmail.sc5.yahoo.com with SMTP;
	6 Aug 2004 00:30:20 -0000
From: "Bonatti, Chris" <BonattiC@ieca.com>
To: <saag@mit.edu>
Date: Thu, 5 Aug 2004 17:30:18 -0700
Organization: IECA, Inc.
Message-ID: <001c01c47b4c$8d0b5e80$4f828182@Vagabond>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.556033
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id
	i760UM3a008935
Subject: [saag] OASIS Report on PKI Deployment Obstacles
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 06 Aug 2004 00:30:23 -0000

Pusuant to today's SAAG discussion on PKI, I'd like to remind
people of a report from the OASIS PKI Technical Committee on
obstacles to PKI deployment and usage.  Steve Hanna previously
introduced this in the IETF some time ago, but it received little
discussion as far as I saw.  You can obtain the report at:

<http://www.oasis-open.org/committees/pki/pkiobstaclesjune2003sur
veyreport.pdf>

I'll call your attention to the list (first appearing on p.12) of
top PKI obstacles.  Their list was:

	1. Software applications don't support it
	2. Costs too high
	3. PKI poorly understood
	4. Poor interoperability
	5. Hard to get started - too complex
	6. Hard for end users to use
	7. Lack of management support
	8. Too much legal work required
	9. Hard for IT to maintain
	10. Other obstacle

You may notice that you have to get down to item 4 to reach
anything that has to do with the IETF.

Regards,
Chris



From gregory-ietf@earthlink.net Thu Aug  5 20:53:48 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i760rl3a009532
	for <saag@jis.mit.edu>; Thu, 5 Aug 2004 20:53:47 -0400 (EDT)
Received: from audiogram.mail.pas.earthlink.net
	(audiogram.mail.pas.earthlink.net [207.217.120.253])i760revK015736
	for <saag@mit.edu>; Thu, 5 Aug 2004 20:53:41 -0400 (EDT)
Received: from opene-130-129-133-217.ietf60.ietf.org ([130.129.133.217]
	helo=5P10R31.earthlink.net)
	by audiogram.mail.pas.earthlink.net with asmtp (Exim 4.34)
	id 1BsszK-0005eY-2v; Thu, 05 Aug 2004 17:53:39 -0700
Message-Id: <5.1.1.6.0.20040805145551.0175b2d8@popd.ix.netcom.com>
X-Sender: gregory-ietf@earthlink.net@mail.earthlink.net
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 05 Aug 2004 17:53:22 -0700
To: Russ Housley <housley@vigilsec.com>, pki4ipsec@icsalabs.com
From: Gregory M Lebovitz <gregory-ietf@earthlink.net>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_29315873==.ALT"
X-ELNK-Trace: bb75549d41bf6763a56c75a03b4135ad4d2b10475b5711201d6d85156697d15aaa6aa8f28657a5bca482dc6f32b1730f350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.129.133.217
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.658297
cc: saag@mit.edu
Subject: [saag] PKI4IPSEC summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 06 Aug 2004 00:53:48 -0000

--=====================_29315873==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

==Major Decisions==
- draft-ietf-pki4ipsec-ikecert-profile-01.txt - IKE / Certificates profile
  The draft is profiling (a) how IKE implementations should process 
cert-related IKE payloads and the certs themselves, (b) contents of certs 
that will be used in IKE exchanges
   - make section 4 (about cert contents) more strongly directed toward PKI 
deployers as an audience, not just PKI developers or VPN operators.
   - send list text from draft on IKE_ID = IPaddr and try to get consensus
   - came to agreement on how to handle KU/EKU - clarify to list and then 
place in next draft
   - move PAD to SPD's major discussion from 2401bis document to this I-D.
   - bunch of other nits that will go to issues list and be rolled into -02

- draft-bonatti-pki4ipsec-profile-reqts-01.txt - Certificate Management Profile
   - will not consider XKMS at this time, stick w/ focus on CMC
   - sticking with CRL via HTTP, until such a time as community at large 
demands another method (OCSP, SCVP)
   - use "control attribute" object within CMC to create a template 
reference for authorizations for VPN to send to PKI when requesting 
authorizations
   - cert used to secure communication from VPN to PKI need NOT be same 
cert as PKI issued to Peer.

- Upcoming profile for VPN-PKI management
   - will profile CMC to fill the requirements from req's document
   - we have a few decisions now that need to be captured in this doc, so 
time to start it
   - looking for an editor and authors!!

== Action Items ==
- update miltestones - sent to ietf-action already for posting
- Gregory Lebovitz to release ...ikecert-profile-02.txt
    - consensus call on IKE_ID IPaddr text
    - consensus call on KU/EKU handling text
    - vamp sect 4 to better address PKI deployers
    - other little items captured in issue tracker
- Mark Zimmerman - post issues raised in WG discussion to issue tracker and 
repost by end of week.
- Brian Korver to release ...ikecert-profile-02.txt by end of Sept. This 
will be WG last call candidate
- Bonatti and Turner - submit ...reqt-01.txt to editor as WG document
- Bonatti and Turner - update ...reqts-02.txt with
- Chairs to secure editor for management profile document and get it going
- Paul Knight / Mark Zimmerman to get issue tracker online setup and 
current xls list ported into it

== Tracking to Charter Milestones ==
new milestones:
DONE - Jan 04 Post Certificate Profile and Use in IKE as an Internet Draft
DONE - Jan 04 Post Management Protocol Profile Requirements as I-D
DONE - July 04 Rev Requirements for management protocol profile as needed
Sept 04 Submit Certificate Profile and Use in IKE as WG last call
Nov 04 Post CMC for IPsec VPN Profile as Internet Draft
Dec 04 Submit Requirements for Management Protocol Profile as WG last call
Dec 04 Submit Certificate Profile and Use to IESG, Proposed Standard
Dec 04 WG decision on other Enrolment/Management protocols to profile
Jan 05 Submit Requirements for Management protocol Profile to IESG, 
Informational
Dec 05 Rev CMC for IPsec VPN profile as needed
Mar 05 CMC for IPsec VPN profile to WG last call
May 05 Submit CMC for IPsec VPN Profile to IESG, Proposed Standard
June 05 Re-charter or close



+++++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
W - +01 (1) 408 543 8002
--=====================_29315873==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
==Major Decisions==<br>
- draft-ietf-pki4ipsec-ikecert-profile-01.txt - IKE / Certificates
profile<br>
&nbsp;The draft is profiling (a) how IKE implementations should process
cert-related IKE payloads and the certs themselves, (b) contents of certs
that will be used in IKE exchanges<br>
&nbsp; - make section 4 (about cert contents) more strongly directed
toward PKI deployers as an audience, not just PKI developers or VPN
operators.<br>
&nbsp; - send list text from draft on IKE_ID = IPaddr and try to get
consensus<br>
&nbsp; - came to agreement on how to handle KU/EKU - clarify to list and
then place in next draft<br>
&nbsp; - move PAD to SPD's major discussion from 2401bis document to this
I-D.<br>
&nbsp; - bunch of other nits that will go to issues list and be rolled
into -02<br><br>
- draft-bonatti-pki4ipsec-profile-reqts-01.txt -
<font face="Trebuchet MS">Certificate Management Profile<br>
</font>&nbsp; - will not consider XKMS at this time, stick w/ focus on
CMC<br>
&nbsp; - sticking with CRL via HTTP, until such a time as community at
large demands another method (OCSP, SCVP)<br>
&nbsp; - use &quot;control attribute&quot; object within CMC to create a
template reference for authorizations for VPN to send to PKI when
requesting authorizations<br>
&nbsp; - cert used to secure communication from VPN to PKI need NOT be
same cert as PKI issued to Peer.<br><br>
- Upcoming profile for VPN-PKI management <br>
&nbsp; - will profile CMC to fill the requirements from req's
document<br>
&nbsp; - we have a few decisions now that need to be captured in this
doc, so time to start it<br>
&nbsp; - looking for an editor and authors!!<br><br>
== Action Items ==<br>
- update miltestones - sent to ietf-action already for posting<br>
- Gregory Lebovitz to release ...ikecert-profile-02.txt<br>
&nbsp;&nbsp; - consensus call on IKE_ID IPaddr text<br>
&nbsp;&nbsp; - consensus call on KU/EKU handling text<br>
&nbsp;&nbsp; - vamp sect 4 to better address PKI deployers<br>
&nbsp;&nbsp; - other little items captured in issue tracker<br>
- Mark Zimmerman - post issues raised in WG discussion to issue tracker
and repost by end of week.<br>
- Brian Korver to release ...ikecert-profile-02.txt by end of Sept. This
will be WG last call candidate<br>
- Bonatti and Turner - submit ...reqt-01.txt to editor as WG
document<br>
- Bonatti and Turner - update ...reqts-02.txt with <br>
- Chairs to secure editor for management profile document and get it
going<br>
- Paul Knight / Mark Zimmerman to get issue tracker online setup and
current xls list ported into it<br><br>
== Tracking to Charter Milestones ==<br>
new milestones:<br>
DONE - Jan 04 Post Certificate Profile and Use in IKE as an Internet
Draft <br>
DONE - Jan 04 Post Management Protocol Profile Requirements as I-D <br>
DONE - July 04 Rev Requirements for management protocol profile as needed
<br>
Sept 04 Submit Certificate Profile and Use in IKE as WG last call <br>
Nov 04 Post CMC for IPsec VPN Profile as Internet Draft <br>
Dec 04 Submit Requirements for Management Protocol Profile as WG last
call <br>
Dec 04 Submit Certificate Profile and Use to IESG, Proposed Standard
<br>
Dec 04 WG decision on other Enrolment/Management protocols to profile
<br>
Jan 05 Submit Requirements for Management protocol Profile to IESG,
Informational <br>
Dec 05 Rev CMC for IPsec VPN profile as needed <br>
Mar 05 CMC for IPsec VPN profile to WG last call <br>
May 05 Submit CMC for IPsec VPN Profile to IESG, Proposed Standard <br>
June 05 Re-charter or close<br><br>
<br>
<x-sigsep><p></x-sigsep>
+++++++++++++++++++++++++<br>
IETF-related email from<br>
Gregory M. Lebovitz<br>
Juniper Networks<br>
W - +01 (1) 408 543 8002</html>

--=====================_29315873==.ALT--

From smb@research.att.com Thu Aug  5 23:04:06 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i763453a012536
	for <saag@jis.mit.edu>; Thu, 5 Aug 2004 23:04:05 -0400 (EDT)
Received: from machshav.com (machshav.com [147.28.0.16])
	i763442g000746
	for <saag@mit.edu>; Thu, 5 Aug 2004 23:04:04 -0400 (EDT)
Received: by machshav.com (Postfix, from userid 512)
	id 20892FB4E0; Thu,  5 Aug 2004 23:04:04 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 9CB21FB4DB
	for <saag@mit.edu>; Thu,  5 Aug 2004 23:04:03 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP id CFF7F1AE9C
	for <saag@mit.edu>; Thu,  5 Aug 2004 23:03:54 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: Steve Bellovin <smb@research.att.com>
To: saag@mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 05 Aug 2004 20:03:54 -0700
Message-Id: <20040806030354.CFF7F1AE9C@berkshire.research.att.com>
Spam-Alum-Prob: 0.000001
Spam-Alum-Time: 0.519829
Subject: [saag] new mailing list -- easycert
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 06 Aug 2004 03:04:06 -0000

As a result of today's SAAG meeting, I've created a new mailing list, 
easycert@machshav.com.  The purpose is to discuss ways to make 
certificate use and deployment easy.  We're likely going to work 
towards a pkiops BoF in Washington.

Subscribe at https://www.machshav.com/mailman/listinfo.cgi/easycert


		--Steve Bellovin, http://www.research.att.com/~smb


From kent@bbn.com Fri Aug  6 11:10:04 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i76FA33a000933
	for <saag@jis.mit.edu>; Fri, 6 Aug 2004 11:10:03 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i76FA2co019183
	for <saag@mit.edu>; Fri, 6 Aug 2004 11:10:02 -0400 (EDT)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i76F9r7f020527;
	Fri, 6 Aug 2004 11:09:57 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06110405bd394c30f63d@[128.89.89.75]>
In-Reply-To: <5.1.1.6.0.20040805145551.0175b2d8@popd.ix.netcom.com>
References: <5.1.1.6.0.20040805145551.0175b2d8@popd.ix.netcom.com>
Date: Fri, 6 Aug 2004 11:05:30 -0400
To: Gregory M Lebovitz <gregory-ietf@earthlink.net>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000034
Spam-Alum-Time: 0.517262
cc: pki4ipsec@icsalabs.com
cc: saag@mit.edu
Subject: [saag] Re: [Pki4ipsec] PKI4IPSEC summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 06 Aug 2004 15:10:05 -0000

Gregory,

>==Major Decisions==
>	<SNIP>
>   - move PAD to SPD's major discussion from 2401bis document to this I-D.

I don't know how to parse this phrase.  I do know that what I said at 
the meeting was that it would be appropriate for this WG to take on 
responsibility for defining the details of the PAD and how to use it, 
beyond what will appear in 2401bis.  is that what the above bullet 
was meant to convey?

Steve

From gregory-ietf@earthlink.net Sat Aug  7 06:11:09 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i77AB83a026113
	for <saag@jis.mit.edu>; Sat, 7 Aug 2004 06:11:08 -0400 (EDT)
Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net
	[207.217.120.84])i77AB8pN019596
	for <saag@mit.edu>; Sat, 7 Aug 2004 06:11:08 -0400 (EDT)
Received: from skeeter.psp.pas.earthlink.net ([207.217.78.186])
	by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1BtOAD-00037Z-00; Sat, 07 Aug 2004 03:10:57 -0700
Message-ID: <9976645.1091873457815.JavaMail.root@skeeter.psp.pas.earthlink.net>
Date: Sat, 7 Aug 2004 03:10:57 -0700 (GMT-07:00)
From: Gregory M Lebovitz <gregory-ietf@earthlink.net>
To: Stephen Kent <kent@bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Earthlink Zoo Mail 1.0
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.549099
cc: pki4ipsec@icsalabs.com
cc: saag@mit.edu
Subject: [saag] Re: [Pki4ipsec] PKI4IPSEC summary
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Gregory M Lebovitz <gregory-ietf@earthlink.net>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 07 Aug 2004 10:11:10 -0000

yes. Thanks for clarification.

-----Original Message-----
From: Stephen Kent <kent@bbn.com>
Sent: Aug 6, 2004 8:05 AM
To: Gregory M Lebovitz <gregory-ietf@earthlink.net>
Cc: Russ Housley <housley@vigilsec.com>, pki4ipsec@icsalabs.com, 
	Steven Bellovin <smb@research.att.com>, saag@mit.edu
Subject: Re: [Pki4ipsec] PKI4IPSEC summary

Gregory,

>==Major Decisions==
>	<SNIP>
>   - move PAD to SPD's major discussion from 2401bis document to this I-D.

I don't know how to parse this phrase.  I do know that what I said at 
the meeting was that it would be appropriate for this WG to take on 
responsibility for defining the details of the PAD and how to use it, 
beyond what will appear in 2401bis.  is that what the above bullet 
was meant to convey?

Steve

_______________________________________________
pki4ipsec mailing list
pki4ipsec@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/pki4ipsec


IETF-related email from
Gregory M Lebovitz
Juniper Networks
From shanna@funk.com Mon Aug  9 11:46:07 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i79Fk53a014305
	for <saag@jis.mit.edu>; Mon, 9 Aug 2004 11:46:06 -0400 (EDT)
Received: from trilmail.funk.com (26-71-51-66.reonbroadband.com [66.51.71.26])
	i79Fk5tu009277
	for <saag@mit.edu>; Mon, 9 Aug 2004 11:46:05 -0400 (EDT)
Received: from [127.0.0.1] (HANNAXP [192.168.21.23]) by trilmail.funk.com with
	SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 2TX6YZ0J; Mon, 9 Aug 2004 11:43:44 -0400
Message-ID: <41179C3C.80500@funk.com>
Date: Mon, 09 Aug 2004 11:46:04 -0400
From: Steve Hanna <shanna@funk.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Bonatti, Chris" <BonattiC@ieca.com>
Subject: Re: [saag] OASIS Report on PKI Deployment Obstacles
References: <001c01c47b4c$8d0b5e80$4f828182@Vagabond>
In-Reply-To: <001c01c47b4c$8d0b5e80$4f828182@Vagabond>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.608320
cc: easycert@machshav.com
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 09 Aug 2004 15:46:07 -0000

I'm glad to see this interest in making PKI easier
to deploy and use. PKI is a valuable technology,
used widely and with great potential but unless
we can resolve these deployment problems it will
continue to languish.

I'm really sorry I missed the discussion at SAAG,
but I have joined the easycert list and look forward to
continuing this discussion there and at future forums.

In addition to the report noted by Chris (thanks!),
the OASIS PKI TC has two other documents relevant to
this discussion:

Analysis of August 2003 Follow-up Survey on Obstacles
to PKI Deployment and Usage
http://www.oasis-open.org/committees/pki/pkiobstaclesaugust2003surveyreport.pdf

PKI Action Plan
http://www.oasis-open.org/committees/pki/pkiactionplan.pdf

If you only have time to read one of these documents,
read the PKI Action Plan. It summarizes the other two.

I have a few more comments on Chris' email, but
I'll take those to the easycert list.

Thanks,

Steve

Chris Bonatti wrote:
> Pusuant to today's SAAG discussion on PKI, I'd like to remind
> people of a report from the OASIS PKI Technical Committee on
> obstacles to PKI deployment and usage.  Steve Hanna previously
> introduced this in the IETF some time ago, but it received little
> discussion as far as I saw.  You can obtain the report at:
> 
> <http://www.oasis-open.org/committees/pki/pkiobstaclesjune2003sur
> veyreport.pdf>
> 
> I'll call your attention to the list (first appearing on p.12) of
> top PKI obstacles.  Their list was:
> 
> 	1. Software applications don't support it
> 	2. Costs too high
> 	3. PKI poorly understood
> 	4. Poor interoperability
> 	5. Hard to get started - too complex
> 	6. Hard for end users to use
> 	7. Lack of management support
> 	8. Too much legal work required
> 	9. Hard for IT to maintain
> 	10. Other obstacle
> 
> You may notice that you have to get down to item 4 to reach
> anything that has to do with the IETF.
> 
> Regards,
> Chris
> 
> 
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

From paul.hoffman@vpnc.org Mon Aug  9 19:05:02 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i79N513a027081
	for <saag@jis.mit.edu>; Mon, 9 Aug 2004 19:05:01 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	i79N4m43009054
	for <saag@mit.edu>; Mon, 9 Aug 2004 19:04:48 -0400 (EDT)
Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com
	[63.249.109.252])	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i79N4eoa030228
	for <saag@mit.edu>; Mon, 9 Aug 2004 16:04:41 -0700 (PDT)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p06110447bd3db370a7e8@[10.20.30.249]>
Date: Mon, 9 Aug 2004 16:04:39 -0700
To: saag@mit.edu
From: The IESG <iesg-secretary@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.522039
Subject: [saag] Last Call: 'Randomness Requirements for Security' to BCP
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 09 Aug 2004 23:05:02 -0000

The IESG has received a request from an individual submitter to consider the
following document:

- 'Randomness Requirements for Security '
    <draft-eastlake-randomness2-08.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2004-09-06.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-eastlake-randomness2-08.txt


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
From ibryant@vedef.org Tue Aug 10 00:15:20 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7A4FE3a005963
	for <saag@jis.mit.edu>; Tue, 10 Aug 2004 00:15:19 -0400 (EDT)
Received: from localdomain (holiday42.nidhog.net [66.207.137.42] (may be
	forged))i7A4FDtT013598
	for <saag@mit.edu>; Tue, 10 Aug 2004 00:15:13 -0400 (EDT)
Received: from 1921681164 ([172.20.100.84]) by localdomain for
	<ibryant@vedef.org> with eXtremail; Tue, 10 Aug 2004 00:10:59 -4GMT
From: "Ian Bryant \(VEDEF mailbox\)" <ibryant@vedef.org>
To: "IETF SAAG Mailing List" <saag@mit.edu>
Date: Tue, 10 Aug 2004 00:14:56 -0400
Organization: VEDEF.ORG
Message-ID: <037d01c47e90$986f5500$83f6690c@1921681164>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
Spam-Alum-Prob: 0.000216
Spam-Alum-Time: 0.527044
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id
	i7A4FE3a005963
X-Mailman-Approved-At: Tue, 10 Aug 2004 10:03:00 -0400
Subject: [saag] VEDEF
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: ibryant@vedef.org
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 10 Aug 2004 04:15:20 -0000

Those of you who were able to attend IETF60 may have heard reference to the
Vulnerability and Exploit Description and Exchange Format (VEDEF) initiative
during the SAAG meeting.

Anyone interested should note there is now a website (http://www.vedef.org),
which includes a mailing list sign-up (http://www.vedef.org/contact.html).


Ian Bryant
--
mailto:ibryant@vedef.org



From stephen.farrell@cs.tcd.ie Tue Aug 10 10:36:56 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7AEat3a022965
	for <saag@jis.mit.edu>; Tue, 10 Aug 2004 10:36:55 -0400 (EDT)
Received: from mail.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56])
	i7AEaigC004640
	for <saag@mit.edu>; Tue, 10 Aug 2004 10:36:44 -0400 (EDT)
Received: from mail.cs.tcd.ie (localhost [127.0.0.1])
	by relay.cs.tcd.ie (Postfix) with ESMTP id 7D0BD7E35
	for <saag@mit.edu>; Tue, 10 Aug 2004 15:36:41 +0100 (IST)
Received: from cs.tcd.ie (sfarrel2.dsg.cs.tcd.ie [134.226.36.26])
	by mail.cs.tcd.ie (Postfix) with ESMTP id 2610D7E16
	for <saag@mit.edu>; Tue, 10 Aug 2004 15:36:41 +0100 (IST)
Message-ID: <4118DDBC.7020501@cs.tcd.ie>
Date: Tue, 10 Aug 2004 15:37:48 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: saag@mit.edu
Subject: Re: [saag] Last Call: 'Randomness Requirements for Security' to BCP
References: <p06110447bd3db370a7e8@[10.20.30.249]>
In-Reply-To: <p06110447bd3db370a7e8@[10.20.30.249]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.555484
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 10 Aug 2004 14:36:57 -0000


Good to see rfc1750 being updated.

It'd be great if this spec also gave some specific guidance
to windows programmers who don't have e.g. /dev/audio (and
no, I don't have text to offer unfortunately).

Surely msft must've done a tech note or something that
could be copied/referenced?

Stephen.

The IESG wrote:

> The IESG has received a request from an individual submitter to consider 
> the
> following document:
> 
> - 'Randomness Requirements for Security '
>    <draft-eastlake-randomness2-08.txt> as a BCP
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2004-09-06.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-eastlake-randomness2-08.txt
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 
From housley@vigilsec.com Tue Aug 10 12:46:51 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7AGko3a026774
	for <saag@jis.mit.edu>; Tue, 10 Aug 2004 12:46:50 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i7AGkegY020891
	for <saag@mit.edu>; Tue, 10 Aug 2004 12:46:41 -0400 (EDT)
Received: (qmail 24346 invoked by uid 0); 10 Aug 2004 16:45:28 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.139.202)
  by woodstock.binhost.com with SMTP; 10 Aug 2004 16:45:28 -0000
Message-Id: <6.1.1.1.2.20040810124620.0839eba8@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Tue, 10 Aug 2004 12:47:18 -0400
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] Last Call: 'Randomness Requirements for Security'
  to BCP
In-Reply-To: <4118DDBC.7020501@cs.tcd.ie>
References: <p06110447bd3db370a7e8@[10.20.30.249]>
 <4118DDBC.7020501@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.566955
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 10 Aug 2004 16:46:51 -0000

Steve:

Good point.  I have pointed out the Last Call notice to someone at 
Microsoft.  They will get "the right people" to take a look.

Russ

At 10:37 AM 8/10/2004, Stephen Farrell wrote:

>Good to see rfc1750 being updated.
>
>It'd be great if this spec also gave some specific guidance
>to windows programmers who don't have e.g. /dev/audio (and
>no, I don't have text to offer unfortunately).
>
>Surely msft must've done a tech note or something that
>could be copied/referenced?
>
>Stephen.
>
>The IESG wrote:
>
>>The IESG has received a request from an individual submitter to consider the
>>following document:
>>- 'Randomness Requirements for Security '
>>    <draft-eastlake-randomness2-08.txt> as a BCP
>>The IESG plans to make a decision in the next few weeks, and solicits
>>final comments on this action.  Please send any comments to the
>>iesg@ietf.org or ietf@ietf.org mailing lists by 2004-09-06.
>>The file can be obtained via
>>http://www.ietf.org/internet-drafts/draft-eastlake-randomness2-08.txt
>>
>>_______________________________________________
>>IETF-Announce mailing list
>>IETF-Announce@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf-announce
>>_______________________________________________
>>saag mailing list
>>saag@mit.edu
>>https://jis.mit.edu/mailman/listinfo/saag
>_______________________________________________
>saag mailing list
>saag@mit.edu
>https://jis.mit.edu/mailman/listinfo/saag
>

From ekr@rtfm.com Wed Aug 18 15:09:16 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7IJ9F3a001543
	for <saag@jis.mit.edu>; Wed, 18 Aug 2004 15:09:16 -0400 (EDT)
Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251])
	i7IJ99H6008134
	for <saag@mit.edu>; Wed, 18 Aug 2004 15:09:10 -0400 (EDT)
Received: from rtfm.com (romeo.rtfm.com [198.144.203.242])
	by sierra.rtfm.com (Postfix) with ESMTP id E2C147199
	for <saag@mit.edu>; Wed, 18 Aug 2004 12:17:47 -0700 (PDT)
To: saag@mit.edu
X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.3.1
Date: Wed, 18 Aug 2004 12:09:09 -0700
From: Eric Rescorla <ekr@rtfm.com>
Message-Id: <20040818191747.E2C147199@sierra.rtfm.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.682785
Subject: [saag] Bad day at the hash function factory
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 18 Aug 2004 19:09:17 -0000

As you may or may not have heard, this year's CRYPTO conference
has been very interesting:

* Joux has found a single collision in SHA-0--an algorithm that nobody
  uses but that is very similar to SHA-1. However, SHA-0 was changed to
  fix a flaw (later found by Joux), thus becoming SHA-1 so we can hope
  that this attack can't be extended to SHA-1. The attack was fairly
  expensive, requiring about 2^51 operations the brute force attack
  would take about 2^80).

* Biham and Chen can find collisions in a reduced round version of SHA-1
  (40 rounds). The full SHA-1 is 80 rounds. It's hard to know whether
  this can be extended to full SHA-1 or not. NSA (who designed SHA-1)
  seems to be generally pretty good at tuning their algorithms so that
  they're just complicated enough to be secure.

* Weng, Fang, Lai, and Yu have what appears to be a general method for
  finding collisions in MD4, MD5, HAVAL-128, and RIPEMD. They
  haven't published any details.

What does this mean for us? I'll be writing up full details hopefully
soon, but here's a short overview...

WHAT'S BEEN SHOWN?
An attacker can generate two messages M and M' such that Hash(M) = Hash(M').
Note that he cannot (currently) generate a message M such that Hash(M)
is a given hash value, nor can he generate a message M' such that it hashes
the same as a fixed message M. Currently this is possible for MD5 
but we have to consider the possibility that it will be eventually
possible for SHA-1.


USES OF HASH FUNCTIONS
We use hash algorithms in a bunch of different contexts. At minimum:

1. Digital signatures (you sign the hash of a message).
   (a) On messages (e.g. S/MIME). 
   (b) On certificates.
   (c) In authentication primitives (e.g., SSH)
2. As MAC functions (e.g. HMAC)
3. As authentication functions (e.g. CRAM-MD5)
4. As key generation functions (e.g. SSL or IPsec PRF)

THE POTENTIAL ATTACKS
The only situation in which the current attacks definitely apply is 
(1). The general problem is illustrated by the following scenario.
Alice and Bob are negotiating a contract. Alice generates two
messages:

M  = "Alice will pay Bob $500/hr"
M' = "Alice will pay Bob $50/hr" [0]

Where H(M) = H(M').

She gets Bob to sign M (and maybe signs it herself). Then when it
comes time to pay Bob, she whips out M' and says "I only owe
$50/hr", which Bob has also signed (remember that you sign the
hash of the message). 

So, this attack threatens non-repudiation or any kind of third
party verifiability. Another, slightly more esoteric, case is
certificates. Remember that a certificate is a signed message
from the CA containing the identity of the user. So, Alice
generates two certificate requests:

R  = "Alice.com, Key=X"
R' = "Bob.com, Key=Y"

Such that H(R) = H(R') (I'm simplifying here). 

When the CA signs R, it's also signing R', so Alice can present
her new "Bob" certificate and pose as Bob. It's not clear that
this attack can work in practice because Alice doesn't control
the entire cert: the CA specifies the serial number. However,
it's getting risky to sign certs with MD5.


WHAT'S SAFE?
First, anything that's already been signed is definitely safe.  If you
stop using MD5 today, nothing you signed already puts you at risk.

There is probably no risk to two party SSH/SSL-style authentication
handshakes.

It's believed that HMAC is secure against this attack (according to Hugo
Krawczyk, the designer) so the modern MAC functions should all be
secure.

I worry a bit about CRAM-MD5 and HTTP Digest. They're not as well
designed as HMAC and you might potentially be able to compromise them to
mount some kind of active cut-and-paste attack, though I don't have one
in my pocket.

The key generation PRFs should be safe.

-Ekr


[0] In practice, the messages might not be this similar, but there
turn out to be lots of opportunities to make subtle changes in any
text message.

From mcgrew@cisco.com Thu Aug 19 12:23:38 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7JGNa3a012671
	for <saag@jis.mit.edu>; Thu, 19 Aug 2004 12:23:37 -0400 (EDT)
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72])
	i7JGNZ4w007587
	for <saag@mit.edu>; Thu, 19 Aug 2004 12:23:35 -0400 (EDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 19 Aug 2004 09:29:04 +0000
X-BrightmailFiltered: true
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
	[171.71.163.14])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7JGNXiQ003581;
	Thu, 19 Aug 2004 09:23:33 -0700 (PDT)
Received: from [10.32.254.210] ([10.32.254.210])
	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with SMTP id AWJ69856;
	Thu, 19 Aug 2004 09:22:20 -0700 (PDT)
In-Reply-To: <20040818191747.E2C147199@sierra.rtfm.com>
References: <20040818191747.E2C147199@sierra.rtfm.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <1B38BDAC-F1FC-11D8-B277-0003935495EC@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Bad day at the hash function factory
Date: Thu, 19 Aug 2004 09:23:29 -0700
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.619)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.727873
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 19 Aug 2004 16:23:38 -0000

Eric,

this is a nice overview, thanks for posting it.  There is some related 
discussion on CFRG (and some folks at Santa Barbara are chiming in, 
which is quite useful).  We should make sure that all of the distinct 
usages of MD5 that you enumerated get critical review.

I expect that the community will be discussing the appropriate 
replacement for MD5 a lot in coming weeks.  I have one comment for SAAG 
here: this 'bad day for hash functions' should remind us about the 
importance of algorithm agility.  When we move forward and revise old 
specifications that use MD5, let's make sure that those revisions make 
it easy to deploy newer hash algorithms.

David

On Aug 18, 2004, at 12:09 PM, Eric Rescorla wrote:

> As you may or may not have heard, this year's CRYPTO conference
> has been very interesting:
>
> * Joux has found a single collision in SHA-0--an algorithm that nobody
>   uses but that is very similar to SHA-1. However, SHA-0 was changed to
>   fix a flaw (later found by Joux), thus becoming SHA-1 so we can hope
>   that this attack can't be extended to SHA-1. The attack was fairly
>   expensive, requiring about 2^51 operations the brute force attack
>   would take about 2^80).
>
> * Biham and Chen can find collisions in a reduced round version of 
> SHA-1
>   (40 rounds). The full SHA-1 is 80 rounds. It's hard to know whether
>   this can be extended to full SHA-1 or not. NSA (who designed SHA-1)
>   seems to be generally pretty good at tuning their algorithms so that
>   they're just complicated enough to be secure.
>
> * Weng, Fang, Lai, and Yu have what appears to be a general method for
>   finding collisions in MD4, MD5, HAVAL-128, and RIPEMD. They
>   haven't published any details.
>
> What does this mean for us? I'll be writing up full details hopefully
> soon, but here's a short overview...
>
> WHAT'S BEEN SHOWN?
> An attacker can generate two messages M and M' such that Hash(M) = 
> Hash(M').
> Note that he cannot (currently) generate a message M such that Hash(M)
> is a given hash value, nor can he generate a message M' such that it 
> hashes
> the same as a fixed message M. Currently this is possible for MD5
> but we have to consider the possibility that it will be eventually
> possible for SHA-1.
>
>
> USES OF HASH FUNCTIONS
> We use hash algorithms in a bunch of different contexts. At minimum:
>
> 1. Digital signatures (you sign the hash of a message).
>    (a) On messages (e.g. S/MIME).
>    (b) On certificates.
>    (c) In authentication primitives (e.g., SSH)
> 2. As MAC functions (e.g. HMAC)
> 3. As authentication functions (e.g. CRAM-MD5)
> 4. As key generation functions (e.g. SSL or IPsec PRF)
>
> THE POTENTIAL ATTACKS
> The only situation in which the current attacks definitely apply is
> (1). The general problem is illustrated by the following scenario.
> Alice and Bob are negotiating a contract. Alice generates two
> messages:
>
> M  = "Alice will pay Bob $500/hr"
> M' = "Alice will pay Bob $50/hr" [0]
>
> Where H(M) = H(M').
>
> She gets Bob to sign M (and maybe signs it herself). Then when it
> comes time to pay Bob, she whips out M' and says "I only owe
> $50/hr", which Bob has also signed (remember that you sign the
> hash of the message).
>
> So, this attack threatens non-repudiation or any kind of third
> party verifiability. Another, slightly more esoteric, case is
> certificates. Remember that a certificate is a signed message
> from the CA containing the identity of the user. So, Alice
> generates two certificate requests:
>
> R  = "Alice.com, Key=X"
> R' = "Bob.com, Key=Y"
>
> Such that H(R) = H(R') (I'm simplifying here).
>
> When the CA signs R, it's also signing R', so Alice can present
> her new "Bob" certificate and pose as Bob. It's not clear that
> this attack can work in practice because Alice doesn't control
> the entire cert: the CA specifies the serial number. However,
> it's getting risky to sign certs with MD5.
>
>
> WHAT'S SAFE?
> First, anything that's already been signed is definitely safe.  If you
> stop using MD5 today, nothing you signed already puts you at risk.
>
> There is probably no risk to two party SSH/SSL-style authentication
> handshakes.
>
> It's believed that HMAC is secure against this attack (according to 
> Hugo
> Krawczyk, the designer) so the modern MAC functions should all be
> secure.
>
> I worry a bit about CRAM-MD5 and HTTP Digest. They're not as well
> designed as HMAC and you might potentially be able to compromise them 
> to
> mount some kind of active cut-and-paste attack, though I don't have one
> in my pocket.
>
> The key generation PRFs should be safe.
>
> -Ekr
>
>
> [0] In practice, the messages might not be this similar, but there
> turn out to be lots of opportunities to make subtle changes in any
> text message.
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>

From pbaker@verisign.com Thu Aug 19 14:45:51 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7JIjo3a017173
	for <saag@jis.mit.edu>; Thu, 19 Aug 2004 14:45:50 -0400 (EDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	i7JIjlVK005503
	for <saag@mit.edu>; Thu, 19 Aug 2004 14:45:47 -0400 (EDT)
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com
	[65.205.251.55])
	by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7JIjk84014694;
	Thu, 19 Aug 2004 11:45:46 -0700 (PDT)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <Q6638JJM>; Thu, 19 Aug 2004 11:45:46 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEA97@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Eric Rescorla'" <ekr@rtfm.com>, saag@mit.edu
Subject: RE: [saag] Bad day at the hash function factory
Date: Thu, 19 Aug 2004 11:45:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.570693
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 19 Aug 2004 18:45:52 -0000

> I worry a bit about CRAM-MD5 and HTTP Digest. They're not as well
> designed as HMAC and you might potentially be able to 
> compromise them to
> mount some kind of active cut-and-paste attack, though I 
> don't have one in my pocket.

I don't see how HTTP Digest is vulnerable. The only security
concerns in HTTP Digest is to make sure that an attacker cannot
1) recover the password from the bits on the wire or 2) generate
the acceptable response to the challeng without the password.

This requires a much more comprehensive attack against MD5
than anything we have yet seen. A compression collision does
not do very much for the attacker.

It is about 12 years since I last looked at Digest but the
issue of concatenation attacks etc had been considered in
the design. If you have a session nonce the construct is:

H1 = H ( H (username + realm + password) + nonce + cnonce)

I will accept that the nested constrution is probably not as
satisfactory as the HMAC construction if you want to hash
large amounts of text, but on the typical message sizes used
for DIGEST I doubt there is much difference since it is
unlikely that there will be more than a couple of compressor
iterations and the operations associated with the HMAC 
are unlikely to significantly add to the difficulty.

The scheme is certainly less satisfactory if the nonces are
omitted, particularly as the outer hash is omitted entirely.


The security of this scheme is not affected if there is
a free means of generating a, b such that H (a) = H (b).


From pbaker@verisign.com Fri Aug 20 09:50:06 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7KDo53a022059
	for <saag@jis.mit.edu>; Fri, 20 Aug 2004 09:50:05 -0400 (EDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	i7KDo1np002698
	for <saag@mit.edu>; Fri, 20 Aug 2004 09:50:01 -0400 (EDT)
Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com
	[65.205.251.33])
	by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7KDlmmt015240;
	Fri, 20 Aug 2004 06:47:48 -0700 (PDT)
Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <RH7G48MA>; Fri, 20 Aug 2004 06:47:48 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEAA0@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'james hughes'" <jim_hughes@stortek.com>,
   "David A. McGrew"
	 <mcgrew@cisco.com>
Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory
Date: Fri, 20 Aug 2004 06:47:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.646708
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 20 Aug 2004 13:50:07 -0000

Err, I don't think we can simply obsolete MD5, not according to my
understanding of how the doc series works. Its informational for starters,
so it is not quite within the control scheme... We are long past the point
where the RFC series should be closed and replaced with something more
sophisticated than a flat sequence order.

There are several other docs that rely on MD5 that are not affected by the
collision attack or do not require strong security properties. I tried to
argue for eliminating MD5 in 1995 to no effect.

What we need to do is depricate MD5. This would be easier if we had a way of
obtaining a proper dependency graph for specs that require MD5.


On the HTTP Digest side I don't see that there is a major issue from mere
collisions.  There is no non-repudiation support in the scheme anyway and
the content is only going to be read once in any case. What does it matter
that there was an alternative set of data? Digest is only intended to be a
lightweight replacement for BASIC, not an SSL equivalent.

		Phill

> -----Original Message-----
> From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org]On Behalf Of
> james hughes
> Sent: Thursday, August 19, 2004 8:59 PM
> To: David A. McGrew
> Cc: saag@mit.edu; james hughes; cfrg@ietf.org; Eric Rescorla
> Subject: [Cfrg] Re: [saag] Bad day at the hash function factory
> 
> 
> One comment and two discussion points.
> 
> Can we withdraw the MD5 RFC as obsolete?
> 
> On Aug 19, 2004, at 12:23 PM, David A. McGrew wrote:
> >> WHAT'S SAFE?
> >> First, anything that's already been signed is definitely 
> safe.  If you
> >> stop using MD5 today, nothing you signed already puts you at risk.
> 
> I sign a document (in the clear) which says "... pay me $100.00 ... " 
> and now I can create a document that to  "... pay me $10,000 
> ... " with 
> a collision. Just because the original is old, why are old these 
> documents safe?
> 
> >> It's believed that HMAC is secure against this attack 
> (according to 
> >> Hugo
> >> Krawczyk, the designer) so the modern MAC functions should all be
> >> secure.
> 
> While I believe this may be true, I believe that the proof 
> that HMAC is 
> secure requires a collision resistant hash function. If this is the 
> case, then we no longer have a proof that HMAC is secure.  The SAAG 
> should understand this with open eyes.
> 
> I agree that we need to move away from MD5.
> 
> Thanks
> 
> jim
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
> 
From housley@vigilsec.com Fri Aug 20 10:16:35 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7KEGY3a022908
	for <saag@jis.mit.edu>; Fri, 20 Aug 2004 10:16:34 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i7KEGWnp021320
	for <saag@mit.edu>; Fri, 20 Aug 2004 10:16:32 -0400 (EDT)
Received: (qmail 12492 invoked by uid 0); 20 Aug 2004 14:16:30 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.1.30)
  by woodstock.binhost.com with SMTP; 20 Aug 2004 14:16:30 -0000
Message-Id: <6.1.1.1.2.20040820101325.03cbfad8@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Fri, 20 Aug 2004 10:17:12 -0400
To: james hughes <jim_hughes@stortek.com>
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
In-Reply-To: <2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
References: <20040818191747.E2C147199@sierra.rtfm.com>
 <1B38BDAC-F1FC-11D8-B277-0003935495EC@cisco.com>
 <2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000162
Spam-Alum-Time: 0.526999
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 20 Aug 2004 14:16:36 -0000

Jim:

>Can we withdraw the MD5 RFC as obsolete?

Nope.  There are a lot of mechanisms that use it.  And MD5 is the only 
integrity mechanism that we have for BGP (see 
draft-iesg-tcpmd5app-00.txt).  It will take a long time to completely move 
away from MD5.

Russ 

From rja@extremenetworks.com Fri Aug 20 11:27:37 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7KFRa3a025146
	for <saag@jis.mit.edu>; Fri, 20 Aug 2004 11:27:36 -0400 (EDT)
Received: from gnat.inet.org (rrcs-midsouth-24-172-58-252.biz.rr.com
	[24.172.58.252])i7KFRXxv009077
	for <saag@mit.edu>; Fri, 20 Aug 2004 11:27:33 -0400 (EDT)
Received: from [10.30.20.242] (unknown [10.30.20.242])
	by gnat.inet.org (Postfix) with ESMTP
	id 016FA67107; Fri, 20 Aug 2004 11:27:30 -0400 (EDT)
In-Reply-To: <6.1.1.1.2.20040820101325.03cbfad8@mail.binhost.com>
References: <20040818191747.E2C147199@sierra.rtfm.com>
	<1B38BDAC-F1FC-11D8-B277-0003935495EC@cisco.com>
	<2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
	<6.1.1.1.2.20040820101325.03cbfad8@mail.binhost.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <729D69DA-F2BD-11D8-A59F-00039357A82A@extremenetworks.com>
Content-Transfer-Encoding: 7bit
From: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
Date: Fri, 20 Aug 2004 11:27:29 -0400
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.619)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.610964
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 20 Aug 2004 15:27:37 -0000


On Aug 20, 2004, at 10:17, Russ Housley wrote:
>> Can we withdraw the MD5 RFC as obsolete?
>
> Nope.  There are a lot of mechanisms that use it.  And MD5 is the only 
> integrity mechanism that we have for BGP (see 
> draft-iesg-tcpmd5app-00.txt).  It will take a long time to completely 
> move away from MD5.

	If folks know of a specific attack against either Keyed-MD5 (which is
used by at least TCP MD5, OSPFv2 MD5, and RIPv2 MD5) or HMAC-MD5 (which 
is
used by at least ESP/AH), please publish the full bibliographic 
citation(s)
here.   I am not aware of any openly published attacks against either
application of MD5, though clearly the compression issue with MD5
(which dates back at least as far as Dobbertin's paper) is cause for 
concern.

	That said, there are a number of reasons that make it sensible to 
migrate
existing uses of Keyed-MD5 or HMAC-MD5 to HMAC-SHA-1.  (One not yet 
stated
here is that some governments (plural) insist on SHA-1 rather than MD5 
if
one wants one's implementation to obtain government certification and/or
accrediation.  FIPS 140-2 is an example of such a certification.)

	Any migration will likely take years, not months, in the deployed 
Internet.
A useful first step would be to draft specs on use of SHA-1 with TCP, 
OSPFv2,
and RIPv2 -- probably using HMAC-hash rather than Keyed-hash at the 
same time.

	Given the existence of the RPsec WG, I imagine that doing such work as
an independent submission, which is faster and simpler, would be 
erroneously
viewed as an end-run, so maybe the Security ADs could take up the issue 
with
RPsec -- hopefully on some sort of fast-track over there.  The sooner 
the
enhanced specs get to RFC -- whether standards-track or not 
(implementers
need stable openly published specs, but aren't too hung up about what is
standards-track) -- the sooner that the SHA-1 versions will be coded 
and available in shipping router images.

	And yes, algorithm-independence is a good thing, as I argued in an
article published in IEEE Computer magazine back in the mid-90s.  I 
think
that one can specify TCP-hash, OSPFv2 hash, and RIPv2 hash in an 
algorithm-
independent way without breaking backward compatibility with the 
Keyed-MD5
variant that is currently deployed.

Yours,

Ran
rja@extremenetworks.com



From rja@extremenetworks.com Fri Aug 20 12:48:30 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7KGmT3a028803
	for <saag@jis.mit.edu>; Fri, 20 Aug 2004 12:48:29 -0400 (EDT)
Received: from gnat.inet.org (rrcs-midsouth-24-172-58-252.biz.rr.com
	[24.172.58.252])i7KGmQxv004559
	for <saag@mit.edu>; Fri, 20 Aug 2004 12:48:27 -0400 (EDT)
Received: from [10.30.20.242] (unknown [10.30.20.242])
	by gnat.inet.org (Postfix) with ESMTP
	id C820A67105; Fri, 20 Aug 2004 12:48:24 -0400 (EDT)
In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA0A97D3CF@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
References: <DAC3FCB50E31C54987CD10797DA511BA0A97D3CF@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C036E1F8-F2C8-11D8-A59F-00039357A82A@extremenetworks.com>
Content-Transfer-Encoding: 7bit
From: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
Date: Fri, 20 Aug 2004 12:48:23 -0400
To: "Christian Huitema" <huitema@windows.microsoft.com>
X-Mailer: Apple Mail (2.619)
Spam-Alum-Prob: 0.000001
Spam-Alum-Time: 0.519548
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 20 Aug 2004 16:48:30 -0000


On Aug 20, 2004, at 12:10, Christian Huitema wrote:
> Actually, some governments insist on the use of locally specified
> algorithm. SHA-1 is a US standard. China or Europe may well want to use
> something else.

:-)

	By the way, while SHA-1 is specified by US NIST, SHA-1 is required
by some governments other than the US, including at least one in Europe
and one in Asia/Pacific.  (I leave the remaining details as an exercise
for the reader.  :-)

Cheers,

Ran
rja@extremenetworks.com

From mouse@Sparkle.Rodents.Montreal.QC.CA Fri Aug 20 13:21:54 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7KHLr3a029920
	for <saag@jis.mit.edu>; Fri, 20 Aug 2004 13:21:53 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i7KHLpxv025233
	for <saag@mit.edu>; Fri, 20 Aug 2004 13:21:52 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA22829;
	Fri, 20 Aug 2004 13:21:49 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200408201721.NAA22829@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Fri, 20 Aug 2004 13:18:10 -0400 (EDT)
To: cfrg@ietf.org, saag@mit.edu
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEAA0@mou1wnexm05.vcorp.ad.vrsn.com>
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEAA0@mou1wnexm05.vcorp.ad.vrsn.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.568277
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 20 Aug 2004 17:21:54 -0000

> There are several other docs that rely on MD5 that are not affected
> by the collision attack or do not require strong security properties.

Not requiring strong security properties, fine; but in that case why
not just use a CRC?  The real issue, as I understand it, is not so much
that MD5 is now broken for all purposes (which it isn't, at least not
publicly) but that with collisions found, the handwriting is on the
wall; it now seems highly likely that within a relatively short time
(years if we're lucky, months if we're not), someone _will_ break it
completely - and it would be good to have already moved away from it by
the time that happens.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From mcr@sandelman.ottawa.on.ca Sat Aug 21 12:43:00 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7LGgx3a002739
	for <saag@jis.mit.edu>; Sat, 21 Aug 2004 12:42:59 -0400 (EDT)
Received: from noxmail.sandelman.ottawa.on.ca
	(cyphermail.sandelman.ottawa.on.ca [205.150.200.161])i7LGgvIk008483
	for <saag@mit.edu>; Sat, 21 Aug 2004 12:42:57 -0400 (EDT)
Received: from lox.sandelman.ottawa.on.ca
	(IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178])
	i7LGgq825200;	Sat, 21 Aug 2004 12:42:52 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca
	[205.150.200.247])i7LGnqj25619verified FAIL);
	Sat, 21 Aug 2004 12:49:57 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1])
	i7LGgUPG018536
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Sat, 21 Aug 2004 12:42:30 -0400
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	i7LGgTKI018533;	Sat, 21 Aug 2004 12:42:29 -0400
To: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory 
In-Reply-To: Message from RJ Atkinson <rja@extremenetworks.com> 
	<729D69DA-F2BD-11D8-A59F-00039357A82A@extremenetworks.com> 
References: <20040818191747.E2C147199@sierra.rtfm.com>
	<1B38BDAC-F1FC-11D8-B277-0003935495EC@cisco.com>
	<2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
	<6.1.1.1.2.20040820101325.03cbfad8@mail.binhost.com>
	<729D69DA-F2BD-11D8-A59F-00039357A82A@extremenetworks.com> 
X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6)
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Sat, 21 Aug 2004 12:42:29 -0400
Message-ID: <18532.1093106549@marajade.sandelman.ottawa.on.ca>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.594915
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 21 Aug 2004 16:43:00 -0000

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "RJ" == RJ Atkinson <rja@extremenetworks.com> writes:
    RJ> 	That said, there are a number of reasons that make it
    RJ> sensible to migrate existing uses of Keyed-MD5 or HMAC-MD5 to
    RJ> HMAC-SHA-1.  (One not yet stated here is that some governments

  In the IPsec space, we can most easily move to SHA-1, because it is
very commonly deployed (for many reasons).
  
  In doing so, however, I want to start commonly deploying another hash
as well. 
  I.e. it is not enough to deprecate HMAC-MD5 (which I understand is not
know to be vulnerable), and make HMAC-SHA1 the default. I want to make
HMAC-SHA1 + QQQQ the new set of algorithms.
  having that "spare" out there is pretty useful.
 
  I'm not convinced SHA-2 is right.
  Maybe AES-XMAC. I don't know at this time.

    RJ> 	Any migration will likely take years, not months, in the
    RJ> deployed Internet.  A useful first step would be to draft specs
    RJ> on use of SHA-1 with TCP, OSPFv2, and RIPv2 -- probably using
    RJ> HMAC-hash rather than Keyed-hash at the same time.

  I agree.

    RJ> 	And yes, algorithm-independence is a good thing, as I
    RJ> argued in an article published in IEEE Computer magazine back in
    RJ> the mid-90s.  I think that one can specify TCP-hash, OSPFv2
    RJ> hash, and RIPv2 hash in an algorithm- independent way without
    RJ> breaking backward compatibility with the Keyed-MD5 variant that
    RJ> is currently deployed.

  I doubly agree.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQSd7c4qHRg3pndX9AQGvfgQAmfRc6adMxhTU2haTw436BAXiD4LE/O3f
hLJ0YhHeHw3X/GlQx4nQmIkenRZ7v7aqPEbSj7coAC4NXfJphLv+cawFWTRCYyZs
2IulvZuOr+Baj7/00jmX4aLECP9kqu55fTH57/pHOZc1HNCUkfIiRbfDjIgBDBwL
1S3/MIv9H4Y=
=ii+Z
-----END PGP SIGNATURE-----
From housley@vigilsec.com Mon Aug 23 09:45:32 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7NDjV3a014243
	for <saag@jis.mit.edu>; Mon, 23 Aug 2004 09:45:31 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i7NDjRXM026578
	for <saag@mit.edu>; Mon, 23 Aug 2004 09:45:27 -0400 (EDT)
Received: (qmail 2149 invoked by uid 0); 23 Aug 2004 13:45:25 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.237.4)
  by woodstock.binhost.com with SMTP; 23 Aug 2004 13:45:25 -0000
Message-Id: <6.1.1.1.2.20040823094107.03724a38@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Mon, 23 Aug 2004 09:46:09 -0400
To: saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.624244
Subject: [saag] The Call Is Cheap; The Wiretap Is Extra
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 23 Aug 2004 13:45:33 -0000

Here is a short excerpt from "The Call Is Cheap. The Wiretap Is Extra." by 
Ken Belson.  It was published on August 23, 2004.

   At first glance, it might seem like the simple extension of a standard tool
   in the fight against the bad guys.

   But in fact, wiretapping Internet phones to monitor criminals and terrorists
   is costly and complex, and potentially a big burden on new businesses trying
   to sell the phone service.

   Earlier this month, the Federal Communications Commission voted unanimously
   to move forward with rules that would compel the businesses to make it
   possible for law enforcement agencies to eavesdrop on Internet calls.

   But developing systems to wiretap calls that travel over high-speed data
   networks - a task that the companies are being asked to pay for - has caused
   executives and some lawmakers to worry that helping the police may stifle
   innovation and force the budding industry to alter its services. That
   requirement, they say, could undermine some of the reasons Internet phones
   are starting to become popular: lower cost and more flexible features.

   The commission's preliminary decision, announced on Aug. 4, is a major step
   in the long process of deciding how Internet-based conversations could be
   monitored. Regulators will now hear three months of public testimony on the
   ruling. Few expect a resolution of the issue this year, but it is not hard
   to figure out who will ultimately pay for the wiretapping capability.

   Tapping Internet phones is far more complicated than listening in on
   traditional calls because the wiretapper has to isolate voice packets moving
   over the Internet from data and other information packets also traveling on
   the network.

   While traditional calls are steady electronic voice signals sent over a
   dedicated wire, Internet calls move as data packets containing as little as
   a hundredth of a second of sound, or less than one syllable, which follow
   often-unpredictable paths before they are reassembled on the receiving end
   to form a conversation.

Food for thought and SAAG discussion ....

Russ

From bgiordan@cisco.com Mon Aug 23 15:14:48 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7NJEl3a024613
	for <saag@jis.mit.edu>; Mon, 23 Aug 2004 15:14:47 -0400 (EDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149])
	i7NJEjQl021352
	for <saag@mit.edu>; Mon, 23 Aug 2004 15:14:45 -0400 (EDT)
Received: from rtp-core-2.cisco.com (64.102.124.13)
  by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2004 15:14:45 -0400
X-BrightmailFiltered: true
Received: from bgiordanw2k04 (dhcp-128-107-163-52.cisco.com [128.107.163.52])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id i7NJEgY3017413;
	Mon, 23 Aug 2004 15:14:43 -0400 (EDT)
Message-ID: <023101c48945$739b1ab0$34a36b80@amer.cisco.com>
From: "Bart Giordano" <bgiordan@cisco.com>
To: <saag@mit.edu>, "Russ Housley" <housley@vigilsec.com>
References: <6.1.1.1.2.20040823094107.03724a38@mail.binhost.com>
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
Date: Mon, 23 Aug 2004 12:14:44 -0700
Organization: Cisco Systems, Inc. - IOS Security Solutions
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.690465
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 23 Aug 2004 19:14:48 -0000

Many of the same arguments presented here were raised by mobile phone makers
and wireless service providers when they were forced to support wire-tapping
for wireless phone calls (and they recently recycled these same arguments
for E-911/GPS as well as Portable Number technologies).

Since the technology to "isolate voice packets moving over the Internet"
from data traffic already exists, this solution likely isn't going to
"stifle innovation" or undermine the "lower cost and more flexible features"
of Internet phone service. And many manufacturer's and providers already
offer technology to allow law enforcement to conduct electronic surveillance
of circuit AND packet-switched communications over data networks. It's
really just an appeal to pity used by the equipment and service providers
against the new rules, and one that they are ultimately going to lose.

Last time I checked, my mobile phone service was extremely cheap and full of
features despite the fact that they were compelled to offer wire-tapping and
the other technologies mentioned above. Traditional wired service providers
are now being forced to offer Internet phone service just to remain
competitive with the wireless market. It's hard to believe that simply
applying the same technology to Internet phone service is going to
dramatically affect the business models or service offerings in the Internet
Phone space.

 -bg

----- Original Message ----- 
From: "Russ Housley" <housley@vigilsec.com>
To: <saag@mit.edu>
Sent: Monday, August 23, 2004 6:46 AM
Subject: [saag] The Call Is Cheap; The Wiretap Is Extra


> Here is a short excerpt from "The Call Is Cheap. The Wiretap Is Extra." by
> Ken Belson.  It was published on August 23, 2004.
>
>    At first glance, it might seem like the simple extension of a standard
tool
>    in the fight against the bad guys.
>
>    But in fact, wiretapping Internet phones to monitor criminals and
terrorists
>    is costly and complex, and potentially a big burden on new businesses
trying
>    to sell the phone service.
>
>    Earlier this month, the Federal Communications Commission voted
unanimously
>    to move forward with rules that would compel the businesses to make it
>    possible for law enforcement agencies to eavesdrop on Internet calls.
>
>    But developing systems to wiretap calls that travel over high-speed
data
>    networks - a task that the companies are being asked to pay for - has
caused
>    executives and some lawmakers to worry that helping the police may
stifle
>    innovation and force the budding industry to alter its services. That
>    requirement, they say, could undermine some of the reasons Internet
phones
>    are starting to become popular: lower cost and more flexible features.
>
>    The commission's preliminary decision, announced on Aug. 4, is a major
step
>    in the long process of deciding how Internet-based conversations could
be
>    monitored. Regulators will now hear three months of public testimony on
the
>    ruling. Few expect a resolution of the issue this year, but it is not
hard
>    to figure out who will ultimately pay for the wiretapping capability.
>
>    Tapping Internet phones is far more complicated than listening in on
>    traditional calls because the wiretapper has to isolate voice packets
moving
>    over the Internet from data and other information packets also
traveling on
>    the network.
>
>    While traditional calls are steady electronic voice signals sent over a
>    dedicated wire, Internet calls move as data packets containing as
little as
>    a hundredth of a second of sound, or less than one syllable, which
follow
>    often-unpredictable paths before they are reassembled on the receiving
end
>    to form a conversation.
>
> Food for thought and SAAG discussion ....
>
> Russ
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>

From beardd@nortelnetworks.com Mon Aug 23 15:55:52 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7NJto3a026038
	for <saag@jis.mit.edu>; Mon, 23 Aug 2004 15:55:50 -0400 (EDT)
Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com
	[47.140.192.55])i7NJtnQl026397
	for <saag@mit.edu>; Mon, 23 Aug 2004 15:55:49 -0400 (EDT)
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	id i7NJtlZ16680;	Mon, 23 Aug 2004 15:55:47 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <RNXXN6WQ>; Mon, 23 Aug 2004 15:55:43 -0400
Message-ID: <0CCD4D34B2952A48AB838DF2D5C840D701298D73@zcarhxm0.corp.nortel.com>
From: "Dennis Beard" <beardd@nortelnetworks.com>
To: Bart Giordano <bgiordan@cisco.com>, saag@mit.edu,
   Russ Housley
	 <housley@vigilsec.com>
Subject: RE: [saag] The Call Is Cheap; The Wiretap Is Extra
Date: Mon, 23 Aug 2004 15:55:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4894B.2DB66C50"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 1.221636
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 23 Aug 2004 19:55:52 -0000

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4894B.2DB66C50
Content-Type: text/plain

Very good points Bart succinctly stated.  It needed to be said.  


Cheers,

Dennis Beard
-----Original Message-----
From: Bart Giordano [mailto:bgiordan@cisco.com] 
Sent: Monday, August 23, 2004 3:15 PM
To: saag@mit.edu; Russ Housley
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra


Many of the same arguments presented here were raised by mobile phone makers
and wireless service providers when they were forced to support wire-tapping
for wireless phone calls (and they recently recycled these same arguments
for E-911/GPS as well as Portable Number technologies).

Since the technology to "isolate voice packets moving over the Internet"
from data traffic already exists, this solution likely isn't going to
"stifle innovation" or undermine the "lower cost and more flexible features"
of Internet phone service. And many manufacturer's and providers already
offer technology to allow law enforcement to conduct electronic surveillance
of circuit AND packet-switched communications over data networks. It's
really just an appeal to pity used by the equipment and service providers
against the new rules, and one that they are ultimately going to lose.

Last time I checked, my mobile phone service was extremely cheap and full of
features despite the fact that they were compelled to offer wire-tapping and
the other technologies mentioned above. Traditional wired service providers
are now being forced to offer Internet phone service just to remain
competitive with the wireless market. It's hard to believe that simply
applying the same technology to Internet phone service is going to
dramatically affect the business models or service offerings in the Internet
Phone space.

 -bg

----- Original Message ----- 
From: "Russ Housley" <housley@vigilsec.com>
To: <saag@mit.edu>
Sent: Monday, August 23, 2004 6:46 AM
Subject: [saag] The Call Is Cheap; The Wiretap Is Extra


> Here is a short excerpt from "The Call Is Cheap. The Wiretap Is 
> Extra." by Ken Belson.  It was published on August 23, 2004.
>
>    At first glance, it might seem like the simple extension of a 
> standard
tool
>    in the fight against the bad guys.
>
>    But in fact, wiretapping Internet phones to monitor criminals and
terrorists
>    is costly and complex, and potentially a big burden on new 
> businesses
trying
>    to sell the phone service.
>
>    Earlier this month, the Federal Communications Commission voted
unanimously
>    to move forward with rules that would compel the businesses to make it
>    possible for law enforcement agencies to eavesdrop on Internet 
> calls.
>
>    But developing systems to wiretap calls that travel over high-speed
data
>    networks - a task that the companies are being asked to pay for - 
> has
caused
>    executives and some lawmakers to worry that helping the police may
stifle
>    innovation and force the budding industry to alter its services. That
>    requirement, they say, could undermine some of the reasons Internet
phones
>    are starting to become popular: lower cost and more flexible 
> features.
>
>    The commission's preliminary decision, announced on Aug. 4, is a 
> major
step
>    in the long process of deciding how Internet-based conversations 
> could
be
>    monitored. Regulators will now hear three months of public 
> testimony on
the
>    ruling. Few expect a resolution of the issue this year, but it is 
> not
hard
>    to figure out who will ultimately pay for the wiretapping 
> capability.
>
>    Tapping Internet phones is far more complicated than listening in on
>    traditional calls because the wiretapper has to isolate voice 
> packets
moving
>    over the Internet from data and other information packets also
traveling on
>    the network.
>
>    While traditional calls are steady electronic voice signals sent over a
>    dedicated wire, Internet calls move as data packets containing as
little as
>    a hundredth of a second of sound, or less than one syllable, which
follow
>    often-unpredictable paths before they are reassembled on the 
> receiving
end
>    to form a conversation.
>
> Food for thought and SAAG discussion ....
>
> Russ
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>

_______________________________________________
saag mailing list
saag@mit.edu
https://jis.mit.edu/mailman/listinfo/saag

------_=_NextPart_001_01C4894B.2DB66C50
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [saag] The Call Is Cheap; The Wiretap Is Extra</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Very good points Bart succinctly stated.&nbsp; It =
needed to be said.&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Cheers,</FONT>
</P>

<P><FONT SIZE=3D2>Dennis Beard</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Bart Giordano [<A =
HREF=3D"mailto:bgiordan@cisco.com">mailto:bgiordan@cisco.com</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, August 23, 2004 3:15 PM</FONT>
<BR><FONT SIZE=3D2>To: saag@mit.edu; Russ Housley</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [saag] The Call Is Cheap; The Wiretap =
Is Extra</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Many of the same arguments presented here were raised =
by mobile phone makers and wireless service providers when they were =
forced to support wire-tapping for wireless phone calls (and they =
recently recycled these same arguments for E-911/GPS as well as =
Portable Number technologies).</FONT></P>

<P><FONT SIZE=3D2>Since the technology to &quot;isolate voice packets =
moving over the Internet&quot; from data traffic already exists, this =
solution likely isn't going to &quot;stifle innovation&quot; or =
undermine the &quot;lower cost and more flexible features&quot; of =
Internet phone service. And many manufacturer's and providers already =
offer technology to allow law enforcement to conduct electronic =
surveillance of circuit AND packet-switched communications over data =
networks. It's really just an appeal to pity used by the equipment and =
service providers against the new rules, and one that they are =
ultimately going to lose.</FONT></P>

<P><FONT SIZE=3D2>Last time I checked, my mobile phone service was =
extremely cheap and full of features despite the fact that they were =
compelled to offer wire-tapping and the other technologies mentioned =
above. Traditional wired service providers are now being forced to =
offer Internet phone service just to remain competitive with the =
wireless market. It's hard to believe that simply applying the same =
technology to Internet phone service is going to dramatically affect =
the business models or service offerings in the Internet Phone =
space.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;-bg</FONT>
</P>

<P><FONT SIZE=3D2>----- Original Message ----- </FONT>
<BR><FONT SIZE=3D2>From: &quot;Russ Housley&quot; =
&lt;housley@vigilsec.com&gt;</FONT>
<BR><FONT SIZE=3D2>To: &lt;saag@mit.edu&gt;</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, August 23, 2004 6:46 AM</FONT>
<BR><FONT SIZE=3D2>Subject: [saag] The Call Is Cheap; The Wiretap Is =
Extra</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; Here is a short excerpt from &quot;The Call Is =
Cheap. The Wiretap Is </FONT>
<BR><FONT SIZE=3D2>&gt; Extra.&quot; by Ken Belson.&nbsp; It was =
published on August 23, 2004.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; At first glance, it might =
seem like the simple extension of a </FONT>
<BR><FONT SIZE=3D2>&gt; standard</FONT>
<BR><FONT SIZE=3D2>tool</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; in the fight against the bad =
guys.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; But in fact, wiretapping =
Internet phones to monitor criminals and</FONT>
<BR><FONT SIZE=3D2>terrorists</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; is costly and complex, and =
potentially a big burden on new </FONT>
<BR><FONT SIZE=3D2>&gt; businesses</FONT>
<BR><FONT SIZE=3D2>trying</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; to sell the phone =
service.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Earlier this month, the =
Federal Communications Commission voted</FONT>
<BR><FONT SIZE=3D2>unanimously</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; to move forward with rules =
that would compel the businesses to make it</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; possible for law enforcement =
agencies to eavesdrop on Internet </FONT>
<BR><FONT SIZE=3D2>&gt; calls.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; But developing systems to =
wiretap calls that travel over high-speed</FONT>
<BR><FONT SIZE=3D2>data</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; networks - a task that the =
companies are being asked to pay for - </FONT>
<BR><FONT SIZE=3D2>&gt; has</FONT>
<BR><FONT SIZE=3D2>caused</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; executives and some lawmakers =
to worry that helping the police may</FONT>
<BR><FONT SIZE=3D2>stifle</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; innovation and force the =
budding industry to alter its services. That</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; requirement, they say, could =
undermine some of the reasons Internet</FONT>
<BR><FONT SIZE=3D2>phones</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; are starting to become =
popular: lower cost and more flexible </FONT>
<BR><FONT SIZE=3D2>&gt; features.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; The commission's preliminary =
decision, announced on Aug. 4, is a </FONT>
<BR><FONT SIZE=3D2>&gt; major</FONT>
<BR><FONT SIZE=3D2>step</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; in the long process of =
deciding how Internet-based conversations </FONT>
<BR><FONT SIZE=3D2>&gt; could</FONT>
<BR><FONT SIZE=3D2>be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; monitored. Regulators will =
now hear three months of public </FONT>
<BR><FONT SIZE=3D2>&gt; testimony on</FONT>
<BR><FONT SIZE=3D2>the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; ruling. Few expect a =
resolution of the issue this year, but it is </FONT>
<BR><FONT SIZE=3D2>&gt; not</FONT>
<BR><FONT SIZE=3D2>hard</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; to figure out who will =
ultimately pay for the wiretapping </FONT>
<BR><FONT SIZE=3D2>&gt; capability.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Tapping Internet phones is =
far more complicated than listening in on</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; traditional calls because the =
wiretapper has to isolate voice </FONT>
<BR><FONT SIZE=3D2>&gt; packets</FONT>
<BR><FONT SIZE=3D2>moving</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; over the Internet from data =
and other information packets also</FONT>
<BR><FONT SIZE=3D2>traveling on</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the network.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; While traditional calls are =
steady electronic voice signals sent over a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; dedicated wire, Internet =
calls move as data packets containing as</FONT>
<BR><FONT SIZE=3D2>little as</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; a hundredth of a second of =
sound, or less than one syllable, which</FONT>
<BR><FONT SIZE=3D2>follow</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; often-unpredictable paths =
before they are reassembled on the </FONT>
<BR><FONT SIZE=3D2>&gt; receiving</FONT>
<BR><FONT SIZE=3D2>end</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; to form a =
conversation.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Food for thought and SAAG discussion =
....</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; saag mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; saag@mit.edu</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://jis.mit.edu/mailman/listinfo/saag" =
TARGET=3D"_blank">https://jis.mit.edu/mailman/listinfo/saag</A></FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>saag mailing list</FONT>
<BR><FONT SIZE=3D2>saag@mit.edu</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://jis.mit.edu/mailman/listinfo/saag" =
TARGET=3D"_blank">https://jis.mit.edu/mailman/listinfo/saag</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4894B.2DB66C50--
From huitema@windows.microsoft.com Tue Aug 10 16:37:44 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7AKbh3a003497
	for <saag@jis.mit.edu>; Tue, 10 Aug 2004 16:37:43 -0400 (EDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	i7AKbdav026094
	for <saag@mit.edu>; Tue, 10 Aug 2004 16:37:40 -0400 (EDT)
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.196);
	Tue, 10 Aug 2004 13:37:59 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by
	mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	Tue, 10 Aug 2004 13:37:19 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com
	([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft
	SMTPSVC(6.0.3790.0);	 Tue, 10 Aug 2004 13:37:22 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com
	([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with
	Microsoft SMTPSVC(6.0.3790.1069);	 Tue, 10 Aug 2004 13:36:30 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [saag] Last Call: 'Randomness Requirements for Security'  to BCP
Date: Tue, 10 Aug 2004 13:37:22 -0700
Message-ID: <DAC3FCB50E31C54987CD10797DA511BA0A74F548@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag] Last Call: 'Randomness Requirements for Security'  to BCP
thread-index: AcR+/HxshYz/ptXbQESHkJHqDnEBbQAHEDLA
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Russ Housley" <housley@vigilsec.com>,
   "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, <saag@mit.edu>
X-OriginalArrivalTime: 10 Aug 2004 20:36:30.0062 (UTC)
	FILETIME=[B75F90E0:01C47F19]
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.525388
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id
	i7AKbh3a003497
X-Mailman-Approved-At: Mon, 23 Aug 2004 18:53:00 -0400
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 10 Aug 2004 20:37:44 -0000

> >It'd be great if this spec also gave some specific guidance
> >to windows programmers who don't have e.g. /dev/audio (and
> >no, I don't have text to offer unfortunately).
> >
> >Surely msft must've done a tech note or something that
> >could be copied/referenced?

Windows programmers should use the "CryptGenRandom" API
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccry
pto/security/cryptgenrandom.asp). 

.Net programmers should use the RNGCryptoServiceProvider Class
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/
html/frlrfsystemsecuritycryptographyrngcryptoserviceproviderclassgetbyte
stopic.asp)

-- Christian Huitema


From jim_hughes@stortek.com Thu Aug 19 20:59:40 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7K0xd3a029606
	for <saag@jis.mit.edu>; Thu, 19 Aug 2004 20:59:39 -0400 (EDT)
Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146])
	i7K0xbCa026122
	for <saag@mit.edu>; Thu, 19 Aug 2004 20:59:38 -0400 (EDT)
Received: from sherman.stortek.com (localhost [127.0.0.1])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id i7K0xZKR020793
	for <saag@mit.edu>; Thu, 19 Aug 2004 18:59:36 -0600 (MDT)
Received: from [129.191.63.222] (puck.network.com [129.191.63.222])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id i7K0xTCr020773;
	Thu, 19 Aug 2004 18:59:31 -0600 (MDT)
In-Reply-To: <1B38BDAC-F1FC-11D8-B277-0003935495EC@cisco.com>
References: <20040818191747.E2C147199@sierra.rtfm.com>
	<1B38BDAC-F1FC-11D8-B277-0003935495EC@cisco.com>
Mime-Version: 1.0 (Apple Message framework v667)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
Content-Transfer-Encoding: 7bit
From: james hughes <jim_hughes@stortek.com>
Subject: Re: [saag] Bad day at the hash function factory
Date: Thu, 19 Aug 2004 20:59:27 -0400
To: "David A. McGrew" <mcgrew@cisco.com>
X-Mailer: Apple Mail (2.667)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.555044
X-Mailman-Approved-At: Mon, 23 Aug 2004 18:53:00 -0400
cc: cfrg@ietf.org
cc: james hughes <jim_hughes@stortek.com>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 20 Aug 2004 00:59:40 -0000

One comment and two discussion points.

Can we withdraw the MD5 RFC as obsolete?

On Aug 19, 2004, at 12:23 PM, David A. McGrew wrote:
>> WHAT'S SAFE?
>> First, anything that's already been signed is definitely safe.  If you
>> stop using MD5 today, nothing you signed already puts you at risk.

I sign a document (in the clear) which says "... pay me $100.00 ... " 
and now I can create a document that to  "... pay me $10,000 ... " with 
a collision. Just because the original is old, why are old these 
documents safe?

>> It's believed that HMAC is secure against this attack (according to 
>> Hugo
>> Krawczyk, the designer) so the modern MAC functions should all be
>> secure.

While I believe this may be true, I believe that the proof that HMAC is 
secure requires a collision resistant hash function. If this is the 
case, then we no longer have a proof that HMAC is secure.  The SAAG 
should understand this with open eyes.

I agree that we need to move away from MD5.

Thanks

jim
From canetti@watson.ibm.com Fri Aug 20 11:34:54 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7KFYr3a025507
	for <saag@jis.mit.edu>; Fri, 20 Aug 2004 11:34:54 -0400 (EDT)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6])
	i7KFYqxv014292
	for <saag@mit.edu>; Fri, 20 Aug 2004 11:34:52 -0400 (EDT)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com
	[129.34.20.41])i7KFWkc73054;	Fri, 20 Aug 2004 11:32:46 -0400
Received: from ornavella.watson.ibm.com (localhost [127.0.0.1])
	(8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i7KFYli49448;
	Fri, 20 Aug 2004 11:34:47 -0400
Received: from localhost (canetti@localhost)ESMTP id i7KFYkI32140;
	Fri, 20 Aug 2004 11:34:46 -0400
Date: Fri, 20 Aug 2004 11:34:45 -0400 (EDT)
From: canetti <canetti@watson.ibm.com>
To: Russ Housley <housley@vigilsec.com>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
In-Reply-To: <6.1.1.1.2.20040820101325.03cbfad8@mail.binhost.com>
Message-ID: <Pine.A41.4.58.0408201132190.35316@ornavella.watson.ibm.com>
References: <20040818191747.E2C147199@sierra.rtfm.com>
	<2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
	<6.1.1.1.2.20040820101325.03cbfad8@mail.binhost.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Spam-Alum-Prob: 0.000001
Spam-Alum-Time: 0.617016
X-Mailman-Approved-At: Mon, 23 Aug 2004 18:53:00 -0400
cc: cfrg@ietf.org
cc: james hughes <jim_hughes@stortek.com>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 20 Aug 2004 15:34:55 -0000


For instance, nothing in the new results points to discernable weaknesses
in using HMAC-MD5 as a MAC or a PRF.

Ran

On Fri, 20 Aug 2004, Russ Housley wrote:

> Jim:
>
> >Can we withdraw the MD5 RFC as obsolete?
>
> Nope.  There are a lot of mechanisms that use it.  And MD5 is the only
> integrity mechanism that we have for BGP (see
> draft-iesg-tcpmd5app-00.txt).  It will take a long time to completely move
> away from MD5.
>
> Russ
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
>
From huitema@windows.microsoft.com Fri Aug 20 12:10:48 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7KGAl3a026885
	for <saag@jis.mit.edu>; Fri, 20 Aug 2004 12:10:47 -0400 (EDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	i7KGAdxv007538
	for <saag@mit.edu>; Fri, 20 Aug 2004 12:10:40 -0400 (EDT)
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.196);
	Fri, 20 Aug 2004 09:10:39 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by
	mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	Fri, 20 Aug 2004 09:10:25 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com
	([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft
	SMTPSVC(6.0.3790.1069);	 Fri, 20 Aug 2004 09:10:38 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com
	([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with
	Microsoft SMTPSVC(6.0.3790.1069);	 Fri, 20 Aug 2004 09:09:40 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory
Date: Fri, 20 Aug 2004 09:10:38 -0700
Message-ID: <DAC3FCB50E31C54987CD10797DA511BA0A97D3CF@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Cfrg] Re: [saag] Bad day at the hash function factory
thread-index: AcSGz2xgZx2tt4CLQiOdnSFiKlxgGAAAJqcw
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "RJ Atkinson" <rja@extremenetworks.com>,
   "Russ Housley" <housley@vigilsec.com>
X-OriginalArrivalTime: 20 Aug 2004 16:09:40.0751 (UTC)
	FILETIME=[193611F0:01C486D0]
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.529800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id
	i7KGAl3a026885
X-Mailman-Approved-At: Mon, 23 Aug 2004 18:53:00 -0400
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 20 Aug 2004 16:10:49 -0000

> 	That said, there are a number of reasons that make it sensible
to
> migrate
> existing uses of Keyed-MD5 or HMAC-MD5 to HMAC-SHA-1.  (One not yet
> stated
> here is that some governments (plural) insist on SHA-1 rather than MD5
> if
> one wants one's implementation to obtain government certification
and/or
> accrediation.  FIPS 140-2 is an example of such a certification.)

Actually, some governments insist on the use of locally specified
algorithm. SHA-1 is a US standard. China or Europe may well want to use
something else.

-- Christian Huitema

From dee3@pothole.com Sun Aug 22 12:32:04 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7MGW33a008171
	for <saag@jis.mit.edu>; Sun, 22 Aug 2004 12:32:03 -0400 (EDT)
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	i7MGW1Ok001965
	for <saag@mit.edu>; Sun, 22 Aug 2004 12:32:01 -0400 (EDT)
Received: from pothole.com ([24.62.71.160])
          by comcast.net (rwcrmhc13) with ESMTP
          id <2004082216320001500p7guse>; Sun, 22 Aug 2004 16:32:00 +0000
Received: from pothole.com (localhost.localdomain [127.0.0.1])
	by pothole.com (8.12.11/8.12.11) with ESMTP id i7MGTrI5020494;
	Sun, 22 Aug 2004 12:29:53 -0400
Received: from localhost (dee3@localhost)
	by pothole.com (8.12.11/8.12.11/Submit) with ESMTP id i7MGTrLS020491;
	Sun, 22 Aug 2004 12:29:53 -0400
Date: Sun, 22 Aug 2004 12:29:53 -0400 (EDT)
From: dee3@pothole.com
X-X-Sender: dee3@pothole.com
To: cfrg@ietf.org, saag@mit.edu
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory 
In-Reply-To: <18532.1093106549@marajade.sandelman.ottawa.on.ca>
Message-ID: <Pine.LNX.4.60.0408221227070.19986@pothole.com>
References: <20040818191747.E2C147199@sierra.rtfm.com>
	<2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
	<6.1.1.1.2.20040820101325.03cbfad8@mail.binhost.com>
	<729D69DA-F2BD-11D8-A59F-00039357A82A@extremenetworks.com> 
	<18532.1093106549@marajade.sandelman.ottawa.on.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.622622
X-Mailman-Approved-At: Mon, 23 Aug 2004 18:53:00 -0400
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 22 Aug 2004 16:32:04 -0000

See draft-ietf-ipsec-esp-ah-algorithms-01.txt.

Thanks,
Donald
======================================================================
  Donald E. Eastlake 3rd                       dee3@torque.pothole.com
  155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
  Milford, MA 01757 USA                   Donald.Eastlake@motorola.com

On Sat, 21 Aug 2004, Michael Richardson wrote:

> Date: Sat, 21 Aug 2004 12:42:29 -0400
> From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
> To: RJ Atkinson <rja@extremenetworks.com>
> Cc: cfrg@ietf.org, saag@mit.edu
> Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
>>>>>> "RJ" == RJ Atkinson <rja@extremenetworks.com> writes:
>    RJ> 	That said, there are a number of reasons that make it
>    RJ> sensible to migrate existing uses of Keyed-MD5 or HMAC-MD5 to
>    RJ> HMAC-SHA-1.  (One not yet stated here is that some governments
>
>  In the IPsec space, we can most easily move to SHA-1, because it is
> very commonly deployed (for many reasons).
>
>  In doing so, however, I want to start commonly deploying another hash
> as well.
>  I.e. it is not enough to deprecate HMAC-MD5 (which I understand is not
> know to be vulnerable), and make HMAC-SHA1 the default. I want to make
> HMAC-SHA1 + QQQQ the new set of algorithms.
>  having that "spare" out there is pretty useful.
>
>  I'm not convinced SHA-2 is right.
>  Maybe AES-XMAC. I don't know at this time.
>
>    RJ> 	Any migration will likely take years, not months, in the
>    RJ> deployed Internet.  A useful first step would be to draft specs
>    RJ> on use of SHA-1 with TCP, OSPFv2, and RIPv2 -- probably using
>    RJ> HMAC-hash rather than Keyed-hash at the same time.
>
>  I agree.
>
>    RJ> 	And yes, algorithm-independence is a good thing, as I
>    RJ> argued in an article published in IEEE Computer magazine back in
>    RJ> the mid-90s.  I think that one can specify TCP-hash, OSPFv2
>    RJ> hash, and RIPv2 hash in an algorithm- independent way without
>    RJ> breaking backward compatibility with the Keyed-MD5 variant that
>    RJ> is currently deployed.
>
>  I doubly agree.
>
> - --
> ]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
> ]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
> ] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
From jis@MIT.EDU Mon Aug 23 19:05:56 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7NN5t3a002835;
	Mon, 23 Aug 2004 19:05:55 -0400 (EDT)
Received: from jis.tzo.com (JISVPN.MIT.EDU [18.100.101.102])
	i7NN5OpE027053;	Mon, 23 Aug 2004 19:05:24 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.12.8p2/8.12.8) id i7NN5Fu5002185;
	Mon, 23 Aug 2004 19:05:15 -0400
X-Authentication-Warning: jis.tzo.com: jis set sender to jis@mit.edu using -f
Date: Mon, 23 Aug 2004 19:05:15 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Dennis Beard <beardd@nortelnetworks.com>
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
Message-ID: <20040823190515.B1953@mit.edu>
References: <0CCD4D34B2952A48AB838DF2D5C840D701298D73@zcarhxm0.corp.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To:
	<0CCD4D34B2952A48AB838DF2D5C840D701298D73@zcarhxm0.corp.nortel.com>; from
	beardd@nortelnetworks.com on Mon, Aug 23, 2004 at 03:55:12PM -0400
Spam-Alum-Prob: 0.000327
Spam-Alum-Prob: 0.081784
Spam-Alum-Time: 0.519677
Spam-Alum-Time: 0.963028
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 23 Aug 2004 23:05:57 -0000

But if I make a VoIP call from my office to someone across campus,
via an outside SIP provider, the talking path should not leave my
campus. How can the outside SIP provider then get access to the
talking path (without my being able to figure out that I was being
tapped)?

			-Jeff
From bgiordan@cisco.com Mon Aug 23 19:19:40 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7NNJe3a003244;
	Mon, 23 Aug 2004 19:19:40 -0400 (EDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86])
	i7NNJOpE006556;	Mon, 23 Aug 2004 19:19:24 -0400 (EDT)
X-BrightmailFiltered: true
Received: from bgiordanw2k04 (stealth-10-32-244-61.cisco.com [10.32.244.61])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id i7NNHgDL005174;
	Mon, 23 Aug 2004 16:17:42 -0700 (PDT)
Message-ID: <002901c48967$640dcf80$3df4200a@amer.cisco.com>
From: "Bart Giordano" <bgiordan@cisco.com>
To: "Jeffrey I. Schiller" <jis@mit.edu>,
   "Dennis Beard" <beardd@nortelnetworks.com>
References:
	<0CCD4D34B2952A48AB838DF2D5C840D701298D73@zcarhxm0.corp.nortel.com>
	<20040823190515.B1953@mit.edu>
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
Date: Mon, 23 Aug 2004 16:17:41 -0700
Organization: Cisco Systems, Inc. - IOS Security Solutions
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.578244
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 23 Aug 2004 23:19:41 -0000

In this case, the agency conducting the surveillance would have to have
physical access to your organizations internal network once a warrant is
granted. You can use your imagination to figure how they might go about
doing that (or just go rent Mission Impossible ;-)).

In any event, the situation you present below really isn't specific to VoIP
calls. The same problem of physical access to the network is relevant for
traditional POTS phone systems too.

-bg

----- Original Message ----- 
From: "Jeffrey I. Schiller" <jis@mit.edu>
To: "Dennis Beard" <beardd@nortelnetworks.com>
Cc: "Bart Giordano" <bgiordan@cisco.com>; <saag@mit.edu>; "Russ Housley"
<housley@vigilsec.com>
Sent: Monday, August 23, 2004 4:05 PM
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra


> But if I make a VoIP call from my office to someone across campus,
> via an outside SIP provider, the talking path should not leave my
> campus. How can the outside SIP provider then get access to the
> talking path (without my being able to figure out that I was being
> tapped)?
>
> -Jeff
>

From jis@MIT.EDU Mon Aug 23 19:31:11 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7NNVA3a003628;
	Mon, 23 Aug 2004 19:31:10 -0400 (EDT)
Received: from jis.tzo.com (JISVPN.MIT.EDU [18.100.101.102])
	i7NNUh7Y022906;	Mon, 23 Aug 2004 19:30:43 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.12.8p2/8.12.8) id i7NNULlR002566;
	Mon, 23 Aug 2004 19:30:21 -0400
X-Authentication-Warning: jis.tzo.com: jis set sender to jis@mit.edu using -f
Date: Mon, 23 Aug 2004 19:30:21 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Bart Giordano <bgiordan@cisco.com>
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
Message-ID: <20040823193021.A2547@mit.edu>
References:
	<0CCD4D34B2952A48AB838DF2D5C840D701298D73@zcarhxm0.corp.nortel.com>
	<20040823190515.B1953@mit.edu> <002901c48967$640dcf80$3df4200a@amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <002901c48967$640dcf80$3df4200a@amer.cisco.com>;
	from bgiordan@cisco.com on Mon, Aug 23, 2004 at 04:17:41PM -0700
Spam-Alum-Prob: 0.000001
Spam-Alum-Prob: 0.010367
Spam-Alum-Time: 0.565379
Spam-Alum-Time: 0.603773
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 23 Aug 2004 23:31:12 -0000

On Mon, Aug 23, 2004 at 04:17:41PM -0700, Bart Giordano wrote:
> In this case, the agency conducting the surveillance would have to have
> physical access to your organizations internal network once a warrant is
> granted. You can use your imagination to figure how they might go about
> doing that (or just go rent Mission Impossible ;-)).

This is exactly my point. I suspect they want to send the warrant to
the SIP provider and expect them to figure out how to do the tap...

			-Jeff
From jwkckid1@ix.netcom.com Mon Aug 23 22:00:43 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7O20g3a008401;
	Mon, 23 Aug 2004 22:00:42 -0400 (EDT)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net
	[207.69.200.246])i7O20R8T003882;
	Mon, 23 Aug 2004 22:00:27 -0400 (EDT)
Received: from 1cust224.tnt59.dfw5.da.uu.net ([67.203.43.224]
	helo=ix.netcom.com)
	by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1)
	id 1BzQb1-00060N-00; Mon, 23 Aug 2004 21:59:36 -0400
Message-ID: <412ABC83.6BBB377F@ix.netcom.com>
Date: Mon, 23 Aug 2004 20:56:56 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: Bart Giordano <bgiordan@cisco.com>
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
References: <0CCD4D34B2952A48AB838DF2D5C840D701298D73@zcarhxm0.corp.nortel.com>
	<002901c48967$640dcf80$3df4200a@amer.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.630344
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 02:00:44 -0000

Bart, Jeff and all,

  Bart is essentially correct here to a point.  That being it is not necessary,

but easier to effect, a direct physical connection to your organizations
internal network to be able to effectively "Tap" your VOIP connection.
This can also be done effectively using a remote access method, which
I dare not mention for fear of loosing my security clearance.  However,
you can effectively negate such a wiretap via several locally loaded
encryption programs if your connection device has enough on board
memory and a means [pc or laptop] for loading your connection device.

Bart Giordano wrote:

> In this case, the agency conducting the surveillance would have to have
> physical access to your organizations internal network once a warrant is
> granted. You can use your imagination to figure how they might go about
> doing that (or just go rent Mission Impossible ;-)).
>
> In any event, the situation you present below really isn't specific to VoIP
> calls. The same problem of physical access to the network is relevant for
> traditional POTS phone systems too.
>
> -bg
>
> ----- Original Message -----
> From: "Jeffrey I. Schiller" <jis@mit.edu>
> To: "Dennis Beard" <beardd@nortelnetworks.com>
> Cc: "Bart Giordano" <bgiordan@cisco.com>; <saag@mit.edu>; "Russ Housley"
> <housley@vigilsec.com>
> Sent: Monday, August 23, 2004 4:05 PM
> Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
>
> > But if I make a VoIP call from my office to someone across campus,
> > via an outside SIP provider, the talking path should not leave my
> > campus. How can the outside SIP provider then get access to the
> > talking path (without my being able to figure out that I was being
> > tapped)?
> >
> > -Jeff
> >
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From jis@MIT.EDU Tue Aug 24 00:44:18 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7O4iH3a012737;
	Tue, 24 Aug 2004 00:44:17 -0400 (EDT)
Received: from jis.tzo.com (JISVPN.MIT.EDU [18.100.101.102])
	i7O4i0fr018601;	Tue, 24 Aug 2004 00:44:00 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.12.8p2/8.12.8) id i7O4hsqW003233;
	Tue, 24 Aug 2004 00:43:54 -0400
X-Authentication-Warning: jis.tzo.com: jis set sender to jis@mit.edu using -f
Date: Tue, 24 Aug 2004 00:43:54 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: Jeff Williams <jwkckid1@ix.netcom.com>
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
Message-ID: <20040824004354.A3221@mit.edu>
References:
	<0CCD4D34B2952A48AB838DF2D5C840D701298D73@zcarhxm0.corp.nortel.com>
	<002901c48967$640dcf80$3df4200a@amer.cisco.com>
	<412ABC83.6BBB377F@ix.netcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <412ABC83.6BBB377F@ix.netcom.com>;
	from jwkckid1@ix.netcom.com on Mon, Aug 23, 2004 at 08:56:56PM -0700
Spam-Alum-Prob: 0.039600
Spam-Alum-Prob: 0.466717
Spam-Alum-Time: 0.499443
Spam-Alum-Time: 0.482453
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 04:44:19 -0000

Would the FCC ruling prohibit the sale of VoIP equipment that does
end-to-end encryption?

			-Jeff
From mouse@Sparkle.Rodents.Montreal.QC.CA Tue Aug 24 00:53:38 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7O4rb3a012955
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 00:53:37 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i7O4raMu004887
	for <saag@mit.edu>; Tue, 24 Aug 2004 00:53:36 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA05762;
	Tue, 24 Aug 2004 00:53:33 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200408240453.AAA05762@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Tue, 24 Aug 2004 00:50:47 -0400 (EDT)
To: saag@mit.edu
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
In-Reply-To: <20040824004354.A3221@mit.edu>
References: 
	<0CCD4D34B2952A48AB838DF2D5C840D701298D73@zcarhxm0.corp.nortel.com>
	<002901c48967$640dcf80$3df4200a@amer.cisco.com>
	<412ABC83.6BBB377F@ix.netcom.com>
	<20040824004354.A3221@mit.edu>
Spam-Alum-Prob: 0.000125
Spam-Alum-Time: 0.512076
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 04:53:39 -0000

> Would the FCC ruling prohibit the sale of VoIP equipment that does
> end-to-end encryption?

Only in the US, if that.  (Which is to say, any such restriction is a
local ordinance, and arguably should not affect IETF decisions....)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From mouse@Sparkle.Rodents.Montreal.QC.CA Tue Aug 24 03:25:29 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7O7PS3a018464
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 03:25:28 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i7O7PRd8012413
	for <saag@mit.edu>; Tue, 24 Aug 2004 03:25:27 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA06313;
	Tue, 24 Aug 2004 03:25:26 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200408240725.DAA06313@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Tue, 24 Aug 2004 03:18:06 -0400 (EDT)
To: cfrg@ietf.org, saag@mit.edu
Subject: Re: [saag] Bad day at the hash function factory
In-Reply-To: <2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
References: <20040818191747.E2C147199@sierra.rtfm.com>
	<1B38BDAC-F1FC-11D8-B277-0003935495EC@cisco.com>
	<2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.542881
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 07:25:29 -0000

> I believe that the proof that HMAC is secure requires a collision
> resistant hash function.

Yes - but what type of collision?

As I understand it, it needs a second-preimage-resistant function,
which (as I understand it) MD5 still is.  (At least as far as the
public literature goes, but that caveat applies to practically all
public crypto discussion.)

The reason I think MD5 should not be used for new work, and should be
withdrawn from existing work to the extent feasible, is not that it's
broken, but that it's showing cracks: that these recent results
indicate that it's comparatively likely to be broken in other ways
(such as second-preimage) relatively soon, even if the current attacks
cannot be used for anything but chosen-preimage-pair collisions.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From lha@stacken.kth.se Tue Aug 24 07:08:13 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7OB883a024235;
	Tue, 24 Aug 2004 07:08:08 -0400 (EDT)
Received: from smtp1.su.se (smtp1.su.se [130.237.162.112])
	i7OB7nKc007580;	Tue, 24 Aug 2004 07:07:49 -0400 (EDT)
Received: from localhost (smtp1.su.se [127.0.0.1])
	by smtp1.su.se (Postfix) with ESMTP id 76122386FF;
	Tue, 24 Aug 2004 13:07:48 +0200 (CEST)
Received: from smtp1.su.se ([127.0.0.1])
 by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 19432-01-83; Tue, 24 Aug 2004 13:07:48 +0200 (CEST)
Received: from nutcracker.stacken.kth.se (nutcracker.it.su.se [130.237.95.69])
	by smtp1.su.se (Postfix) with ESMTP id 400953807A;
	Tue, 24 Aug 2004 13:07:48 +0200 (CEST)
Received: by nutcracker.stacken.kth.se (Postfix, from userid 913)
	id A4F21F3852; Tue, 24 Aug 2004 13:08:15 +0200 (CEST)
To: "Jeffrey I. Schiller" <jis@mit.edu>
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
References: <0CCD4D34B2952A48AB838DF2D5C840D701298D73@zcarhxm0.corp.nortel.com>
	<20040823190515.B1953@mit.edu>
	<002901c48967$640dcf80$3df4200a@amer.cisco.com>
	<20040823193021.A2547@mit.edu>
From:
	"From@nutcracker.stacken.kth.se":=?iso-8859-1?q?Love_H=F6rnquist_=C5strand?=
	<lha@it.su.se>
Date: Tue, 24 Aug 2004 13:08:08 +0200
In-Reply-To: <20040823193021.A2547@mit.edu> (Jeffrey I. Schiller's message
 of "Mon, 23 Aug 2004 19:30:21 -0400")
Message-ID: <amzn4k94kn.fsf@nutcracker.stacken.kth.se>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
X-Virus-Scanned: by amavisd-new at su.se
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.609858
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 11:08:15 -0000

--=-=-=


"Jeffrey I. Schiller" <jis@mit.edu> writes:

> On Mon, Aug 23, 2004 at 04:17:41PM -0700, Bart Giordano wrote:
>> In this case, the agency conducting the surveillance would have to have
>> physical access to your organizations internal network once a warrant is
>> granted. You can use your imagination to figure how they might go about
>> doing that (or just go rent Mission Impossible ;-)).
>
> This is exactly my point. I suspect they want to send the warrant to
> the SIP provider and expect them to figure out how to do the tap...

If you use the providers SIP proxy (the provider can hardly be responible
for traffic not going over their network/proxy), the provider can do the
tap if they can safely replace the SDP content in the INVITE and the OK
(using Record-Route make sure the proxy get the OK), now they can redirect
their own RTP forwarder and record all datagrams there.

Using TLS wont help you for being "wiretaped" since the TLS enpoints are
between you and your proxy, not you and the one you are calling.

This of course wastes width for the provider and wont work when the SDP
messages are signed (and encrypted) with PKCS7.

This idea also can be used by a proxy to filter RTP content, add PKCS7
signatures to the SDP/SIP message in INVITE/OK, support IPv6/IPv4
transparently, etc.

Love


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (NetBSD)

iQIVAwUAQSshnxZyDLTSep3UAQKQrA//fqS4U/AolpVsv2+tg4cfk503ddkUKv9D
PKw3BwQn8dIeOmizAv5mdYQTfJ/ts23OlwsEceLk+tIHJ6krcJiEnv7Tot4/c5D2
Ck+5y8f1OhWBaGiHkse95mODoIZscqk/zLF9fM/h/TpTqCqAa3Ou1zLx3nb0vMpO
gGDV1o86CHa1ot8X1G6gwQPY8Ux2Qf8GnPsQiGbIMTF/3pMBd0hSO4netCnk1DEE
GfPGVAN9GeIFYVFQfx3kbhBD+YEL2Y4lUxm6n5eRY640fPa87XZzj3IL6C84/gry
ZKZSW+83MU1W/LqBMsyTSI8s2gjfSINb0l+GqyahipnMnBRbbNAD9Jk6RDL13CTz
8qjJ4Rc1REiA6j+YMd58SnFZv2/X1jQY3tvx4Nv0uysoOjzPYTpPY3B44HCI8KQE
Br3K07ivfrrNSe38fHTwIAPd7m65btbVuh94f4vNB9ywyFUp2FxwRgp6cxZpkvE+
5iAroq39WP6jdAjgJZkVQIC70N4FAjUm6oRHP7z4+4h4/9wGJlE68fWxoJx7OUaN
+SzvEMSRRHGw3sJk9umoV7SLATlgN2FsgmtAUqjDt8WTDXLtpYtLFkeDF9Ax9i1p
HDxqnxo5BTFyDsbWAf+tjAq56h2VOl9Qz84GxVj9e4QjVY+/nVWmERC5cgQZLuF5
2wq9+vsnbuk=
=vB98
-----END PGP SIGNATURE-----
--=-=-=--
From jwkckid1@ix.netcom.com Tue Aug 24 08:11:23 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7OCBM3a026251;
	Tue, 24 Aug 2004 08:11:23 -0400 (EDT)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net
	[207.69.200.246])i7OC32aa016860;
	Tue, 24 Aug 2004 08:03:03 -0400 (EDT)
Received: from 1cust127.tnt36.dfw9.da.uu.net ([67.234.81.127]
	helo=ix.netcom.com)
	by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1)
	id 1Bza0z-00080K-00; Tue, 24 Aug 2004 08:03:01 -0400
Message-ID: <412B49F6.A368FB19@ix.netcom.com>
Date: Tue, 24 Aug 2004 07:00:23 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: "Jeffrey I. Schiller" <jis@MIT.EDU>
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
References:
	<0CCD4D34B2952A48AB838DF2D5C840D701298D73@zcarhxm0.corp.nortel.com>
	<002901c48967$640dcf80$3df4200a@amer.cisco.com>
	<412ABC83.6BBB377F@ix.netcom.com> <20040824004354.A3221@mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.623752
cc: saag@MIT.EDU
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 12:11:25 -0000

Jeff and all,

  I have read the ruling closely and checked with their legal folks
and the answer I got was nothing in the ruling specifically prohibits
software or firmware for such a use or purpose.

Jeffrey I. Schiller wrote:

> Would the FCC ruling prohibit the sale of VoIP equipment that does
> end-to-end encryption?
>
>                         -Jeff

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From smb@research.att.com Tue Aug 24 09:20:40 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7ODKd3a028327;
	Tue, 24 Aug 2004 09:20:39 -0400 (EDT)
Received: from machshav.com (machshav.com [147.28.0.16])
	i7ODKSkD021134;	Tue, 24 Aug 2004 09:20:28 -0400 (EDT)
Received: by machshav.com (Postfix, from userid 512)
	id A6CF4FB455; Tue, 24 Aug 2004 09:20:27 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP
	id E705EFB44C; Tue, 24 Aug 2004 09:20:26 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id AE3AA1AE71; Tue, 24 Aug 2004 09:20:25 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: "\"From@nutcracker.stacken.kth.se\"@research.att.com": ;
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra 
In-Reply-To: Your message of "Tue, 24 Aug 2004 13:08:08 +0200."
             <amzn4k94kn.fsf@nutcracker.stacken.kth.se> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 24 Aug 2004 09:20:25 -0400
Message-Id: <20040824132025.AE3AA1AE71@berkshire.research.att.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.594410
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 13:20:41 -0000

In message <amzn4k94kn.fsf@nutcracker.stacken.kth.se>, =?iso-8859-1?q?Love_H=F6
rnquist_=C5strand?= writes:

>
>"Jeffrey I. Schiller" <jis@mit.edu> writes:
>
>> On Mon, Aug 23, 2004 at 04:17:41PM -0700, Bart Giordano wrote:
>>> In this case, the agency conducting the surveillance would have to have
>>> physical access to your organizations internal network once a warrant is
>>> granted. You can use your imagination to figure how they might go about
>>> doing that (or just go rent Mission Impossible ;-)).
>>
>> This is exactly my point. I suspect they want to send the warrant to
>> the SIP provider and expect them to figure out how to do the tap...
>
>If you use the providers SIP proxy (the provider can hardly be responible
>for traffic not going over their network/proxy), the provider can do the
>tap if they can safely replace the SDP content in the INVITE and the OK
>(using Record-Route make sure the proxy get the OK), now they can redirect
>their own RTP forwarder and record all datagrams there.
>
>Using TLS wont help you for being "wiretaped" since the TLS enpoints are
>between you and your proxy, not you and the one you are calling.
>
>This of course wastes width for the provider and wont work when the SDP
>messages are signed (and encrypted) with PKCS7.
>
>This idea also can be used by a proxy to filter RTP content, add PKCS7
>signatures to the SDP/SIP message in INVITE/OK, support IPv6/IPv4
>transparently, etc.

But this is all detectable by the target of the wiretap.

Jeff is right.  The content tap has to be done by the physical source 
or destination ISP; the traffic analysis tap is probaly best done by 
the VoIP provider (if any).  And end-to-end encryption of content is
coming -- Skype already has it.

		--Steve Bellovin, http://www.research.att.com/~smb


From James_Hughes@StorageTek.com Tue Aug 24 09:31:23 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7ODVM3a028674
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 09:31:22 -0400 (EDT)
Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146])
	i7ODVLkD028402
	for <saag@mit.edu>; Tue, 24 Aug 2004 09:31:21 -0400 (EDT)
Received: from sherman.stortek.com (localhost [127.0.0.1])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id i7ODVJKR023993
	for <saag@mit.edu>; Tue, 24 Aug 2004 07:31:20 -0600 (MDT)
Received: from [129.191.63.222] (puck.network.com [129.191.63.222])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id i7ODVFCr023975;
	Tue, 24 Aug 2004 07:31:17 -0600 (MDT)
In-Reply-To: <p06110404bd503cb704ba@[10.84.131.39]>
References: <p06110404bd503cb704ba@[10.84.131.39]>
Mime-Version: 1.0 (Apple Message framework v667)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <DD8D8230-F5D1-11D8-B66B-000A95A27482@StorageTek.com>
From: James Hughes <James_Hughes@StorageTek.com>
Subject: Re: [saag] Bad day at the hash function factory
Date: Tue, 24 Aug 2004 09:31:12 -0400
To: Stephen Kent <kent@bbn.com>, saag@mit.edu
X-Mailer: Apple Mail (2.667)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.653764
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id
	i7ODVM3a028674
cc: cfrg@ietf.org
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 13:31:24 -0000

I am actually sorry to continue to beat this, but this is an important 
issue. Comments at the end please.

First, to clarify the discussion, I want to present some definitions. 
From
	http://www.wordiq.com/definition/Cryptographic_hash_function

1. Collision resistance is that it is to hard to find H(m1)=H(m2) for 
_any_ messages m1 and m2.

2. Second preimage resistance is that given h_1=H(m_1) it is hard to 
find m_2 such that h_1=H(m_2). This is for digital signatures.

3. Preimage resistance is that given h determine any message m_2, 
h=H(m_2). This is for password files.

If you have Collision resistance then you have 2nd preimage resistance. 
If you have 2nd preimage resistance preimage resistance.

The attack that Xiaoyun Wang, Xuejia Lai (& Dengguo Feng, Hongbo Yu) 
performed (portions of which were not presented) was that they spend 
about one and one half hours on a workstation to find an example of a 
class of messages (m_1) that are not 2nd pre-image resistant. Then once 
they have done that, then they can find multiple 2nd pre-image (m_2) 
from this message every 15 minutes.

So "MD5 is collision resistant" has fallen by existence proof and a 
demonstration that there are some messages that are not 2nd preimage 
resistant has also occurred (although this has not been analyzed to a 
great extent).

On Aug 23, 2004, at 8:32 PM, Stephen Kent wrote:
> At 8:59 PM -0400 8/19/04, james hughes wrote:
> >One comment and two discussion points.
> >
> >Can we withdraw the MD5 RFC as obsolete?
> >
> >On Aug 19, 2004, at 12:23 PM, David A. McGrew wrote:
> >>>WHAT'S SAFE?
> >>>First, anything that's already been signed is definitely safe.  If 
> you
> >>>stop using MD5 today, nothing you signed already puts you at risk.
> >
> >I sign a document (in the clear) which says "... pay me $100.00 ...
> >" and now I can create a document that to  "... pay me $10,000 ... "
> >with a collision. Just because the original is old, why are old
> >these documents safe?
>
> because you would have to generate a collision with a fixed value,
> the old has, and the techniques presented do not do that. They find a
> collision for MD5 based on the ability to create both messages from
> scratch. This is fundamentally different, in the same way that
> "birthday paradox" attacks have always been different from fixed
> message attacks.

Yes, but...

What you are saying is that even though MD5 is not collision resistant 
and it has been demonstrated that there is a class of messages that are 
not 2nd preimage resistant, that this class of messages is small small 
enough that _any_ message is not a member of this class even though the 
specific characteristics of this class has not been determined.

I could argue that saying that "nothing you signed already puts you at 
risk" is being hopeful. It really depends on the numbers of messages 
that have been signed and the percentage of this class. If billions of 
messages have been signed, are _all_ of them safe? Aren't we talking 
about probabilities? If we are talking about [unknown] probabilities, 
isn't this statement false in a rigorous logical [legal] sense (even 
though it may turn out to be true from a practical sense)? I am 
quibbling with your words "definitely" and "nothing" as being too 
absolute given the factual information that is out there.

I would suggest better wording of this statement would be
> [...] anything that's already been signed has a high probability of 
> being safe.  If you stop using MD5 today, there is a high probability 
> that nothing [previously] you signed already puts you at risk.

Even then, this begs the issue of trusting the timestamp.

Comments here...




Thanks!

jim
From pbaker@verisign.com Tue Aug 24 09:54:53 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7ODsq3a029468
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 09:54:52 -0400 (EDT)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	i7ODsoaa018110
	for <saag@mit.edu>; Tue, 24 Aug 2004 09:54:51 -0400 (EDT)
Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com
	[65.205.251.53])i7ODsiBP002090;	Tue, 24 Aug 2004 06:54:44 -0700 (PDT)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <RP4A4KPD>; Tue, 24 Aug 2004 06:54:44 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEAB7@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: cfrg@ietf.org, saag@mit.edu
Date: Tue, 24 Aug 2004 06:54:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.607343
Subject: [saag] Cryptography Algorithm Choice
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 13:54:53 -0000

I think that part of what the MD5/SHA1 situation throws up is the need for a
better means of tracking use of cryptography in standards. We have no
systematic method of indicating what algorithms are used and what properties
of those algorithms are relied upon.

There are two independent issues
	1) What should new protocols use?
	2) What changes need to be made by legacy protocols?

Answering (1) is easy, MD5 has been deprecated for years. SHA1 is not yet
compromised to the point it should be abandonded.

Answering (2) is hard for two reasons. First the decision comes down to
individual risk analysis, many people continue to use 56 bit DES encryption
on their VPN because it is more than sufficient for their needs. It is easy
to make the case for choice of strong algorithms when there is no cost,
legacy systems always involve cost.

The second problem is that we simply do not know what specifications are
using what crypto and in what context without spending a great deal of time
and effort on it. Part of the problem is that because of the process failure
that has led to most IETF standards in use having DRAFT or PROPOSED status
and many de facto standards merely INFORMATIONAL status these terms are
effectively meaningless and INTERCHANGEABLE. My management has no interest
in whether PKIX advances to DRAFT or STANDARD status, none. Nor does any
other PKI vendor apear to care much.

NEWTRACK are looking at some of these issues and it seems likely that DRAFT
status will be eliminated. But that will not address the crypto issue and it
will be as hard as ever to track the status, work out which documents are in
what category etc.

Try to work out what drafts use MD5, people will propose using GREP, which
would be fine if it really worked for this purpose, all you end up with is a
list of documents that mention MD5 which is not the same thing. Then each
one has to be analyzed and there are at least a hundred.

What we need is a machine readable set of information tags that can be put
in a security considerations that provide a formal statement of what
properties of what algorithms are depended on for security.
From paul.hoffman@vpnc.org Tue Aug 24 12:44:30 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7OGiT3a006078
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 12:44:30 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	i7OGiS6w006222
	for <saag@mit.edu>; Tue, 24 Aug 2004 12:44:28 -0400 (EDT)
Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net
	[66.125.125.65])	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGiLtD014862;
	Tue, 24 Aug 2004 09:44:22 -0700 (PDT)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p0611045bbd511da3455b@[10.20.30.249]>
In-Reply-To: 
 <C6DDA43B91BFDA49AA2F1E473732113E010BEAB7@mou1wnexm05.vcorp.ad.vrsn.com>
References: 
 <C6DDA43B91BFDA49AA2F1E473732113E010BEAB7@mou1wnexm05.vcorp.ad.vrsn.com>
Date: Tue, 24 Aug 2004 09:43:34 -0700
To: cfrg@ietf.org, saag@mit.edu
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: [saag] Cryptography Algorithm Choice
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.596707
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 16:44:31 -0000

At 6:54 AM -0700 8/24/04, Hallam-Baker, Phillip wrote:
>First the decision comes down to
>individual risk analysis, many people continue to use 56 bit DES encryption
>on their VPN because it is more than sufficient for their needs.

Is there any evidence for that statement? Almost no vendors currently 
ship VPNs with the default settings of DES. VPNC has never tested DES 
conformance or interoperability, and we have never had a single VPN 
user ask us to do so (or ask us why we didn't). No VPNC member has 
told me that they any customer demands for DES.

This ties closely to the request for tracking of the algorithms 
allowed, suggested, and mandated in IETF standards. Even today, DES 
is the MUST-level algorithm for IKEv1 (the IPsec WG never got around 
to changing it). IKEv1 is a great example of a protocol where you 
cannot determine what security algorithms are being used by looking 
at the RFC.

>What we need is a machine readable set of information tags that can be put
>in a security considerations that provide a formal statement of what
>properties of what algorithms are depended on for security.

That would only work if someone went back and re-wrote every RFC that 
uses security algorithms. A much better mechanism is a human-edited 
registry (hopefully a real database, not an Old Skool text file) that 
contains this information. Such a registry should be the job of the 
IETF Secretariat and/or IANA.

--Paul Hoffman, Director
--VPN Consortium
From pbaker@verisign.com Tue Aug 24 16:47:27 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7OKlQ3a016194
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 16:47:26 -0400 (EDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	i7OKlPTA001004
	for <saag@mit.edu>; Tue, 24 Aug 2004 16:47:25 -0400 (EDT)
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com
	[65.205.251.55])
	by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7OKlBx0003481;
	Tue, 24 Aug 2004 13:47:11 -0700 (PDT)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <Q66PGQ2M>; Tue, 24 Aug 2004 13:47:11 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEAC5@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Paul Hoffman / VPNC'" <paul.hoffman@vpnc.org>, cfrg@ietf.org,
   saag@mit.edu
Subject: RE: [saag] Cryptography Algorithm Choice
Date: Tue, 24 Aug 2004 13:47:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.643959
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 20:47:27 -0000


> Is there any evidence for that statement? Almost no vendors currently 
> ship VPNs with the default settings of DES. VPNC has never tested DES 
> conformance or interoperability, and we have never had a single VPN 
> user ask us to do so (or ask us why we didn't). No VPNC member has 
> told me that they any customer demands for DES.

Paul, there are many VPN vendors that do not use IPSEC or for that matter
SSL. DES VPNs really do exist, hopefully they are fading away but I
would not bet on it having been completed :-(

Put it this way there are plenty of 40 bit SSL browsers arround and I am
not aware of anyone ever having broken the crypto to actually do something
malicious. Although at this point it is clear that the phishing gangs will
be doing this at some point. 

At the moment ask the customer their credit card number works too well.


> This ties closely to the request for tracking of the algorithms 
> allowed, suggested, and mandated in IETF standards. Even today, DES 
> is the MUST-level algorithm for IKEv1 (the IPsec WG never got around 
> to changing it). IKEv1 is a great example of a protocol where you 
> cannot determine what security algorithms are being used by looking 
> at the RFC.

I agree, I think we need a process and a set of use levels for 
crypto algorithms. I think that this is an independent axis from
the standards level consideration. MD5 still makes a fine database
hash. 

In your example DES is still a MUST for conformance testing but it 
is a SHOULD NOT as far as security goes. 


> That would only work if someone went back and re-wrote every RFC that 
> uses security algorithms. A much better mechanism is a human-edited 
> registry (hopefully a real database, not an Old Skool text file) that 
> contains this information. Such a registry should be the job of the 
> IETF Secretariat and/or IANA.

We can hope, but I can't imagine that this is going to happen. The 
processes are just too sclerotic.

I suggest that we approach the subject a different way. We deal with 
the legacy base in a one off process, then get future specs to do 
something that is self maintaining.


Either way, machine or manual we have to get the statement down to
a checkbox level.

One of the ideas of CFRG was to be able to take these alg discussions
outside the WG process precisely so that we can avoid the issues you
raise.

I would like the NEWTRACK folk to give us a credible list of what
the real standards status of various RFCs are. Then for each of those
we should look to see whether there is a crypto algorithm involved
at any level and if so what the security considerations of the
algorithm selection are and what the constraints are for changing it.

Then we should write up a doc that sets out 1) the information above
and 2) what the recommended and acceptable algorithms are for each
protocol.

There should only be one place that people have to go to find out 
this info.


From paul.hoffman@vpnc.org Tue Aug 24 17:10:35 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7OLAY3a017209
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 17:10:34 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	i7OLAXTA021963
	for <saag@mit.edu>; Tue, 24 Aug 2004 17:10:33 -0400 (EDT)
Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net
	[66.125.125.65])	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OLAL6x057225;
	Tue, 24 Aug 2004 14:10:22 -0700 (PDT)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p0611046bbd515aec9f1c@[10.20.30.249]>
In-Reply-To: 
 <C6DDA43B91BFDA49AA2F1E473732113E010BEAC5@mou1wnexm05.vcorp.ad.vrsn.com>
References: 
 <C6DDA43B91BFDA49AA2F1E473732113E010BEAC5@mou1wnexm05.vcorp.ad.vrsn.com>
Date: Tue, 24 Aug 2004 14:10:23 -0700
To: cfrg@ietf.org, saag@mit.edu
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: RE: [saag] Cryptography Algorithm Choice
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.657675
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 21:10:36 -0000

At 1:47 PM -0700 8/24/04, Hallam-Baker, Phillip wrote:
>  > Is there any evidence for that statement? Almost no vendors currently
>>  ship VPNs with the default settings of DES. VPNC has never tested DES
>>  conformance or interoperability, and we have never had a single VPN
>>  user ask us to do so (or ask us why we didn't). No VPNC member has
>>  told me that they any customer demands for DES.
>
>Paul, there are many VPN vendors that do not use IPSEC or for that matter
>SSL.

Of course.

>DES VPNs really do exist, hopefully they are fading away but I
>would not bet on it having been completed :-(

Sorry, but it's hard to take that on faith without seeing any 
evidence of it. And, yes, this is relevant to the discussion at hand 
because this group might act differently if we believe that weak 
encryption is commonly used in IETF-created protocols.

And, although I have no hard facts, when I spoke to link-layer 
encryption vendors 18 months ago, they all said the same thing: there 
was essentially no current market for DES or anything with keys less 
than 112 bits of effective strength for anything called a VPN.

>Put it this way there are plenty of 40 bit SSL browsers arround and I am
>not aware of anyone ever having broken the crypto to actually do something
>malicious. Although at this point it is clear that the phishing gangs will
>be doing this at some point.

This has nothing to do with VPNs, only with SSL-enabled sites. None 
of the SSL VPN vendors that I know of allow DES as an acceptable 
connection algorithm by default. If you are saying that a significant 
number of users who have SSL VPN systems have turned this on this 
option, it would be good if you also supplied some evidence for this.

Of course, the algorithms being negotiated in the wild can actually 
be measured by ISPs who do a bit of port sniffing. If anyone has such 
numbers, it would greatly help to have them published!

>  > This ties closely to the request for tracking of the algorithms
>>  allowed, suggested, and mandated in IETF standards. Even today, DES
>>  is the MUST-level algorithm for IKEv1 (the IPsec WG never got around
>>  to changing it). IKEv1 is a great example of a protocol where you
>>  cannot determine what security algorithms are being used by looking
>>  at the RFC.
>
>I agree, I think we need a process and a set of use levels for
>crypto algorithms. I think that this is an independent axis from
>the standards level consideration. MD5 still makes a fine database
>hash.
>
>In your example DES is still a MUST for conformance testing but it
>is a SHOULD NOT as far as security goes.

Huh? Where in RFC 2407 do you see that? The RFC is completely clear: 
MUST support DES, "strongly encouraged" to support TripleDES. The 
waffly words in the IESG note do not say "SHOULD NOT", and the 
prediction that "it is very likely that the IETF will deprecate the 
use of ESP_DES as a mandatory cipher suite in the near future" never 
came to pass.

--Paul Hoffman, Director
--VPN Consortium
From smb@research.att.com Tue Aug 24 18:17:33 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7OMHW3a019043
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 18:17:32 -0400 (EDT)
Received: from machshav.com (machshav.com [147.28.0.16])
	i7OMHVTA019748
	for <saag@mit.edu>; Tue, 24 Aug 2004 18:17:31 -0400 (EDT)
Received: by machshav.com (Postfix, from userid 512)
	id CC8D9FB4E1; Tue, 24 Aug 2004 18:17:30 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP
	id 4FCDFFB455; Tue, 24 Aug 2004 18:17:30 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 508D41AE88; Tue, 24 Aug 2004 18:17:29 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: [saag] Cryptography Algorithm Choice 
In-Reply-To: Your message of "Tue, 24 Aug 2004 14:10:23 PDT."
             <p0611046bbd515aec9f1c@[10.20.30.249]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 24 Aug 2004 18:17:29 -0400
Message-Id: <20040824221729.508D41AE88@berkshire.research.att.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.532564
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 22:17:33 -0000

In message <p0611046bbd515aec9f1c@[10.20.30.249]>, Paul Hoffman / VPNC writes:
>The 
>waffly words in the IESG note do not say "SHOULD NOT", and the 
>prediction that "it is very likely that the IETF will deprecate the 
>use of ESP_DES as a mandatory cipher suite in the near future" never 
>came to pass.

Formally, no; in practice, IESG policy has been to require 3DES or AES
for quite some time.  SAAG had decided quite some time ago that it 
wanted to wait for AES before picking a new standard; that happend in 
October, 2000.  


		--Steve Bellovin, http://www.research.att.com/~smb


From jwkckid1@ix.netcom.com Tue Aug 24 19:30:32 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7ONUV3a021203
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 19:30:32 -0400 (EDT)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net
	[207.69.200.226])i7ONSFt6000531
	for <saag@mit.edu>; Tue, 24 Aug 2004 19:28:15 -0400 (EDT)
Received: from 1cust39.tnt36.dfw9.da.uu.net ([67.234.81.39]
	helo=ix.netcom.com)
	by blount.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1Bzki3-0004HW-00; Tue, 24 Aug 2004 19:28:11 -0400
Message-ID: <412BEA8B.914C0139@ix.netcom.com>
Date: Tue, 24 Aug 2004 18:25:32 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: "Steven M. Bellovin" <smb@research.att.com>
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
References: <20040824132025.AE3AA1AE71@berkshire.research.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.667451
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 24 Aug 2004 23:30:33 -0000

Steven and all,

  Skype is by no means the only one that has end-to-end encryption of
content, we do as well.  And again as far as I can currently determine
the FCC's ruling does not include banning this sort of wire tapping of
VOIP transmissions/content.  ISP's will only carry the signal or decide
later to block such end-to-end encryption of content.  Which I doubt
they will want to do unless a modified ruling from the FCC is forthcoming.
However legally speaking such a updated or modified ruling would
be bad for business and would garner serious opposition if ISP's and
content carriers of other sorts/types would consider such as a restraint
of trade that is both unnecessary and perhaps dangerous to their customers.

Steven M. Bellovin wrote:

> In message <amzn4k94kn.fsf@nutcracker.stacken.kth.se>, =?iso-8859-1?q?Love_H=F6
> rnquist_=C5strand?= writes:
>
> >
> >"Jeffrey I. Schiller" <jis@mit.edu> writes:
> >
> >> On Mon, Aug 23, 2004 at 04:17:41PM -0700, Bart Giordano wrote:
> >>> In this case, the agency conducting the surveillance would have to have
> >>> physical access to your organizations internal network once a warrant is
> >>> granted. You can use your imagination to figure how they might go about
> >>> doing that (or just go rent Mission Impossible ;-)).
> >>
> >> This is exactly my point. I suspect they want to send the warrant to
> >> the SIP provider and expect them to figure out how to do the tap...
> >
> >If you use the providers SIP proxy (the provider can hardly be responible
> >for traffic not going over their network/proxy), the provider can do the
> >tap if they can safely replace the SDP content in the INVITE and the OK
> >(using Record-Route make sure the proxy get the OK), now they can redirect
> >their own RTP forwarder and record all datagrams there.
> >
> >Using TLS wont help you for being "wiretaped" since the TLS enpoints are
> >between you and your proxy, not you and the one you are calling.
> >
> >This of course wastes width for the provider and wont work when the SDP
> >messages are signed (and encrypted) with PKCS7.
> >
> >This idea also can be used by a proxy to filter RTP content, add PKCS7
> >signatures to the SDP/SIP message in INVITE/OK, support IPv6/IPv4
> >transparently, etc.
>
> But this is all detectable by the target of the wiretap.
>
> Jeff is right.  The content tap has to be done by the physical source
> or destination ISP; the traffic analysis tap is probaly best done by
> the VoIP provider (if any).  And end-to-end encryption of content is
> coming -- Skype already has it.
>
>                 --Steve Bellovin, http://www.research.att.com/~smb
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From smb@research.att.com Tue Aug 24 22:17:55 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7P2Hs3a026382
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 22:17:55 -0400 (EDT)
Received: from machshav.com (machshav.com [147.28.0.16])
	i7P2Hq6F008313
	for <saag@mit.edu>; Tue, 24 Aug 2004 22:17:52 -0400 (EDT)
Received: by machshav.com (Postfix, from userid 512)
	id D5304FB4DA; Tue, 24 Aug 2004 22:17:51 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 72C21FB455
	for <saag@mit.edu>; Tue, 24 Aug 2004 22:17:51 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP id E4D7B1AE76
	for <saag@mit.edu>; Tue, 24 Aug 2004 22:17:49 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: saag@mit.edu
Subject: Re: [saag] Bad day at the hash function factory 
In-Reply-To: Your message of "Wed, 18 Aug 2004 12:09:09 PDT."
             <20040818191747.E2C147199@sierra.rtfm.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 24 Aug 2004 22:17:49 -0400
Message-Id: <20040825021750.E4D7B1AE76@berkshire.research.att.com>
Spam-Alum-Prob: 0.000151
Spam-Alum-Time: 0.512724
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 25 Aug 2004 02:17:56 -0000

<ad hat=on>
So -- is it the sense of SAAG that use of MD5 for IETF protocols should be
deprecated, except for HMAC-MD5?
</ad>


		--Steve Bellovin, http://www.research.att.com/~smb


From jmorris-lists@cdt.org Tue Aug 24 22:22:41 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7P2Me3a026573
	for <saag@jis.mit.edu>; Tue, 24 Aug 2004 22:22:40 -0400 (EDT)
Received: from mail.cdt.org (www.cdt.org [206.112.85.61])
	i7P2MdKk020531
	for <saag@mit.edu>; Tue, 24 Aug 2004 22:22:39 -0400 (EDT)
Received: from [65.235.137.208] (localhost.localdomain [127.0.0.1])
	by mail.cdt.org (Postfix) with ESMTP id 8A2F549011B
	for <saag@mit.edu>; Tue, 24 Aug 2004 22:09:50 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jmorris-lists@localhost
Message-Id: <a06020404bd51a79c6eec@[65.235.137.208]>
In-Reply-To: <412BEA8B.914C0139@ix.netcom.com>
References: <20040824132025.AE3AA1AE71@berkshire.research.att.com>
 <412BEA8B.914C0139@ix.netcom.com>
Date: Tue, 24 Aug 2004 22:22:21 -0400
To: saag@mit.edu
From: John Morris <jmorris-lists@cdt.org>
Subject: Re: [saag] The Call Is Cheap; The Wiretap Is Extra
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.709177
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 25 Aug 2004 02:22:42 -0000

Encryption is only implicated by CALEA if:

    (a) a provider provides the encryption capability, and
    (b) the provider has the key.

Thus, encryption on Skpye (which would not likely be covered by the 
current FCC Notice of Proposed Rulemaking in any event) would not be 
affected because Skype does not have the key.

John Morris

At 6:25 PM -0700 8/24/04, Jeff Williams wrote:
>Steven and all,
>
>   Skype is by no means the only one that has end-to-end encryption of
>content, we do as well.  And again as far as I can currently determine
>the FCC's ruling does not include banning this sort of wire tapping of
>VOIP transmissions/content.  ISP's will only carry the signal or decide
>later to block such end-to-end encryption of content.  Which I doubt
>they will want to do unless a modified ruling from the FCC is forthcoming.
>However legally speaking such a updated or modified ruling would
>be bad for business and would garner serious opposition if ISP's and
>content carriers of other sorts/types would consider such as a restraint
>of trade that is both unnecessary and perhaps dangerous to their customers.
>
>Steven M. Bellovin wrote:
>
>>  In message <amzn4k94kn.fsf@nutcracker.stacken.kth.se>, 
>>=?iso-8859-1?q?Love_H=F6
>>  rnquist_=C5strand?= writes:
>>
>>  >
>>  >"Jeffrey I. Schiller" <jis@mit.edu> writes:
>>  >
>>  >> On Mon, Aug 23, 2004 at 04:17:41PM -0700, Bart Giordano wrote:
>>  >>> In this case, the agency conducting the surveillance would have to have
>>  >>> physical access to your organizations internal network once a warrant is
>>  >>> granted. You can use your imagination to figure how they might go about
>>  >>> doing that (or just go rent Mission Impossible ;-)).
>>  >>
>>  >> This is exactly my point. I suspect they want to send the warrant to
>>  >> the SIP provider and expect them to figure out how to do the tap...
>>  >
>>  >If you use the providers SIP proxy (the provider can hardly be responible
>>  >for traffic not going over their network/proxy), the provider can do the
>>  >tap if they can safely replace the SDP content in the INVITE and the OK
>>  >(using Record-Route make sure the proxy get the OK), now they can redirect
>>  >their own RTP forwarder and record all datagrams there.
>>  >
>>  >Using TLS wont help you for being "wiretaped" since the TLS enpoints are
>>  >between you and your proxy, not you and the one you are calling.
>>  >
>>  >This of course wastes width for the provider and wont work when the SDP
>>  >messages are signed (and encrypted) with PKCS7.
>>  >
>>  >This idea also can be used by a proxy to filter RTP content, add PKCS7
>>  >signatures to the SDP/SIP message in INVITE/OK, support IPv6/IPv4
>>  >transparently, etc.
>>
>>  But this is all detectable by the target of the wiretap.
>>
>>  Jeff is right.  The content tap has to be done by the physical source
>>  or destination ISP; the traffic analysis tap is probaly best done by
>>  the VoIP provider (if any).  And end-to-end encryption of content is
>>  coming -- Skype already has it.
>>
>>                  --Steve Bellovin, http://www.research.att.com/~smb
>>
>>  _______________________________________________
>>  saag mailing list
>>  saag@mit.edu
>>  https://jis.mit.edu/mailman/listinfo/saag
>
>Regards,
>
>--
>Jeffrey A. Williams
>Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
>"Be precise in the use of words and expect precision from others" -
>     Pierre Abelard
>
>"If the probability be called P; the injury, L; and the burden, B;
>liability depends upon whether B is less than L multiplied by
>P: i.e., whether B is less than PL."
>United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
>===============================================================
>Updated 1/26/04
>CSO/DIR. Internet Network Eng. SR. Eng. Network data security
>IDNS. div. of Information Network Eng.  INEG. INC.
>E-Mail jwkckid1@ix.netcom.com
>  Registered Email addr with the USPS
>Contact Number: 214-244-4827
>
>
>_______________________________________________
>saag mailing list
>saag@mit.edu
>https://jis.mit.edu/mailman/listinfo/saag

From kent@bbn.com Wed Aug 25 09:23:01 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7PDN03a015346
	for <saag@jis.mit.edu>; Wed, 25 Aug 2004 09:23:00 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i7PDMxP9028610
	for <saag@mit.edu>; Wed, 25 Aug 2004 09:22:59 -0400 (EDT)
Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7PDMujh028920;
	Wed, 25 Aug 2004 09:22:58 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06110401bd5241e92b00@[128.89.89.75]>
In-Reply-To: <20040825021750.E4D7B1AE76@berkshire.research.att.com>
References: <20040825021750.E4D7B1AE76@berkshire.research.att.com>
Date: Wed, 25 Aug 2004 09:17:37 -0400
To: "Steven M. Bellovin" <smb@research.att.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] Bad day at the hash function factory
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000523
Spam-Alum-Time: 0.502824
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 25 Aug 2004 13:23:01 -0000

At 10:17 PM -0400 8/24/04, Steven M. Bellovin wrote:
><ad hat=on>
>So -- is it the sense of SAAG that use of MD5 for IETF protocols should be
>deprecated, except for HMAC-MD5?
></ad>
>

yes.

Steve
From rshirey@bbn.com Wed Aug 25 10:19:09 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7PEJ83a017025
	for <saag@jis.mit.edu>; Wed, 25 Aug 2004 10:19:08 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i7PEJ7P9020391
	for <saag@mit.edu>; Wed, 25 Aug 2004 10:19:07 -0400 (EDT)
Received: from po2.bbn.com (po2.bbn.com [128.33.0.56])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7PEJ6je002136
	for <saag@mit.edu>; Wed, 25 Aug 2004 10:19:06 -0400 (EDT)
Received: from [192.233.51.106] (ros-dhcp233-051-106.bbn.com [192.233.51.106])
	by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id i7PEJ6g07859
	for <saag@mit.edu>; Wed, 25 Aug 2004 10:19:06 -0400 (EDT)
Mime-Version: 1.0
X-Sender: rshirey@po2.bbn.com
Message-Id: <p05100303bd524fbde686@[192.233.51.106]>
Date: Wed, 25 Aug 2004 10:19:29 -0400
To: saag@mit.edu
From: "Robert W. Shirey" <rshirey@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.582542
Subject: [saag] Internet Security Glossary, Version 2
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 25 Aug 2004 14:19:10 -0000

Late Friday, I uploaded a finished draft of the Internet Security 
Glossary, Version 2 (draft-shirey-secgloss-v2-00.txt) to the IETF 
secretariat. I expect to update the  draft in a few weeks.

This version is intended to obsolete RFC 2828 (a.k.a. FYI 36); it 
contains about 500 more entries than 2828. Here is the abstract:

"This Glossary has 1,500 entries that give definitions, 
abbreviations, and explanations for terminology concerning 
information system security. It makes recommendations to improve the 
clarity of Internet Standards documents (ISDs) and the ease with 
which international readers can understand ISDs. It follows the 
principles that ISDs should (a) use the same term or definition 
whenever the same concept is mentioned; (b) use terms in their 
plainest, dictionary sense; (c) use terms that are already 
well-established in open publications; and (d) avoid terms that are 
proprietary, favor a particular vendor, or create a bias toward a 
particular technology or mechanism versus other, competing techniques 
that already exist or might be developed."

Regards, -Rob-

Robert W. Shirey, Decision and Security Tech. Dept., BBN Technologies
Suite 400, 1300 Seventeenth St. North,  Arlington, VA  22209-3801 USA
rshirey@bbn.com, Phone 703-284-1358, Reception 284-1200, Fax 284-1300

From pbaker@verisign.com Wed Aug 25 11:01:33 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7PF1W3a018205
	for <saag@jis.mit.edu>; Wed, 25 Aug 2004 11:01:33 -0400 (EDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	i7PF1VT4001345
	for <saag@mit.edu>; Wed, 25 Aug 2004 11:01:31 -0400 (EDT)
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com
	[65.205.251.55])
	by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7PF1SSA009131;
	Wed, 25 Aug 2004 08:01:29 -0700 (PDT)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <Q66P2F4Z>; Wed, 25 Aug 2004 08:01:28 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEACD@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Paul Hoffman / VPNC'" <paul.hoffman@vpnc.org>, cfrg@ietf.org,
   saag@mit.edu
Subject: RE: [Cfrg] RE: [saag] Cryptography Algorithm Choice
Date: Wed, 25 Aug 2004 08:01:26 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.541302
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 25 Aug 2004 15:01:34 -0000

> >In your example DES is still a MUST for conformance testing but it
> >is a SHOULD NOT as far as security goes.
> 
> Huh? Where in RFC 2407 do you see that? The RFC is completely clear: 
> MUST support DES, "strongly encouraged" to support TripleDES. The 
> waffly words in the IESG note do not say "SHOULD NOT", and the 
> prediction that "it is very likely that the IETF will deprecate the 
> use of ESP_DES as a mandatory cipher suite in the near future" never 
> came to pass.

Since when was RFC status a useful guide to security?

An RFC can recommend ROT13 as an encryption algorithm. Its still a
SHOULD NOT as far as security goes.

The point of my note is that I do NOT regard IETF requirements as
being authoratative on security matters.
From pbaker@verisign.com Wed Aug 25 11:11:51 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7PFBo3a018589;
	Wed, 25 Aug 2004 11:11:50 -0400 (EDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	i7PFBhT4011897;	Wed, 25 Aug 2004 11:11:44 -0400 (EDT)
Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com
	[65.205.251.33])
	by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7PFA0Bt009599;
	Wed, 25 Aug 2004 08:10:00 -0700 (PDT)
Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <RH7G5WHY>; Wed, 25 Aug 2004 08:10:00 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEACE@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Jeffrey I. Schiller'" <jis@mit.edu>,
   Bart Giordano
	 <bgiordan@cisco.com>
Subject: RE: [saag] The Call Is Cheap; The Wiretap Is Extra
Date: Wed, 25 Aug 2004 08:09:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.558811
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 25 Aug 2004 15:11:52 -0000

> On Mon, Aug 23, 2004 at 04:17:41PM -0700, Bart Giordano wrote:
> > In this case, the agency conducting the surveillance would 
> have to have
> > physical access to your organizations internal network once 
> a warrant is
> > granted. You can use your imagination to figure how they 
> might go about
> > doing that (or just go rent Mission Impossible ;-)).
> 
> This is exactly my point. I suspect they want to send the warrant to
> the SIP provider and expect them to figure out how to do the tap...

The SIP provider then hands the warrant over to their lawful intercept
service provider who tells the law enforcement what the effect of the
CALEA tap is. 

If they wanted to gain access to the network before the SIP provider box 
then they would have to serve process on the MIT network manager.

Since he appears to be the target of the investigation they would have
to do it the old way, break into his office and replace the phone or
bug it.
From pbaker@verisign.com Wed Aug 25 11:14:15 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7PFEE3a018669
	for <saag@jis.mit.edu>; Wed, 25 Aug 2004 11:14:14 -0400 (EDT)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	i7PFE6mY015154
	for <saag@mit.edu>; Wed, 25 Aug 2004 11:14:07 -0400 (EDT)
Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com
	[65.205.251.53])i7PFDxSe013658;	Wed, 25 Aug 2004 08:13:59 -0700 (PDT)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <RP4AXBH4>; Wed, 25 Aug 2004 08:13:59 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEACF@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Steven M. Bellovin'" <smb@research.att.com>, saag@mit.edu
Subject: RE: [saag] Bad day at the hash function factory 
Date: Wed, 25 Aug 2004 08:13:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.540871
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 25 Aug 2004 15:14:15 -0000

I think that HMAC-MD5 should be considered an entirely different function
in the same way that DES and 3DES are. The construction around HMAC 
effectively turns it into a different function.

Also I would limit the scope to IETF security protocols since there are
a couple of non security uses. I argued against Content-MD5 in HTTP 
at the time.

> -----Original Message-----
> From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu]On Behalf Of
> Steven M. Bellovin
> Sent: Tuesday, August 24, 2004 10:18 PM
> To: saag@mit.edu
> Subject: Re: [saag] Bad day at the hash function factory 
> 
> 
> <ad hat=on>
> So -- is it the sense of SAAG that use of MD5 for IETF 
> protocols should be
> deprecated, except for HMAC-MD5?
> </ad>
> 
> 
> 		--Steve Bellovin, http://www.research.att.com/~smb
> 
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 
From aramp@qualcomm.com Wed Aug 25 11:46:33 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7PFkW3a019729
	for <saag@jis.mit.edu>; Wed, 25 Aug 2004 11:46:32 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	i7PFkVT4015444
	for <saag@mit.edu>; Wed, 25 Aug 2004 11:46:31 -0400 (EDT)
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	i7PFkS57019315
	for <saag@mit.edu>; Wed, 25 Aug 2004 08:46:29 -0700 (PDT)
Received: from ARAMP.qualcomm.com (aramp.qualcomm.com [129.46.158.205])
	i7PFkRRE026149
	for <saag@mit.edu>; Wed, 25 Aug 2004 08:46:27 -0700 (PDT)
Message-Id: <6.0.0.22.2.20040825083942.01beecc8@qcmail1.qualcomm.com>
X-Sender: aramp@qcmail1.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Wed, 25 Aug 2004 08:46:26 -0700
To: saag@mit.edu
From: Aram Perez <aramp@qualcomm.com>
Subject: A request (was: Re: [saag] Bad day at the hash function
  factory)
In-Reply-To: <p06110401bd5241e92b00@[128.89.89.75]>
References: <20040825021750.E4D7B1AE76@berkshire.research.att.com>
 <p06110401bd5241e92b00@[128.89.89.75]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.560678
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 25 Aug 2004 15:46:33 -0000

Hi Folks,

Is it possible to get the IETF or some other well-known 
security/cryptography group to issue a press release to clearly state what 
hashes were "broken", what the break was, how it affects existing 
certs/signed docs, and what hashes should be used now that there are 
"broken" hashes?

Steve, I believe you're on the ABA ISC mailing list, I know Russ is. 
There's lots of confusion in the legal world about this "bad day at the 
hash function factory" and how it affects digital signatures.

Just a request,
Aram Perez

At 06:17 AM 8/25/2004, Stephen Kent wrote:
>At 10:17 PM -0400 8/24/04, Steven M. Bellovin wrote:
>><ad hat=on>
>>So -- is it the sense of SAAG that use of MD5 for IETF protocols should be
>>deprecated, except for HMAC-MD5?
>></ad>
>
>yes.
>
>Steve
>_______________________________________________
>saag mailing list
>saag@mit.edu
>https://jis.mit.edu/mailman/listinfo/saag

From kent@bbn.com Wed Aug 25 12:57:08 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7PGv73a022020
	for <saag@jis.mit.edu>; Wed, 25 Aug 2004 12:57:07 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i7PGv6T4018581
	for <saag@mit.edu>; Wed, 25 Aug 2004 12:57:06 -0400 (EDT)
Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7PGuXjf011720;
	Wed, 25 Aug 2004 12:56:33 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06110401bd52648787b2@[10.84.131.39]>
In-Reply-To: <DD8D8230-F5D1-11D8-B66B-000A95A27482@StorageTek.com>
References: <p06110404bd503cb704ba@[10.84.131.39]>
 <DD8D8230-F5D1-11D8-B66B-000A95A27482@StorageTek.com>
Date: Wed, 25 Aug 2004 12:56:09 -0400
To: James Hughes <James_Hughes@StorageTek.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] Bad day at the hash function factory
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.659628
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 25 Aug 2004 16:57:08 -0000

Jim,

>On Aug 23, 2004, at 8:32 PM, Stephen Kent wrote:
>>At 8:59 PM -0400 8/19/04, james hughes wrote:
>>>One comment and two discussion points.
>>>
>>>Can we withdraw the MD5 RFC as obsolete?
>>>
>>>On Aug 19, 2004, at 12:23 PM, David A. McGrew wrote:
>>>>>WHAT'S SAFE?
>>>>>First, anything that's already been signed is definitely safe.  If you
>>>>>stop using MD5 today, nothing you signed already puts you at risk.
>>>
>>>I sign a document (in the clear) which says "... pay me $100.00 ...
>>>" and now I can create a document that to  "... pay me $10,000 ... "
>>>with a collision. Just because the original is old, why are old
>>>these documents safe?
>>
>>because you would have to generate a collision with a fixed value,
>>the old has, and the techniques presented do not do that. They find a
>>collision for MD5 based on the ability to create both messages from
>>scratch. This is fundamentally different, in the same way that
>>"birthday paradox" attacks have always been different from fixed
>>message attacks.
>
>Yes, but...
>
>What you are saying is that even though MD5 is not collision 
>resistant and it has been demonstrated that there is a class of 
>messages that are not 2nd preimage resistant, that this class of 
>messages is small small enough that _any_ message is not a member of 
>this class even though the specific characteristics of this class 
>has not been determined.
>
>I could argue that saying that "nothing you signed already puts you 
>at risk" is being hopeful. It really depends on the numbers of 
>messages that have been signed and the percentage of this class. If 
>billions of messages have been signed, are _all_ of them safe? 
>Aren't we talking about probabilities? If we are talking about 
>[unknown] probabilities, isn't this statement false in a rigorous 
>logical [legal] sense (even though it may turn out to be true from a 
>practical sense)? I am quibbling with your words "definitely" and 
>"nothing" as being too absolute given the factual information that 
>is out there.

I'm looking at the text of my message that you copied  above and I 
don't see the words "definitely" or "nothing" in what I said, only in 
what David said :-)

But, I concede your point that IF the signed messages of interest 
have a prefix that falls into the class noted, then there could be a 
problem. I didn't attend Crypto, but the examples were shown for 
messages that were 1024 bits long, and the prefix was 512 bits. If 
the length is a critical feature of the attack capability, that would 
limit the set of vulnerable messages.

>
>I would suggest better wording of this statement would be
>>[...] anything that's already been signed has a high probability of 
>>being safe.  If you stop using MD5 today, there is a high 
>>probability that nothing [previously] you signed already puts you 
>>at risk.
>
>Even then, this begs the issue of trusting the timestamp.

Time stamp? The usual concern re time stamping is compromise of a 
private key and being able to distinguish what was signed before 
detection of the compromise, vs. afterwards. In this context, a 
secure time stamp would help IF it used a different hash algorithm. 
In the current Internet context, most of the persistent, signed 
objects are X.509 certificates, and the syntax of these certs does 
not accommodate time stamps from other parties.


Steve
From sommerfeld@east.sun.com Wed Aug 25 17:36:54 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7PLar3a001526
	for <saag@jis.mit.edu>; Wed, 25 Aug 2004 17:36:53 -0400 (EDT)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	i7PLapvC014755
	for <saag@mit.edu>; Wed, 25 Aug 2004 17:36:52 -0400 (EDT)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i7PLap35021559
	for <saag@mit.edu>; Wed, 25 Aug 2004 14:36:51 -0700 (PDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	ESMTP id i7PLaoQH001465
	for <saag@mit.edu>; Wed, 25 Aug 2004 17:36:50 -0400 (EDT)
Received: from thunk (localhost [127.0.0.1])
	by thunk.east.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7PLaoOY023143
	for <saag@mit.edu>; Wed, 25 Aug 2004 17:36:50 -0400 (EDT)
Message-Id: <200408252136.i7PLaoOY023143@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@sun.com>
To: saag@mit.edu
Date: Wed, 25 Aug 2004 17:36:50 -0400
Sender: sommerfeld@east.sun.com
Spam-Alum-Prob: 0.001274
Spam-Alum-Time: 0.520617
Subject: [saag] naming/use of rfc2412/rfc3526 groups by other protocols
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: sommerfeld@sun.com
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 25 Aug 2004 21:36:54 -0000

rfc2412 (oakley) defines several "MODP" diffie-hellman groups of
varying sizes in appendix E.  Several larger groups were defined in
RFC3526.

SSHv2 uses one of these groups, and also includes an extension to
allow the group to be dynamically negotiated.

Muddying the waters, SSHv2 defined its own group-numbering space;
diffie-hellman-group1-sha1 is the same as IKE's "group 2".

Do any protocols other than SSHv2 reuse IKE's MODP Diffie-Hellman
groups?  If so, what naming convention, if any, is used in that protocol?

						- Bill








From jwkckid1@ix.netcom.com Thu Aug 26 03:32:18 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7Q7WH3a017403
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 03:32:17 -0400 (EDT)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net
	[207.69.200.226])i7Q7WGRu026187
	for <saag@mit.edu>; Thu, 26 Aug 2004 03:32:16 -0400 (EDT)
Received: from 1cust100.tnt36.dfw9.da.uu.net ([67.234.81.100]
	helo=ix.netcom.com)
	by blount.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1C0Ehh-0000kh-00; Thu, 26 Aug 2004 03:29:49 -0400
Message-ID: <412DACEA.9DE5331@ix.netcom.com>
Date: Thu, 26 Aug 2004 02:27:06 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: Re: [Cfrg] RE: [saag] Cryptography Algorithm Choice
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEACD@mou1wnexm05.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.595943
cc: 'Paul Hoffman / VPNC' <paul.hoffman@vpnc.org>
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 07:32:18 -0000

Phillip and all,

  I agree the IETF as well as the IAB are fare behind the real world
curve in security matters.  Has been for some time...

Hallam-Baker, Phillip wrote:

> > >In your example DES is still a MUST for conformance testing but it
> > >is a SHOULD NOT as far as security goes.
> >
> > Huh? Where in RFC 2407 do you see that? The RFC is completely clear:
> > MUST support DES, "strongly encouraged" to support TripleDES. The
> > waffly words in the IESG note do not say "SHOULD NOT", and the
> > prediction that "it is very likely that the IETF will deprecate the
> > use of ESP_DES as a mandatory cipher suite in the near future" never
> > came to pass.
>
> Since when was RFC status a useful guide to security?
>
> An RFC can recommend ROT13 as an encryption algorithm. Its still a
> SHOULD NOT as far as security goes.
>
> The point of my note is that I do NOT regard IETF requirements as
> being authoratative on security matters.
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From Black_David@emc.com Thu Aug 26 11:01:07 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QF163a028536
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 11:01:06 -0400 (EDT)
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [168.159.2.31])
	i7QF13tZ019589
	for <saag@mit.edu>; Thu, 26 Aug 2004 11:01:04 -0400 (EDT)
Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9])
	i7QF0wp4015934;	Thu, 26 Aug 2004 11:01:00 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <PNM1Z563>; Thu, 26 Aug 2004 11:00:57 -0400
Message-ID: <B459CE1AFFC52D4688B2A5B842CA35EA07E5C7F0@corpmx14.corp.emc.com>
From: Black_David@emc.com
To: sommerfeld@sun.com, saag@mit.edu
Subject: RE: [saag] naming/use of rfc2412/rfc3526 groups by other protocol
	s
Date: Thu, 26 Aug 2004 11:00:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data:
	2004.8.25.111267
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.594536
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 15:01:08 -0000

Bill,

The 3072 bit and larger MODP groups have been reused and modified
for SRP in iSCSI by RFC 3723 Appendix A.  The modification is
that SRP needs different generators for these groups (can't use
the 2 that IKE/IKEv2 use) for reasons that I'll let real
cryptographers explain.  iSCSI uses text names, and these
groups have names of the form "MODP-nnnn" where "nnnn"
is the number of bits in the group.  SRP uses its own groups
(different from the IKE MODP groups) up to 2048 bits.

Fibre Channel (FC-SP) plans to reuse IKEv2 with modifications
necessary for Fibre Channel traffic; IKEv2's group numbers
will be reused.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On 
> Behalf Of Bill Sommerfeld
> Sent: Wednesday, August 25, 2004 5:37 PM
> To: saag@mit.edu
> Subject: [saag] naming/use of rfc2412/rfc3526 groups by other 
> protocols
> 
> 
> rfc2412 (oakley) defines several "MODP" diffie-hellman groups of
> varying sizes in appendix E.  Several larger groups were defined in
> RFC3526.
> 
> SSHv2 uses one of these groups, and also includes an extension to
> allow the group to be dynamically negotiated.
> 
> Muddying the waters, SSHv2 defined its own group-numbering space;
> diffie-hellman-group1-sha1 is the same as IKE's "group 2".
> 
> Do any protocols other than SSHv2 reuse IKE's MODP Diffie-Hellman
> groups?  If so, what naming convention, if any, is used in 
> that protocol?
> 
> 						- Bill
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 
From mcgrew@cisco.com Thu Aug 26 11:37:39 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QFbc3a029708
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 11:37:38 -0400 (EDT)
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71])
	i7QFbWtZ001440
	for <saag@mit.edu>; Thu, 26 Aug 2004 11:37:32 -0400 (EDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 26 Aug 2004 08:42:46 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
	[171.71.163.14])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7QFbSnV028139;
	Thu, 26 Aug 2004 08:37:29 -0700 (PDT)
Received: from [10.32.254.210] ([10.32.254.210])
	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with SMTP id AWO78081;
	Thu, 26 Aug 2004 08:36:16 -0700 (PDT)
In-Reply-To: <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
References: <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D428A482-F775-11D8-BEAF-0003935495EC@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
Date: Thu, 26 Aug 2004 08:37:25 -0700
To: "Hughes, James P" <HugheJP@LOUISVILLE.STORTEK.COM>
X-Mailer: Apple Mail (2.619)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.729088
cc: "'kent@bbn.com'" <kent@bbn.com>
cc: "'cfrg@ietf.org'" <cfrg@ietf.org>
cc: "'saag@mit.edu'" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 15:37:39 -0000

Jim,

On Aug 25, 2004, at 9:22 PM, Hughes, James P wrote:

> Thanks Steve [Kent] and sorry about confusing the quotes. As you 
> correctly
> noted, I was was trying to comment on the absolutes in David's 
> statement.

for the record, the brief quote was part of a nice early summary of the 
hash situation put together last week by Eric Rescorla, which I'd 
forwarded to CFRG.  This summary preceded the clarification of the 
results from Wang and Lai, and I'd expect Eric would agree that the 
absolutes ought to be qualified.

Thanks for providing the detailed summary of the results from the 
conference.

David

>
>
> Thanks Phillip [Hallam-Baker] about the fundamental differences in MD5 
> and
> HMAC algorithm and generally agree, but would add that MD5 and SHA are
> diffent "sized" algorithms and 128 vs 160 or 256 bits is not an
> inconsequential difference and should be considered when discussing 
> what
> kinds of HMAC is recommmended. (Similar to the TDES vs AES 
> discussions.)
>
> Thanks Steve [Bellovin] for the "ad on" statement. I would like to 
> agree and
> even suggest that it goes without saying that you may want future new
> applications of HMAC to pass over MD5 (for SHA-x where x>0) if they 
> have the
> option.
>
> Thanks! I thought this was a very civil conversation!
>
> Jim
>
>
>
>
> -----Original Message-----
> From: Stephen Kent <kent@bbn.com>
> To: Hughes, James P <HugheJP@LOUISVILLE.STORTEK.COM>
> CC: saag@mit.edu <saag@mit.edu>; cfrg@ietf.org <cfrg@ietf.org>
> Sent: Wed Aug 25 10:56:09 2004
> Subject: Re: [saag] Bad day at the hash function factory
>
> Jim,
>
>> On Aug 23, 2004, at 8:32 PM, Stephen Kent wrote:
>>> At 8:59 PM -0400 8/19/04, james hughes wrote:
>>>> One comment and two discussion points.
>>>>
>>>> Can we withdraw the MD5 RFC as obsolete?
>>>>
>>>> On Aug 19, 2004, at 12:23 PM, David A. McGrew wrote:
>>>>>> WHAT'S SAFE?
>>>>>> First, anything that's already been signed is definitely safe.  
>>>>>> If you
>>>>>> stop using MD5 today, nothing you signed already puts you at risk.
>>>>
>>>> I sign a document (in the clear) which says "... pay me $100.00 ...
>>>> " and now I can create a document that to  "... pay me $10,000 ... "
>>>> with a collision. Just because the original is old, why are old
>>>> these documents safe?
>>>
>>> because you would have to generate a collision with a fixed value,
>>> the old has, and the techniques presented do not do that. They find a
>>> collision for MD5 based on the ability to create both messages from
>>> scratch. This is fundamentally different, in the same way that
>>> "birthday paradox" attacks have always been different from fixed
>>> message attacks.
>>
>> Yes, but...
>>
>> What you are saying is that even though MD5 is not collision
>> resistant and it has been demonstrated that there is a class of
>> messages that are not 2nd preimage resistant, that this class of
>> messages is small small enough that _any_ message is not a member of
>> this class even though the specific characteristics of this class
>> has not been determined.
>>
>> I could argue that saying that "nothing you signed already puts you
>> at risk" is being hopeful. It really depends on the numbers of
>> messages that have been signed and the percentage of this class. If
>> billions of messages have been signed, are _all_ of them safe?
>> Aren't we talking about probabilities? If we are talking about
>> [unknown] probabilities, isn't this statement false in a rigorous
>> logical [legal] sense (even though it may turn out to be true from a
>> practical sense)? I am quibbling with your words "definitely" and
>> "nothing" as being too absolute given the factual information that
>> is out there.
>
> I'm looking at the text of my message that you copied  above and I
> don't see the words "definitely" or "nothing" in what I said, only in
> what David said :-)
>
> But, I concede your point that IF the signed messages of interest
> have a prefix that falls into the class noted, then there could be a
> problem. I didn't attend Crypto, but the examples were shown for
> messages that were 1024 bits long, and the prefix was 512 bits. If
> the length is a critical feature of the attack capability, that would
> limit the set of vulnerable messages.
>
>>
>> I would suggest better wording of this statement would be
>>> [...] anything that's already been signed has a high probability of
>>> being safe.  If you stop using MD5 today, there is a high
>>> probability that nothing [previously] you signed already puts you
>>> at risk.
>>
>> Even then, this begs the issue of trusting the timestamp.
>
> Time stamp? The usual concern re time stamping is compromise of a
> private key and being able to distinguish what was signed before
> detection of the compromise, vs. afterwards. In this context, a
> secure time stamp would help IF it used a different hash algorithm.
> In the current Internet context, most of the persistent, signed
> objects are X.509 certificates, and the syntax of these certs does
> not accommodate time stamps from other parties.
>
>
> Steve
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
>

From smb@research.att.com Thu Aug 26 11:46:31 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QFkU3a000084
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 11:46:30 -0400 (EDT)
Received: from machshav.com (machshav.com [147.28.0.16])
	i7QFkIT4000359
	for <saag@mit.edu>; Thu, 26 Aug 2004 11:46:19 -0400 (EDT)
Received: by machshav.com (Postfix, from userid 512)
	id DA6E6FB457; Thu, 26 Aug 2004 11:46:15 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP
	id 58267FB44F; Thu, 26 Aug 2004 11:46:15 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 3335B1AE76; Thu, 26 Aug 2004 11:46:14 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Hughes, James P" <HugheJP@LOUISVILLE.STORTEK.COM>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory 
In-Reply-To: Your message of "Wed, 25 Aug 2004 22:22:57 MDT."
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 26 Aug 2004 11:46:14 -0400
Message-Id: <20040826154614.3335B1AE76@berkshire.research.att.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.552952
cc: "'kent@bbn.com'" <kent@bbn.com>
cc: "'cfrg@ietf.org'" <cfrg@ietf.org>
cc: "'saag@mit.edu'" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 15:46:31 -0000

In message <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.c
om>, "Hughes, James P" writes:
>
>Thanks Steve [Bellovin] for the "ad on" statement. I would like to agree and
>even suggest that it goes without saying that you may want future new
>applications of HMAC to pass over MD5 (for SHA-x where x>0) if they have the
>option. 
>

I was asking a question, to see what the sense of the community is -- and
I've gotten very few responses.  Certainly, I have my own opinion -- I 
don't think we should have any new specs based on MD5 except for 
HMAC-MD5 -- but I don't think that that's completely up to me.  (I even 
saw one private response advocating retaining MD5.)

		--Steve Bellovin, http://www.research.att.com/~smb


From aramp@qualcomm.com Thu Aug 26 12:23:49 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QGNm3a001596
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 12:23:48 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	i7QGNjT4029768
	for <saag@mit.edu>; Thu, 26 Aug 2004 12:23:45 -0400 (EDT)
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	i7QGNg57012501
	for <saag@mit.edu>; Thu, 26 Aug 2004 09:23:42 -0700 (PDT)
Received: from ARAMP.qualcomm.com (aramp.qualcomm.com [129.46.158.205])
	i7QGNeWk020961
	for <saag@mit.edu>; Thu, 26 Aug 2004 09:23:41 -0700 (PDT)
Message-Id: <6.0.0.22.2.20040826085448.01bda3b0@qcmail1.qualcomm.com>
X-Sender: aramp@qcmail1.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Thu, 26 Aug 2004 09:15:50 -0700
To: "'saag@mit.edu'" <saag@mit.edu>
From: Aram Perez <aramp@qualcomm.com>
Subject: Re: A request (was: Re: [saag] Bad day at the hash function
  factory)
In-Reply-To: <151A63B4E33B4F49896AC6D1BA788A6E15C57E@EXCHVS2.louisville.
 stortek.com>
References: <151A63B4E33B4F49896AC6D1BA788A6E15C57E@EXCHVS2.louisville.stortek.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.601535
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 16:23:49 -0000

<html>
<body>
Hi Jim,<br><br>
What the lawyers do with the press release is what has legal
rammifications, not the actual press release (not unless the press
release states the it is safe to continue to use the broken hashes). I
believe the lawyers &quot;just want to <font face="Verdana" size=2>know
the facts</font><font face="Verdana">&quot;.<br><br>
</font>Respectfully,<br>
Aram Perez<br><br>
At 09:19 PM 8/25/2004, Hughes, James P wrote:<br>
<blockquote type=cite class=cite cite>This sounds like a good research
paper, not so much a &quot;press release&quot; since<br>
it has, as you suggest, legal rammifications. <br><br>
Thanks<br><br>
Jim<br><br>
<br><br>
-----Original Message-----<br>
From: saag-bounces@mit.edu &lt;saag-bounces@mit.edu&gt;<br>
To: saag@mit.edu &lt;saag@mit.edu&gt;<br>
Sent: Wed Aug 25 09:46:26 2004<br>
Subject: A request (was: Re: [saag] Bad day at the hash function
factory)<br><br>
Hi Folks,<br><br>
Is it possible to get the IETF or some other well-known <br>
security/cryptography group to issue a press release to clearly state
what <br>
hashes were &quot;broken&quot;, what the break was, how it affects
existing <br>
certs/signed docs, and what hashes should be used now that there are
<br>
&quot;broken&quot; hashes?<br><br>
Steve, I believe you're on the ABA ISC mailing list, I know Russ is.
<br>
There's lots of confusion in the legal world about this &quot;bad day at
the <br>
hash function factory&quot; and how it affects digital
signatures.<br><br>
Just a request,<br>
Aram Perez<br><br>
At 06:17 AM 8/25/2004, Stephen Kent wrote:<br>
&gt;At 10:17 PM -0400 8/24/04, Steven M. Bellovin wrote:<br>
&gt;&gt;&lt;ad hat=on&gt;<br>
&gt;&gt;So -- is it the sense of SAAG that use of MD5 for IETF protocols
should be<br>
&gt;&gt;deprecated, except for HMAC-MD5?<br>
&gt;&gt;&lt;/ad&gt;<br>
&gt;<br>
&gt;yes.<br>
&gt;<br>
&gt;Steve<br>
&gt;_______________________________________________<br>
&gt;saag mailing list<br>
&gt;saag@mit.edu<br>
&gt;<a href="https://jis.mit.edu/mailman/listinfo/saag" eudora="autourl">https://jis.mit.edu/mailman/listinfo/saag</a><br><br>
_______________________________________________<br>
saag mailing list<br>
saag@mit.edu<br>
<a href="https://jis.mit.edu/mailman/listinfo/saag" eudora="autourl">https://jis.mit.edu/mailman/listinfo/saag</a>
</blockquote></body>
</html>

From housley@vigilsec.com Thu Aug 26 12:33:36 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QGXZ3a001906
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 12:33:36 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i7QGXYtZ028876
	for <saag@mit.edu>; Thu, 26 Aug 2004 12:33:35 -0400 (EDT)
Received: (qmail 9674 invoked by uid 0); 26 Aug 2004 16:33:33 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.23)
  by woodstock.binhost.com with SMTP; 26 Aug 2004 16:33:33 -0000
Message-Id: <6.1.1.1.2.20040826123049.03b0be90@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Thu, 26 Aug 2004 12:34:01 -0400
To: saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] Bad day at the hash function factory 
In-Reply-To: <20040825021750.E4D7B1AE76@berkshire.research.att.com>
References: <Your message of "Wed, 18 Aug 2004 12:09:09 PDT."
	<20040818191747.E2C147199@sierra.rtfm.com>
	<20040825021750.E4D7B1AE76@berkshire.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.537842
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 16:33:37 -0000

I have not hear anyone speak against this action, but I do think that more 
than "Yes" or "No"  is needed to answer the question.  We deprecated DES 
many years ago, but we still have standards-track RFCs that include MUST 
statements that require DES.

So, if we are going to deprecate MD5, what actions are needed to accomplish 
the task, and who will perform the actions.

Just trying to help heard the cats ....

Russ

At 10:17 PM 8/24/2004, Steven M. Bellovin wrote:
><ad hat=on>
>So -- is it the sense of SAAG that use of MD5 for IETF protocols should be
>deprecated, except for HMAC-MD5?
></ad>

From mcgrew@cisco.com Thu Aug 26 12:54:18 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QGsH3a002625
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 12:54:17 -0400 (EDT)
Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70])
	i7QGsDT4024416
	for <saag@mit.edu>; Thu, 26 Aug 2004 12:54:15 -0400 (EDT)
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-1.cisco.com with ESMTP; 26 Aug 2004 09:59:45 -0700
X-BrightmailFiltered: true
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
	[171.71.163.14])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7QGs4CU005481;
	Thu, 26 Aug 2004 09:54:05 -0700 (PDT)
Received: from [10.32.254.210] ([10.32.254.210])
	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with SMTP id AWO85522;
	Thu, 26 Aug 2004 09:52:55 -0700 (PDT)
In-Reply-To: <20040825021750.E4D7B1AE76@berkshire.research.att.com>
References: <20040825021750.E4D7B1AE76@berkshire.research.att.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <89AC6462-F780-11D8-A97A-0003935495EC@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Bad day at the hash function factory 
Date: Thu, 26 Aug 2004 09:54:04 -0700
To: "Steven M. Bellovin" <smb@research.att.com>
X-Mailer: Apple Mail (2.619)
Spam-Alum-Prob: 0.000004
Spam-Alum-Time: 0.561248
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 16:54:18 -0000

Steve,

On Aug 24, 2004, at 7:17 PM, Steven M. Bellovin wrote:

> <ad hat=on>
> So -- is it the sense of SAAG that use of MD5 for IETF protocols 
> should be
> deprecated, except for HMAC-MD5?
> </ad>

I would agree, and the discussion on the CFRG list supports this 
position.  The current attacks on MD5 were summarized by Jim Hughes in

http://www1.ietf.org/mail-archive/web/cfrg/current/msg00539.html

and the strength of HMAC-MD5 despite these attacks was outlined by Hugo 
Krawczyk in

http://www1.ietf.org/mail-archive/web/cfrg/current/msg00527.html

David


>
>
> 		--Steve Bellovin, http://www.research.att.com/~smb
>
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>

From ekr@romeo.rtfm.com Thu Aug 26 13:27:05 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QHR33a003526
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 13:27:04 -0400 (EDT)
Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251])
	i7QHR1T4019403
	for <saag@mit.edu>; Thu, 26 Aug 2004 13:27:02 -0400 (EDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242])
	by sierra.rtfm.com (Postfix) with ESMTP
	id 62F83710E; Thu, 26 Aug 2004 10:35:49 -0700 (PDT)
Received: by romeo.rtfm.com (Postfix, from userid 556)
	id 51F4B44AB0; Thu, 26 Aug 2004 10:26:59 -0700 (PDT)
To: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
References: <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<D428A482-F775-11D8-BEAF-0003935495EC@cisco.com>
From: Eric Rescorla <ekr@romeo.rtfm.com>
Date: 26 Aug 2004 10:26:59 -0700
In-Reply-To: <D428A482-F775-11D8-BEAF-0003935495EC@cisco.com>
Message-ID: <kj4qmpn730.fsf@romeo.rtfm.com>
Lines: 24
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.578977
cc: "Hughes, James P" <HugheJP@LOUISVILLE.STORTEK.COM>
cc: "'kent@bbn.com'" <kent@bbn.com>
cc: "'cfrg@ietf.org'" <cfrg@ietf.org>
cc: "'saag@mit.edu'" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: EKR <ekr@rtfm.com>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 17:27:05 -0000

"David A. McGrew" <mcgrew@cisco.com> writes:

> Jim,
> 
> On Aug 25, 2004, at 9:22 PM, Hughes, James P wrote:
> 
> > Thanks Steve [Kent] and sorry about confusing the quotes. As you
> > correctly
> > noted, I was was trying to comment on the absolutes in David's
> > statement.
> 
> for the record, the brief quote was part of a nice early summary of
> the hash situation put together last week by Eric Rescorla, which I'd
> forwarded to CFRG.  This summary preceded the clarification of the
> results from Wang and Lai, and I'd expect Eric would agree that the
> absolutes ought to be qualified.

Yes, I agree. I'd still be surprised if there were a lot of
vulnerable signatures, but there could be some. I'd need
to examine Wang and Lai's results more carefully to get an
idea of what fraction of messages one could now generate
2nd preimages for.

-Ekr
From pbaker@verisign.com Thu Aug 26 13:32:28 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QHWR3a003706
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 13:32:27 -0400 (EDT)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	i7QHWOT4023855
	for <saag@mit.edu>; Thu, 26 Aug 2004 13:32:24 -0400 (EDT)
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com
	[65.205.251.54])i7QHW37a007591;	Thu, 26 Aug 2004 10:32:03 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <Q66RMZJR>; Thu, 26 Aug 2004 10:32:03 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEAE0@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Steven M. Bellovin'" <smb@research.att.com>,
   "Hughes, James P"
	 <HugheJP@LOUISVILLE.STORTEK.COM>
Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory 
Date: Thu, 26 Aug 2004 10:32:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.749118
cc: "'kent@bbn.com'" <kent@bbn.com>
cc: "'cfrg@ietf.org'" <cfrg@ietf.org>
cc: "'saag@mit.edu'" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 17:32:29 -0000

I think that we should track status of crypto algs independently of their
standards status. In particular I think that we should distinguish between
Recommended and Acceptable status.

New applications should specify algorithms with Recommended status
Continued use of algorithms with Acceptable status should not raise concern.


So I would classify as follows:

Proposed: SHA-2
Recommended: SHA-1, HMAC-SHA1, RSA-2048, RSA-4096, AES, DH-1024
Acceptable: HMAC-MD5, RSA-1024, 3DES, DSA, DH-512, RC4
Depricated: IDEA, RSA1024+MD5
Obsolete: MD4, MD5, RSA-512, DES

The reason that I distinguish between Depricated and obsolete is that there
are uses of RSA signatures with MD5 hash that are still acceptably secure
and the applications concerned do not support SHA1. The reason I put DSA as
acceptable rather than recommended is that it does need a good random seed,
the key size is small and it is unlikely at this point to see much use.

RC4 has been compromised by Shamir & co, but as a general rule I don't think
any stream cipher should ever get a higher status than acceptable. A stream
cipher always allows a person who has a plaintext and ciphertext
corresponding to a key to encode or decode all messages with that key that
are shorter or the same size. In effect all stream ciphers are vulnerable to
a trivial form of known plaintext attack, the attack does not reveal the key
but this is not necessary.

I do not feel confident in recommending moving to SHA2 at this point. Before
jumping I want to see that the place we are going to is better than where we
left. SHA2 is not currently widely used. If it turns out that the recent
cryptanalysis of SHA1 is also applicable to the structures used in SHA2 then
the rationale for a change is lost. I would feel happier moving to a hash
function based on AES encryption (which i had eroneously assumed had been
the point of the SHA2 work).

I think that after the Crypto 2004 results sink in it would make sense for
NIST to be asked to hold another contest for a hash function standard,
alternatively if NIST want to make SHA2 a contest entry then someone else
should organize.


I would prefer that any statements about certificates be carfeully thought
through since the criteria applicable to certs are very different to the
criteria applicable to applications.

In particular root certificates have to exist for a very long time and
premature expiry of certs is itself a huge problem that creates security
issues. Over the past few days I have been looking into the implications of
hash function use on root certs, I don't think that there are any. Once the
root is distributed the hash and signature have done their work.

If a hash function is vulnerable then there is a vulnerability due to the
fact that the algorithm is accepted at all. What this comes down to is that
we should not revoke root certs because the hash is bad, nor is this
actually possible since the attacker could manipulate the serial number.
What we should do instead is to revoke algorithms.

The concerns for end entity certs are much less of an issue since the expiry
interval is usually three years or less. There are SSL products in use that
only recognize MD5. RSA+MD5 is still secure for cert use under controlled
circumstances.


What this comes down to is that people should not look to the actions of CAs
for guidance as to what is good crypto practice. Good security practice
requires us to be conservative on both ends of the curve. When we distribute
new roots these should have a very long lifetime and use recommended
strength algorithms.

As far as process goes something seems to be broken. It should be very hard
to push algorithms up the hill but easy to roll them back down. The IETF
process is equally slow in both directions and all decisions are
concentrated in a body where only two members have positions that qualify
them to make an opinion.


> -----Original Message-----
> From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org]On Behalf Of
> Steven M. Bellovin
> Sent: Thursday, August 26, 2004 11:46 AM
> To: Hughes, James P
> Cc: 'saag@mit.edu'; 'cfrg@ietf.org'; 'kent@bbn.com'
> Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory 
> 
> 
> In message 
> <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.c
> om>, "Hughes, James P" writes:
> >
> >Thanks Steve [Bellovin] for the "ad on" statement. I would 
> like to agree and
> >even suggest that it goes without saying that you may want future new
> >applications of HMAC to pass over MD5 (for SHA-x where x>0) 
> if they have the
> >option. 
> >
> 
> I was asking a question, to see what the sense of the 
> community is -- and
> I've gotten very few responses.  Certainly, I have my own 
> opinion -- I 
> don't think we should have any new specs based on MD5 except for 
> HMAC-MD5 -- but I don't think that that's completely up to 
> me.  (I even 
> saw one private response advocating retaining MD5.)
> 
> 		--Steve Bellovin, http://www.research.att.com/~smb
> 
> 
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
> 
From pbaker@verisign.com Thu Aug 26 15:25:03 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QJP23a006956
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 15:25:02 -0400 (EDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	i7QJOxua021432
	for <saag@mit.edu>; Thu, 26 Aug 2004 15:25:00 -0400 (EDT)
Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com
	[65.205.251.33])
	by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7QJOw8O004403;
	Thu, 26 Aug 2004 12:24:58 -0700 (PDT)
Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <RH7G7RVC>; Thu, 26 Aug 2004 12:24:58 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEAE7@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Russ Housley'" <housley@vigilsec.com>, saag@mit.edu
Subject: RE: [saag] Bad day at the hash function factory 
Date: Thu, 26 Aug 2004 12:24:56 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000003
Spam-Alum-Time: 0.539435
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 19:25:03 -0000

> I have not hear anyone speak against this action, but I do 
> think that more 
> than "Yes" or "No"  is needed to answer the question.  We 
> deprecated DES 
> many years ago, but we still have standards-track RFCs that 
> include MUST 
> statements that require DES.

This is why i am arguing to separate the question of 'is it
standard compliant' from 'is it secure'.

It would be perfectly reasonable to require everyone to 
implement ROT13 in a system for the sole purpose of interop
testing. This would not be a reasonable choice of secure
cipher.


		Phill
From Matthew_Chalmers@bankone.com Thu Aug 26 15:27:44 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QJRh3a007070
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 15:27:43 -0400 (EDT)
Received: from smtpext43.bankone.com ([159.53.110.172])i7QJRcua023532
	for <saag@mit.edu>; Thu, 26 Aug 2004 15:27:38 -0400 (EDT)
Received: from smtpesf34.svr.bankone.net (smtpesf34.svr.bankone.net
	[155.180.133.40])i7QJRICm021525
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
	for <saag@mit.edu>; Thu, 26 Aug 2004 19:27:19 GMT
Received: from swilnts861.wil.fusa.com (swilnts861.wil.fusa.com
	[168.118.4.173])id i7QJRZGc000111
	for <saag@mit.edu>; Thu, 26 Aug 2004 19:27:35 GMT
Received: from swilnts807.wil.fusa.com (unverified) by 
    swilnts861.wil.fusa.com (Content Technologies SMTPRS 4.3.12) with ESMTP 
    id <T6ba81e7823a87604adc70@swilnts861.wil.fusa.com>; Thu, 26 Aug 2004 
    15:27:49 -0400
Received: from swilnts804.wil.fusa.com ([168.118.4.49]) by 
    swilnts807.wil.fusa.com with Microsoft SMTPSVC (5.0.2195.6713); Thu, 26 
    Aug 2004 15:27:49 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory
Date: Thu, 26 Aug 2004 15:27:49 -0400
Message-ID: <9BAB6CB128665C4F9CD6569BC42DAFA9056778ED@swilnts804.wil.fusa.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Cfrg] Re: [saag] Bad day at the hash function factory
Thread-Index: AcSLku2mJDi0M7WWTBe4SQyVSxW3EwACZbLw
From: <Matthew_Chalmers@bankone.com>
To: <pbaker@verisign.com>, <saag@mit.edu>
X-OriginalArrivalTime: 26 Aug 2004 19:27:49.0681 (UTC) 
    FILETIME=[C60B5210:01C48BA2]
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.880496
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id
	i7QJRh3a007070
cc: HugheJP@LOUISVILLE.STORTEK.COM
cc: kent@bbn.com
cc: cfrg@ietf.org
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 19:27:45 -0000

I for one think your classification idea is good. You also bring up good points about certificate replacement; there is much to consider before outright abandoning such a pervasive algorithm.

Regarding "good crypto practice," I once heard someone say it is "hard." On the one hand, we can say MD5 should/must not be used, period. But what if the (only) alternative turned out just as broken tomorrow? Obsolete it too? What do we have then? On the other hand, we could acknowledge MD5 as still suitable for certain applications, e.g. HMAC-MD5, digesting human-processed messages (e.g. text email, since the liklihood of an attacker finding any reasonable message with the same digest is low, i.e. the literal attack of "Alice pay Bob $10" replaced by "Alice pay Bob $100" is unlikely), or any low-value applications where speed and/or size matter; but seems clear we don't want to use plain MD5 for digesting computer-processed messages (e.g. integrity-checked device commands, or perhaps passwords) or any highly-entropic source such as key (even if human-processed, it could be difficult or impossible to tell whether "039AB03CF8DD32AC" or "FF03ABC3228CAF31" is the real key if they hash the same). The former is easy, and perhaps dangerous if we "run out" of good algorithms; the latter is hard, and perhaps dangerous if further weaknesses are found or if programmers simply implement inappropriately.

Cryptologists will do what they feel is right based on their understanding of the issues but they sometimes only understand the cryptologic ones; laypersons will do what they're told (by IETF, NIST, etc.) unless they misunderstand the guidance due to complexity or gray areas, but they sometimes use what's readily available even if it's only the bare minimum. So we can either tell them "don't use MD5 at all" or "only use MD5 for this, that, and another thing."

We don't have a perfect algorithm ideally suited to all needs--cryptologists', implementers', users'--so we have complexity, gray area, and degrees of risk. We need a balance between them. Perhaps the classifications below will do, or perhaps we need to define appropriate applications for each algorithm--not simply that encrypting is for confidentiality, hashing is for integrity, etc. but as I said above, MD5 is for integrity of human-processed (or processable) messages such as text email but not highly-entropic, computer-processed messages such as key.

P.S. Thanks to James H. and Hugo K. for their clarifications, and to David M. for pointing us to links to both their messages.

-----Original Message-----
From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu]On Behalf Of
Hallam-Baker, Phillip
Sent: Thursday, August 26, 2004 1:32 PM
To: 'Steven M. Bellovin'; Hughes, James P
Cc: 'kent@bbn.com'; 'cfrg@ietf.org'; 'saag@mit.edu'
Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory 


I think that we should track status of crypto algs independently of their
standards status. In particular I think that we should distinguish between
Recommended and Acceptable status.

New applications should specify algorithms with Recommended status
Continued use of algorithms with Acceptable status should not raise concern.


So I would classify as follows:

Proposed: SHA-2
Recommended: SHA-1, HMAC-SHA1, RSA-2048, RSA-4096, AES, DH-1024
Acceptable: HMAC-MD5, RSA-1024, 3DES, DSA, DH-512, RC4
Depricated: IDEA, RSA1024+MD5
Obsolete: MD4, MD5, RSA-512, DES

The reason that I distinguish between Depricated and obsolete is that there
are uses of RSA signatures with MD5 hash that are still acceptably secure
and the applications concerned do not support SHA1. The reason I put DSA as
acceptable rather than recommended is that it does need a good random seed,
the key size is small and it is unlikely at this point to see much use.

RC4 has been compromised by Shamir & co, but as a general rule I don't think
any stream cipher should ever get a higher status than acceptable. A stream
cipher always allows a person who has a plaintext and ciphertext
corresponding to a key to encode or decode all messages with that key that
are shorter or the same size. In effect all stream ciphers are vulnerable to
a trivial form of known plaintext attack, the attack does not reveal the key
but this is not necessary.

I do not feel confident in recommending moving to SHA2 at this point. Before
jumping I want to see that the place we are going to is better than where we
left. SHA2 is not currently widely used. If it turns out that the recent
cryptanalysis of SHA1 is also applicable to the structures used in SHA2 then
the rationale for a change is lost. I would feel happier moving to a hash
function based on AES encryption (which i had eroneously assumed had been
the point of the SHA2 work).

I think that after the Crypto 2004 results sink in it would make sense for
NIST to be asked to hold another contest for a hash function standard,
alternatively if NIST want to make SHA2 a contest entry then someone else
should organize.


I would prefer that any statements about certificates be carfeully thought
through since the criteria applicable to certs are very different to the
criteria applicable to applications.

In particular root certificates have to exist for a very long time and
premature expiry of certs is itself a huge problem that creates security
issues. Over the past few days I have been looking into the implications of
hash function use on root certs, I don't think that there are any. Once the
root is distributed the hash and signature have done their work.

If a hash function is vulnerable then there is a vulnerability due to the
fact that the algorithm is accepted at all. What this comes down to is that
we should not revoke root certs because the hash is bad, nor is this
actually possible since the attacker could manipulate the serial number.
What we should do instead is to revoke algorithms.

The concerns for end entity certs are much less of an issue since the expiry
interval is usually three years or less. There are SSL products in use that
only recognize MD5. RSA+MD5 is still secure for cert use under controlled
circumstances.


What this comes down to is that people should not look to the actions of CAs
for guidance as to what is good crypto practice. Good security practice
requires us to be conservative on both ends of the curve. When we distribute
new roots these should have a very long lifetime and use recommended
strength algorithms.

As far as process goes something seems to be broken. It should be very hard
to push algorithms up the hill but easy to roll them back down. The IETF
process is equally slow in both directions and all decisions are
concentrated in a body where only two members have positions that qualify
them to make an opinion.


> -----Original Message-----
> From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org]On Behalf Of
> Steven M. Bellovin
> Sent: Thursday, August 26, 2004 11:46 AM
> To: Hughes, James P
> Cc: 'saag@mit.edu'; 'cfrg@ietf.org'; 'kent@bbn.com'
> Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory 
> 
> 
> In message 
> <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.c
> om>, "Hughes, James P" writes:
> >
> >Thanks Steve [Bellovin] for the "ad on" statement. I would 
> like to agree and
> >even suggest that it goes without saying that you may want future new
> >applications of HMAC to pass over MD5 (for SHA-x where x>0) 
> if they have the
> >option. 
> >
> 
> I was asking a question, to see what the sense of the 
> community is -- and
> I've gotten very few responses.  Certainly, I have my own 
> opinion -- I 
> don't think we should have any new specs based on MD5 except for 
> HMAC-MD5 -- but I don't think that that's completely up to 
> me.  (I even 
> saw one private response advocating retaining MD5.)
> 
> 		--Steve Bellovin, http://www.research.att.com/~smb
> 
> 
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
> 
_______________________________________________
saag mailing list
saag@mit.edu
https://jis.mit.edu/mailman/listinfo/saag


**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************


From housley@vigilsec.com Thu Aug 26 18:03:37 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QM3a3a011641
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 18:03:36 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i7QM3ZhX027454
	for <saag@mit.edu>; Thu, 26 Aug 2004 18:03:35 -0400 (EDT)
Received: (qmail 19684 invoked by uid 0); 26 Aug 2004 22:03:34 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.131.45)
  by woodstock.binhost.com with SMTP; 26 Aug 2004 22:03:34 -0000
Message-Id: <6.1.1.1.2.20040826180006.08c7e3a0@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Thu, 26 Aug 2004 18:04:20 -0400
To: saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] Bad day at the hash function factory
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.862883
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 26 Aug 2004 22:03:38 -0000


NIST's Brief Comments on the issue are attached.

Russ

= = = = = = = = = =

    NIST Brief Comments
    on
    Recent Cryptanalytic Attacks on Secure Hashing Functions
    and
    the Continued Security Provided by SHA-1


Cryptographic hash functions that compute a fixed size message digest
from arbitrary size messages are widely used for many purposes in
cryptography, including digital signatures.  At the recent Crypto2004
conference, researchers announced that they had discovered a way to
"break" a number of hash algorithms, including MD4, MD5, HAVAL-128,
RIPEMD and the long superseded Federal Standard SHA-0 algorithm.  The
current Federal Information Processing Standard SHA-1 algorithm,
which has been in effect since it replaced SHA-0 in 1994, was also
analyzed, and a weakened variant was broken, but the full SHA-1
function was not broken and no collisions were found in SHA-1.  The
results presented so far on SHA-1 do not call its security into
question.   However, due to advances in technology, NIST plans to
phase out of SHA-1 in favor of the larger and stronger hash functions
(SHA-224, SHA-256, SHA-384 and SHA-512) by 2010. SHA-1 and the larger
hash functions are specified in FIPS 180-2.  For planning purposes by
Federal agencies and others, note also that the use of other
cryptographic algorithms of similar strength to SHA-1 will also be
phased out in 2010.

SHA-1 and the stronger hash functions in FIPS 180-2 are all NIST
approved.  NIST encourages the implementers of the FIPS 180-2 hash
algorithms to have the correctness of their implementations validated
though the Cryptographic Module Validation Program; such validation
is required for Federal use.

NIST applauds the recent analysis and encourages more published
research into hash functions and their resistance to attack,
particularly for newer algorithms such as SHA-256 and SHA-512. Such
analysis helps us continue to gain assurance in the security of the
algorithms we use.

8-25-2004

From pbaker@verisign.com Thu Aug 26 22:54:26 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7R2sQ3a018411
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 22:54:26 -0400 (EDT)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	i7R2sONr011614
	for <saag@mit.edu>; Thu, 26 Aug 2004 22:54:25 -0400 (EDT)
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com
	[65.205.251.54])i7R2sOcL027887
	for <saag@mit.edu>; Thu, 26 Aug 2004 19:54:24 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <Q66RNWB7>; Thu, 26 Aug 2004 19:54:24 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEAF0@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: saag@mit.edu
Subject: RE: [saag] Bad day at the hash function factory
Date: Thu, 26 Aug 2004 19:54:23 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.013994
Spam-Alum-Time: 0.530961
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 27 Aug 2004 02:54:27 -0000


> For planning purposes by
> Federal agencies and others, note also that the use of other
> cryptographic algorithms of similar strength to SHA-1 will also be
> phased out in 2010.

Anyone got an idea what this might refer to? DSA? 3DES?
From mcgrew@cisco.com Fri Aug 27 07:53:08 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7RBr73a001752
	for <saag@jis.mit.edu>; Fri, 27 Aug 2004 07:53:07 -0400 (EDT)
Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70])
	i7RBr6qd000624
	for <saag@mit.edu>; Fri, 27 Aug 2004 07:53:06 -0400 (EDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-1.cisco.com with ESMTP; 27 Aug 2004 04:58:50 -0700
X-BrightmailFiltered: true
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
	[171.71.163.14])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7RBr3nV017182;
	Fri, 27 Aug 2004 04:53:04 -0700 (PDT)
Received: from [10.32.254.210] ([10.32.254.210])
	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with SMTP id AWP54521;
	Fri, 27 Aug 2004 04:51:51 -0700 (PDT)
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEAF0@mou1wnexm05.vcorp.ad.vrsn.com>
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEAF0@mou1wnexm05.vcorp.ad.vrsn.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <A54B26DC-F81F-11D8-A97A-0003935495EC@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Bad day at the hash function factory
Date: Fri, 27 Aug 2004 04:53:00 -0700
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
X-Mailer: Apple Mail (2.619)
Spam-Alum-Prob: 0.000004
Spam-Alum-Time: 0.551978
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 27 Aug 2004 11:53:08 -0000

Phill,

On Aug 26, 2004, at 7:54 PM, Hallam-Baker, Phillip wrote:

>
>> For planning purposes by
>> Federal agencies and others, note also that the use of other
>> cryptographic algorithms of similar strength to SHA-1 will also be
>> phased out in 2010.
>
> Anyone got an idea what this might refer to? DSA? 3DES?

probably SKIPJACK, which is a block cipher with an 80-bit key, which 
roughly corresponds to the collision-resistance level of SHA-1.

NIST has a schedule for phasing out weaker cryptoalgorithms in favor of 
stronger ones, and it goes out a couple of decades, IIRC.  I can't find 
it on their website at present, though.

David

> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>

From pbaker@verisign.com Fri Aug 27 09:14:12 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7RDEC3a004032
	for <saag@jis.mit.edu>; Fri, 27 Aug 2004 09:14:12 -0400 (EDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	i7RDE9t4011046
	for <saag@mit.edu>; Fri, 27 Aug 2004 09:14:09 -0400 (EDT)
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com
	[65.205.251.55])
	by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7RDDFfH006630;
	Fri, 27 Aug 2004 06:13:15 -0700 (PDT)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <Q66PM4A0>; Fri, 27 Aug 2004 06:13:15 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEAF1@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'David A. McGrew'" <mcgrew@cisco.com>,
   "Hallam-Baker, Phillip"
	 <pbaker@verisign.com>
Subject: RE: [saag] Bad day at the hash function factory
Date: Fri, 27 Aug 2004 06:13:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.036935
Spam-Alum-Time: 0.514410
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 27 Aug 2004 13:14:13 -0000

> probably SKIPJACK, which is a block cipher with an 80-bit key, which 
> roughly corresponds to the collision-resistance level of SHA-1.

Yep, that must be it, Skipjack and DSA 

From dee3@pothole.com Sun Aug 29 22:50:17 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7U2oH3a011744
	for <saag@jis.mit.edu>; Sun, 29 Aug 2004 22:50:17 -0400 (EDT)
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35])
	i7U2oFo1023846
	for <saag@mit.edu>; Sun, 29 Aug 2004 22:50:15 -0400 (EDT)
Received: from localhost.localdomain
	(h00095bc05ec9.ne.client2.attbi.com[24.62.71.160])
	by comcast.net (rwcrmhc11) with ESMTP
	id <2004083002501401300hmcvfe>; Mon, 30 Aug 2004 02:50:15 +0000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	i7U2lfiL026167;	Sun, 29 Aug 2004 22:47:41 -0400
Received: from localhost (dee3@localhost)i7U2lfha026164;
	Sun, 29 Aug 2004 22:47:41 -0400
Date: Sun, 29 Aug 2004 22:47:41 -0400 (EDT)
From: dee3@pothole.com
X-X-Sender: dee3@localhost.localdomain
To: Bill Sommerfeld <sommerfeld@sun.com>
Subject: Re: [saag] naming/use of rfc2412/rfc3526 groups by other protocols
In-Reply-To: <200408252136.i7PLaoOY023143@thunk.east.sun.com>
Message-ID: <Pine.LNX.4.60.0408292246100.26101@localhost.localdomain>
References: <200408252136.i7PLaoOY023143@thunk.east.sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Spam-Alum-Prob: 0.000001
Spam-Alum-Time: 0.566178
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 30 Aug 2004 02:50:18 -0000

I believe the groups in draft-ietf-dnsext-rfc2539bis-dhk-04.txt may be 
from IKE.

Thanks,
Donald
======================================================================
  Donald E. Eastlake 3rd                       dee3@torque.pothole.com
  155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
  Milford, MA 01757 USA                   Donald.Eastlake@motorola.com

On Wed, 25 Aug 2004, Bill Sommerfeld wrote:

> Date: Wed, 25 Aug 2004 17:36:50 -0400
> From: Bill Sommerfeld <sommerfeld@sun.com>
> To: saag@mit.edu
> Subject: [saag] naming/use of rfc2412/rfc3526 groups by other protocols
> 
> rfc2412 (oakley) defines several "MODP" diffie-hellman groups of
> varying sizes in appendix E.  Several larger groups were defined in
> RFC3526.
>
> SSHv2 uses one of these groups, and also includes an extension to
> allow the group to be dynamically negotiated.
>
> Muddying the waters, SSHv2 defined its own group-numbering space;
> diffie-hellman-group1-sha1 is the same as IKE's "group 2".
>
> Do any protocols other than SSHv2 reuse IKE's MODP Diffie-Hellman
> groups?  If so, what naming convention, if any, is used in that protocol?
>
> 						- Bill
>
>
>
>
>
>
>
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>
From housley@vigilsec.com Mon Aug 30 17:06:05 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7UL643a013625
	for <saag@jis.mit.edu>; Mon, 30 Aug 2004 17:06:04 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i7UL5xjC021698
	for <saag@mit.edu>; Mon, 30 Aug 2004 17:05:59 -0400 (EDT)
Received: (qmail 14690 invoked by uid 0); 30 Aug 2004 21:05:58 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.169.160)
  by woodstock.binhost.com with SMTP; 30 Aug 2004 21:05:58 -0000
Message-Id: <6.1.1.1.2.20040830103630.037242e8@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Mon, 30 Aug 2004 10:37:58 -0400
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>,
   "'David A. McGrew'" <mcgrew@cisco.com>
From: Russ Housley <housley@vigilsec.com>
Subject: RE: [saag] Bad day at the hash function factory
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEAF1@mou1wnexm05.vcorp
 .ad.vrsn.com>
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEAF1@mou1wnexm05.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000006
Spam-Alum-Time: 0.523134
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 30 Aug 2004 21:06:06 -0000

Phill:

The DSA standard is being changed to accept larger key sizes.  Once this is 
done, it will no longer be limited to 1024-bit keys.  With the bigger key 
sizes, there is not need to phase them out in 2010.

Russ

At 09:13 AM 8/27/2004, Hallam-Baker, Phillip wrote:
> > probably SKIPJACK, which is a block cipher with an 80-bit key, which
> > roughly corresponds to the collision-resistance level of SHA-1.
>
>Yep, that must be it, Skipjack and DSA

From pbaker@verisign.com Mon Aug 30 20:32:15 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7V0WE3a019665
	for <saag@jis.mit.edu>; Mon, 30 Aug 2004 20:32:15 -0400 (EDT)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	i7V0WAjC001181
	for <saag@mit.edu>; Mon, 30 Aug 2004 20:32:10 -0400 (EDT)
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com
	[65.205.251.54])i7V0VZtP020655;	Mon, 30 Aug 2004 17:31:35 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <Q66RTFY7>; Mon, 30 Aug 2004 17:31:35 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEB0F@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Russ Housley'" <housley@vigilsec.com>,
   "Hallam-Baker, Phillip"
	 <pbaker@verisign.com>,
   "'David A. McGrew'" <mcgrew@cisco.com>
Subject: RE: [saag] Bad day at the hash function factory
Date: Mon, 30 Aug 2004 17:31:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.554091
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 31 Aug 2004 00:32:16 -0000

So DSA-512 is dead, but we can expect DSA-1024 and DSA-2048 shortly?

It would be useful if the new spec also provided some way of making the
random seed generation totaly foolproof.

Any idea when these might be along?

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Monday, August 30, 2004 10:38 AM
> To: Hallam-Baker, Phillip; 'David A. McGrew'
> Cc: saag@mit.edu
> Subject: RE: [saag] Bad day at the hash function factory
> 
> 
> Phill:
> 
> The DSA standard is being changed to accept larger key sizes. 
>  Once this is 
> done, it will no longer be limited to 1024-bit keys.  With 
> the bigger key 
> sizes, there is not need to phase them out in 2010.
> 
> Russ
> 
> At 09:13 AM 8/27/2004, Hallam-Baker, Phillip wrote:
> > > probably SKIPJACK, which is a block cipher with an 80-bit 
> key, which
> > > roughly corresponds to the collision-resistance level of SHA-1.
> >
> >Yep, that must be it, Skipjack and DSA
> 
From mcr@sandelman.ottawa.on.ca Tue Aug 31 09:31:28 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7VDVR3a010443
	for <saag@jis.mit.edu>; Tue, 31 Aug 2004 09:31:27 -0400 (EDT)
Received: from noxmail.sandelman.ottawa.on.ca
	(cyphermail.sandelman.ottawa.on.ca [205.150.200.161])i7VDVGUF001233
	for <saag@mit.edu>; Tue, 31 Aug 2004 09:31:22 -0400 (EDT)
Received: from lox.sandelman.ottawa.on.ca
	(IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178])i7VDKjS28339
	verified FAIL);	Tue, 31 Aug 2004 09:31:08 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca
	[205.150.200.247])i7VDPjU09228verified NO);
	Tue, 31 Aug 2004 09:26:05 -0400 (EDT)
Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1])
	i7VDHDB9004445;	Tue, 31 Aug 2004 09:17:31 -0400
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	i7UJOsjj002028;	Mon, 30 Aug 2004 15:24:57 -0400
To: dee3@pothole.com
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory 
In-Reply-To: Message from dee3@pothole.com 
	<Pine.LNX.4.60.0408221227070.19986@pothole.com> 
References: <20040818191747.E2C147199@sierra.rtfm.com>
	<2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
	<6.1.1.1.2.20040820101325.03cbfad8@mail.binhost.com>
	<729D69DA-F2BD-11D8-A59F-00039357A82A@extremenetworks.com>
	<18532.1093106549@marajade.sandelman.ottawa.on.ca>
	<Pine.LNX.4.60.0408221227070.19986@pothole.com> 
X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15)
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 30 Aug 2004 15:24:54 -0400
Message-ID: <2027.1093893894@marajade.sandelman.ottawa.on.ca>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Spam-Alum-Prob: 0.000006
Spam-Alum-Time: 0.542374
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 31 Aug 2004 13:31:28 -0000


>>>>> "dee3" == dee3  <dee3@pothole.com> writes:
    dee3> See draft-ietf-ipsec-esp-ah-algorithms-01.txt.

  yeah, I forgot about that one.
  QQQQ = AES-CBC here.

    >> In doing so, however, I want to start commonly deploying another hash
    >> as well.
    >> I.e. it is not enough to deprecate HMAC-MD5 (which I understand is not
    >> know to be vulnerable), and make HMAC-SHA1 the default. I want to make
    >> HMAC-SHA1 + QQQQ the new set of algorithms.
    >> having that "spare" out there is pretty useful.
    >> 

--
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
From jwkckid1@ix.netcom.com Wed Sep  1 23:52:25 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i823qP3a015874
	for <saag@jis.mit.edu>; Wed, 1 Sep 2004 23:52:25 -0400 (EDT)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	i823qNvT008178
	for <saag@mit.edu>; Wed, 1 Sep 2004 23:52:23 -0400 (EDT)
Received: from 1cust14.tnt36.dfw9.da.uu.net ([67.234.81.14]
	helo=ix.netcom.com)	by smtp6.mindspring.com with esmtp (Exim 3.33 #1)
	id 1C2ie7-0006ST-00	for saag@mit.edu; Wed, 01 Sep 2004 23:52:23 -0400
Message-ID: <4136B45E.1D742E03@ix.netcom.com>
Date: Wed, 01 Sep 2004 22:49:22 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: saag <saag@mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.591309
Subject: [saag] The End of Encryption?
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 02 Sep 2004 03:52:26 -0000

All,

  A very interesting article. Some of you may have already read it...

See:
http://www.technologyreview.com/articles/04/09/wo_garfinkel090104.asp

"The encryption algorithms that make virtually all electronic commerce
possible work only because certain mathematical problems are very,
very hard to solve. But some mathematicians are trying to prove that
there's really no difference between 'hard' and 'not hard'
problems--known
in the math biz as P and NP. In an article on TechnologyReview.com,
Simson Garfinkel spells out the real-world consequences of this
mathematical conundrum."

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From steve@stevecrocker.com Thu Sep  2 08:48:05 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i82Clu3a028293
	for <saag@jis.mit.edu>; Thu, 2 Sep 2004 08:48:05 -0400 (EDT)
Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238])
	i82ClsYs013843
	for <saag@mit.edu>; Thu, 2 Sep 2004 08:47:55 -0400 (EDT)
Received: from [66.93.106.226] (HELO SCROCKER)
  by EXECDSL.COM (CommuniGate Pro SMTP 3.3)
  with ESMTP id 7500271; Thu, 02 Sep 2004 08:47:17 -0400
From: "Steve Crocker" <steve@stevecrocker.com>
To: "'Jeff Williams'" <jwkckid1@ix.netcom.com>, "'saag'" <saag@mit.edu>
Subject: RE: [saag] The End of Encryption?
Date: Thu, 2 Sep 2004 08:47:25 -0400
Message-ID: <00bf01c490ea$ff553de0$0cffa8c0@SCROCKER>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200
In-Reply-To: <4136B45E.1D742E03@ix.netcom.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.632922
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 02 Sep 2004 12:48:06 -0000

Jeff,

Your posting suggests there will soon be a proof that P = NP and that
current encryption techniques will be broken.  In contrast, I think
Simson's article reports that no such proof is imminent and that the
problem remains open and has been put on the list of very hard
challenges ("Millenium Challenges").  I don't follow the literature very
closely, but I have not seen *any* evidence to suggest P = NP.  Does
anyone have such evidence?  By evidence, I mean anything reasonably
suggestive, not necessarily something as strong as a proof.

Steve

> -----Original Message-----
> From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On 
> Behalf Of Jeff Williams
> Sent: Thursday, September 02, 2004 1:49 AM
> To: saag
> Subject: [saag] The End of Encryption?
> 
> 
> All,
> 
>   A very interesting article. Some of you may have already read it...
> 
> See: 
> http://www.technologyreview.com/articles/04/09>
/wo_garfinkel090104.asp
> 
> "The encryption algorithms that make virtually all electronic 
> commerce possible work only because certain mathematical 
> problems are very, very hard to solve. But some 
> mathematicians are trying to prove that there's really no 
> difference between 'hard' and 'not hard' problems--known in 
> the math biz as P and NP. In an article on 
> TechnologyReview.com, Simson Garfinkel spells out the 
> real-world consequences of this mathematical conundrum."
> 
> Regards,
> 
> --
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 134k members/stakeholders 
> strong!) "Be precise in the use of words and expect precision 
> from others" -
>     Pierre Abelard
> 
> "If the probability be called P; the injury, L; and the 
> burden, B; liability depends upon whether B is less than L 
> multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947] 
> ===============================================================
> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security 
> IDNS. div. of Information Network Eng.  INEG. INC. E-Mail 
> jwkckid1@ix.netcom.com  Registered Email addr with the USPS 
> Contact Number: 214-244-4827
> 
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 

From pbaker@verisign.com Thu Sep  2 13:29:16 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i82HTF3a005733
	for <saag@jis.mit.edu>; Thu, 2 Sep 2004 13:29:15 -0400 (EDT)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	i82HTDek029726
	for <saag@mit.edu>; Thu, 2 Sep 2004 13:29:13 -0400 (EDT)
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com
	[65.205.251.54])i82HTCIC008792
	for <saag@mit.edu>; Thu, 2 Sep 2004 10:29:12 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <SDPA8RAZ>; Thu, 2 Sep 2004 10:29:13 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEB25@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: saag <saag@mit.edu>
Subject: RE: [saag] The End of Encryption?
Date: Thu, 2 Sep 2004 10:29:10 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.610276
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 02 Sep 2004 17:29:17 -0000

It is not very relevant.

NP complete problems are only asymptoticaly hard. It is possible to solve
the knapsack problem in much less than NP time for most cases - as folk who
tried to use them for public key algorithms found.

What you need is a problem that is reliably and quantifiably hard.

> -----Original Message-----
> From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu]On Behalf Of
> Jeff Williams
> Sent: Thursday, September 02, 2004 1:49 AM
> To: saag
> Subject: [saag] The End of Encryption?
> 
> 
> All,
> 
>   A very interesting article. Some of you may have already read it...
> 
> See:
> http://www.technologyreview.com/articles/04/09/wo_garfinkel090104.asp
> 
> "The encryption algorithms that make virtually all electronic commerce
> possible work only because certain mathematical problems are very,
> very hard to solve. But some mathematicians are trying to prove that
> there's really no difference between 'hard' and 'not hard'
> problems--known
> in the math biz as P and NP. In an article on TechnologyReview.com,
> Simson Garfinkel spells out the real-world consequences of this
> mathematical conundrum."
> 
> Regards,
> 
> --
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
> "Be precise in the use of words and expect precision from others" -
>     Pierre Abelard
> 
> "If the probability be called P; the injury, L; and the burden, B;
> liability depends upon whether B is less than L multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> ===============================================================
> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> IDNS. div. of Information Network Eng.  INEG. INC.
> E-Mail jwkckid1@ix.netcom.com
>  Registered Email addr with the USPS
> Contact Number: 214-244-4827
> 
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 
From mouse@Sparkle.Rodents.Montreal.QC.CA Thu Sep  2 14:10:26 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i82IAN3a007047
	for <saag@jis.mit.edu>; Thu, 2 Sep 2004 14:10:23 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i82IAGU5000373
	for <saag@mit.edu>; Thu, 2 Sep 2004 14:10:17 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA02178;
	Thu, 2 Sep 2004 14:10:15 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200409021810.OAA02178@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Thu, 2 Sep 2004 13:55:47 -0400 (EDT)
To: The Indian Food List <saag@mit.edu>
Subject: Re: [saag] The End of Encryption?
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEB25@mou1wnexm05.vcorp.ad.vrsn.com>
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEB25@mou1wnexm05.vcorp.ad.vrsn.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.575605
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 02 Sep 2004 18:10:26 -0000

> It is not very relevant.

Actually, this is only partially true.

> NP complete problems are only asymptoticaly hard.  It is possible to
> solve the knapsack problem in much less than NP time for most cases -
> as folk who tried to use them for public key algorithms found.

> What you need is a problem that is reliably and quantifiably hard.

Yes - but it's still true that if P=NP, then all those NP-hard problems
are suddenly easy.  (Not that polynomial time (or space) is necessarily
easy in practice; it takes a fairly large N (approximately 2.4e+10) for
1.00001^N to outweigh N^10000, yet the former is considered hard and
the latter easy by complexity theorists.  And in a sense they're right,
but if all the Ns you care about are below that point, that doesn't
much matter in practice.)

Also, even if it's proven that P=NP, the proof may not actually give a
polynomial-time algorithm for solving an NP-hard problem (instead
merely proving that such an algorithm must exist), in which case it's
of no immediate practical use.

And, of course, certain relevant problems have not been proven to be
NP-hard.  (Factoring and discrete logarithms come to mind, though I'm
not au courant enough to be sure they are actually examples.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From rhee@sookmyung.ac.kr Thu Sep  2 21:58:32 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i831wT3a019326
	for <saag@jis.mit.edu>; Thu, 2 Sep 2004 21:58:29 -0400 (EDT)
Received: from ccmail.sookmyung.ac.kr ([203.252.201.50])
	i831wQJe003154
	for <saag@mit.edu>; Thu, 2 Sep 2004 21:58:27 -0400 (EDT)
Received: from sookmyung.ac.kr
        by mit.edu with ESMTP (BeeHive 1.4.1) 
        for saag@mit.edu; Fri, 3 Sep 2004 11:03:21 +0900
Message-ID: <4137CFB4.6FD1B72@sookmyung.ac.kr>
Date: Fri, 03 Sep 2004 10:58:12 +0900
From: Gwangsoo Rhee <rhee@sookmyung.ac.kr>
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Subject: Re: [saag] The End of Encryption?
References:
	<C6DDA43B91BFDA49AA2F1E473732113E010BEB25@mou1wnexm05.vcorp.ad.vrsn.com>
	<200409021810.OAA02178@Sparkle.Rodents.Montreal.QC.CA>
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.622380
cc: The Indian Food List <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: rhee@sookmyung.ac.kr
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 03 Sep 2004 01:58:33 -0000



der Mouse wrote:

> > It is not very relevant.
>
> Actually, this is only partially true.
>
> > NP complete problems are only asymptoticaly hard.  It is possible to
> > solve the knapsack problem in much less than NP time for most cases -
> > as folk who tried to use them for public key algorithms found.
>
> > What you need is a problem that is reliably and quantifiably hard.
>
> Yes - but it's still true that if P=NP, then all those NP-hard problems
> are suddenly easy.  (Not that polynomial time (or space) is necessarily
> easy in practice; it takes a fairly large N (approximately 2.4e+10) for
> 1.00001^N to outweigh N^10000, yet the former is considered hard and
> the latter easy by complexity theorists.  And in a sense they're right,
> but if all the Ns you care about are below that point, that doesn't
> much matter in practice.)
>
> Also, even if it's proven that P=NP, the proof may not actually give a
> polynomial-time algorithm for solving an NP-hard problem (instead
> merely proving that such an algorithm must exist), in which case it's
> of no immediate practical use.
>

The proof will immediately give polynomial-time algorithms
for every NP-complete problem, because

(1) the proof will involve a polynomial-time algorithm for one of
the NP-complete problems (those hard problems in NP), and
(2) all the NP-complete problems are related to each other by
some polynomial transformations, which means a solution to one
NP-complete problem can be transformed to a solution to another
NP-complete problem in polynomial-time, and
(3) the polynomial-time transformation for each NP-complete problem
from one of the other NP-complete problems was already constructed
in its NPcompleteness proof.

>
> And, of course, certain relevant problems have not been proven to be
> NP-hard.  (Factoring and discrete logarithms come to mind, though I'm
> not au courant enough to be sure they are actually examples.)
>
> /~\ The ASCII                           der Mouse
> \ / Ribbon Campaign
>  X  Against HTML               mouse@rodents.montreal.qc.ca
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

--

---------------------------------------
Gwangsoo Rhee <rhee@sookmyung.ac.kr>
tel: +82-2-710-9429  fax: 710-9296
HP: 011-9691-9541
---------------------------------------


From mouse@Sparkle.Rodents.Montreal.QC.CA Fri Sep  3 00:25:20 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i834PJ3a022956
	for <saag@jis.mit.edu>; Fri, 3 Sep 2004 00:25:19 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i834PIut004663
	for <saag@mit.edu>; Fri, 3 Sep 2004 00:25:18 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA14814;
	Fri, 3 Sep 2004 00:25:17 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200409030425.AAA14814@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Fri, 3 Sep 2004 00:04:54 -0400 (EDT)
To: The Indian Food List <saag@mit.edu>
Subject: Re: [saag] The End of Encryption?
In-Reply-To: <4137CFB4.6FD1B72@sookmyung.ac.kr>
References: 
	<C6DDA43B91BFDA49AA2F1E473732113E010BEB25@mou1wnexm05.vcorp.ad.vrsn.com>
	<200409021810.OAA02178@Sparkle.Rodents.Montreal.QC.CA>
	<4137CFB4.6FD1B72@sookmyung.ac.kr>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.586144
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 03 Sep 2004 04:25:21 -0000

>> Also, even if it's proven that P=NP, the proof may not actually give
>> a polynomial-time algorithm for solving an NP-hard problem (instead
>> merely proving that such an algorithm must exist), [...]
> The proof will immediately give polynomial-time algorithms for every
> NP-complete problem, because

> (1) the proof will involve a polynomial-time algorithm for one of the
> NP-complete problems

Ah.  That wasn't clear to me; the Technology Review article gives no
hint of what form the proof might take (whether by example, as you
describe, or one of the various forms of existence proof that does not
produce an example).

> (3) the polynomial-time transformation for each NP-complete problem
> from one of the other NP-complete problems was already constructed in
> its NPcompleteness proof.

It's not quite that easy.  Solving any NP-complete problem in
polynomial time means that all NP problems are solvable in polynomial
time, but it does not necessarily give an algorithm for doing so for
any particular problem; it merely means that such an algorithm must
exist.  (After all, at least one NP-completeness proof must have been
done by means other than demonstrating a polynomial-time transformation
to some other NP-complete problem!)

>> And, of course, certain relevant problems have not been proven to be
>> NP-hard.  (Factoring and discrete logarithms come to mind, though
>> I'm not au courant enough to be sure they are actually examples.)

Which was of course me being confused.  They don't need to be NP-hard
for this work to be relevant, merely NP, which factoring is and offhand
I think discrete logs are (though I'd have to think about it mroe to be
sure).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From jwkckid1@ix.netcom.com Fri Sep  3 02:10:38 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i836AZ3a026140
	for <saag@jis.mit.edu>; Fri, 3 Sep 2004 02:10:35 -0400 (EDT)
Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net
	[207.69.200.243])i836AYuv022797
	for <saag@mit.edu>; Fri, 3 Sep 2004 02:10:34 -0400 (EDT)
Received: from 1cust159.tnt36.dfw9.da.uu.net ([67.234.81.159]
	helo=ix.netcom.com)
	by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1C37HJ-0004qY-00; Fri, 03 Sep 2004 02:10:30 -0400
Message-ID: <41382643.39DD57FC@ix.netcom.com>
Date: Fri, 03 Sep 2004 01:07:31 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: Steve Crocker <steve@stevecrocker.com>
Subject: Re: [saag] The End of Encryption?
References: <00bf01c490ea$ff553de0$0cffa8c0@SCROCKER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.734559
cc: 'saag' <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 03 Sep 2004 06:10:39 -0000

Steve and all,

  Steve, first let me say I appreciate your input.  >:)

 I personally am not suggesting that there will soon be proof that
P=NP.  I happen to believe that this will happen as the article I
believe rightly suggests, but does not offer any real/strong proof 
of same.  Yet the arguments provided in the article if you read it 
closely, are mathematically very strong.  History also tells us, 
or at a minimum, has shown a number of times that any encryption 
algorithm is breakable, and many have been broken.

 I am also not personally suggesting that the author is right in his
assumptions, nor am I suggesting he isn't right/correct either, but 
he makes a very strong argument as far as he went, anyway...  He ask 
a question as a suggestion or challenge as you indicate in your 
remarks below.  But that question is more than a challenge if you 
consider the long history of encryption...

 So I view Simsons article as both a challenge and a warning.  I hope
others in the field working independently as well as cooperatively will
head both.  Given your remarks Steve, I gathered that you only see
the challenge in the question.  Perhaps I am not interpreting your
remarks properly???  Please advise...

  My history with cryptography is about 25 years long.  I have
personally seen many encryption methods and algorithms broken or 
compromised.  I have participated in helping to break a few myself.  
However now I look to find ways to make breaking encryption 
algorithms more difficult so as to allow for them to have a longer 
safe use life span.

 As 9/11 has shown us all I hope, we must in my opinion accept that
there are those within our internet community that would consider
using their skills as cryptographers for harmful means.  Therefore we
whom are the "Good guys" in cryptography must look for ways to
expediate change over in safe encryption use and consider planning
for the worst in the use of certain encryption algorithms.  So setting
a long term standard or "Best Practice" is no longer a wise approach
or method for the safe long term use of encryption.  This was the
"Theme" I got from Simsons article, more than any thing else.  I for
one am glad he tried to point that out, although not very directly...

  Therefore I am confident in believing that Adelman's conclusion
is over confident at a minimum and would make a separate bet
doubling Sipser's wager that in a given amount of time the bet Sipser
made in too short amount of time, will come to pass...

  To answer your final question, Steve, I do have some very good
data that P approximates NP, but would not, and at present cannot
publish that on any public forum.  However I would be able to
share that information/evidance with you or anyone that can
be very confidential with the data and/or evidence...  You know
how to reach me [See sig file below]

Steve Crocker wrote:

> Jeff,
>
> Your posting suggests there will soon be a proof that P = NP and that
> current encryption techniques will be broken.  In contrast, I think
> Simson's article reports that no such proof is imminent and that the
> problem remains open and has been put on the list of very hard
> challenges ("Millenium Challenges").  I don't follow the literature very
> closely, but I have not seen *any* evidence to suggest P = NP.  Does
> anyone have such evidence?  By evidence, I mean anything reasonably
> suggestive, not necessarily something as strong as a proof.
>
> Steve
>
> > -----Original Message-----
> > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On
> > Behalf Of Jeff Williams
> > Sent: Thursday, September 02, 2004 1:49 AM
> > To: saag
> > Subject: [saag] The End of Encryption?
> >
> >
> > All,
> >
> >   A very interesting article. Some of you may have already read it...
> >
> > See:
> > http://www.technologyreview.com/articles/04/09>
> /wo_garfinkel090104.asp
> >
> > "The encryption algorithms that make virtually all electronic
> > commerce possible work only because certain mathematical
> > problems are very, very hard to solve. But some
> > mathematicians are trying to prove that there's really no
> > difference between 'hard' and 'not hard' problems--known in
> > the math biz as P and NP. In an article on
> > TechnologyReview.com, Simson Garfinkel spells out the
> > real-world consequences of this mathematical conundrum."
> >
> > Regards,
> >
> > --
> > Jeffrey A. Williams
> > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders
> > strong!) "Be precise in the use of words and expect precision
> > from others" -
> >     Pierre Abelard
> >
> > "If the probability be called P; the injury, L; and the
> > burden, B; liability depends upon whether B is less than L
> > multiplied by
> > P: i.e., whether B is less than PL."
> > United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> > ===============================================================
> > Updated 1/26/04
> > CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> > IDNS. div. of Information Network Eng.  INEG. INC. E-Mail
> > jwkckid1@ix.netcom.com  Registered Email addr with the USPS
> > Contact Number: 214-244-4827
> >
> >
> > _______________________________________________
> > saag mailing list
> > saag@mit.edu
> > https://jis.mit.edu/mailman/listinfo/saag
> >

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827
From mouse@Sparkle.Rodents.Montreal.QC.CA Fri Sep  3 02:23:21 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i836NL3a026556
	for <saag@jis.mit.edu>; Fri, 3 Sep 2004 02:23:21 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i836NJuv002857
	for <saag@mit.edu>; Fri, 3 Sep 2004 02:23:20 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA15784;
	Fri, 3 Sep 2004 02:23:19 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200409030623.CAA15784@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Fri, 3 Sep 2004 02:15:26 -0400 (EDT)
To: saag@mit.edu
Subject: Re: [saag] The End of Encryption?
In-Reply-To: <41382643.39DD57FC@ix.netcom.com>
References: <00bf01c490ea$ff553de0$0cffa8c0@SCROCKER>
	<41382643.39DD57FC@ix.netcom.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.557191
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 03 Sep 2004 06:23:22 -0000

> So I view Simsons article as both a challenge and a warning.

I think that a proof that P=NP will have _far_ more wide-reaching
effects than just cryptography - especially if it does result in
algorithms fast enough to be useful for the sorts of problems
encountered in practice.

Don't forget that even if (say) factoring is in P, it's still entirely
possible that the polynomial-time algorithms are faster only for
problems so huge that it makes no difference in practice, in which case
such a result won't have much immediate practical effect, for all its
tremendous theoretical importance.  (And of course it may be otherwise,
too; it's too soon to tell, at least too soon for _me_ to tell.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From rhee@sookmyung.ac.kr Fri Sep  3 02:28:02 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i836S13a026801
	for <saag@jis.mit.edu>; Fri, 3 Sep 2004 02:28:01 -0400 (EDT)
Received: from ccmail.sookmyung.ac.kr ([203.252.201.50])
	i836RsBk021770
	for <saag@mit.edu>; Fri, 3 Sep 2004 02:27:56 -0400 (EDT)
Received: from sookmyung.ac.kr
        by mit.edu with ESMTP (BeeHive 1.4.1) 
        for saag@mit.edu; Fri, 3 Sep 2004 15:32:31 +0900
Message-ID: <41380ECC.3B004BC2@sookmyung.ac.kr>
Date: Fri, 03 Sep 2004 15:27:24 +0900
From: Gwangsoo Rhee <rhee@sookmyung.ac.kr>
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Subject: Re: [saag] The End of Encryption?
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEB25@mou1wnexm05.vcorp.ad.vrsn.com>
	<200409021810.OAA02178@Sparkle.Rodents.Montreal.QC.CA>
	<200409030425.AAA14814@Sparkle.Rodents.Montreal.QC.CA>
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.637381
cc: The Indian Food List <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: rhee@sookmyung.ac.kr
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 03 Sep 2004 06:28:03 -0000



der Mouse wrote:

> >> Also, even if it's proven that P=NP, the proof may not actually give
> >> a polynomial-time algorithm for solving an NP-hard problem (instead
> >> merely proving that such an algorithm must exist), [...]
> > The proof will immediately give polynomial-time algorithms for every
> > NP-complete problem, because
>
> > (1) the proof will involve a polynomial-time algorithm for one of the
> > NP-complete problems
>
> Ah.  That wasn't clear to me; the Technology Review article gives no
> hint of what form the proof might take (whether by example, as you
> describe, or one of the various forms of existence proof that does not
> produce an example).

I'd like to say that a proof not involving an actual polynomial-time
algorithm is very unlikely in this case.

>
>
> > (3) the polynomial-time transformation for each NP-complete problem
> > from one of the other NP-complete problems was already constructed in
> > its NPcompleteness proof.
>
> It's not quite that easy.  Solving any NP-complete problem in
> polynomial time means that all NP problems are solvable in polynomial
> time, but it does not necessarily give an algorithm for doing so for
> any particular problem; it merely means that such an algorithm must
> exist.  (After all, at least one NP-completeness proof must have been
> done by means other than demonstrating a polynomial-time transformation
> to some other NP-complete problem!)
>

The first NP-completeness proof (called Cook's Theorem) shows
how we can construct polynomial-time algorithms for every NP-complete
problem
once we find a polynomial-time algorithm for a single NP-complete problem.

All the texts I read imply that P === NP proof will have to be done with an
example,
and that P != NP proof may need a new paradigm.
If you don't feel that way, I can't give you any proof.

Just in case you (or some other people reading this discussion)
need a good reference on NP-completeness and NP-hard problems,
I recommend the following classic text:

 Michael R. Garey and David S. Johnson,
 Computers and Intractability:
 A Guide to the Theory of NP-Completeness,
 Freeman, 1979




>
> >> And, of course, certain relevant problems have not been proven to be
> >> NP-hard.  (Factoring and discrete logarithms come to mind, though
> >> I'm not au courant enough to be sure they are actually examples.)
>
> Which was of course me being confused.  They don't need to be NP-hard
> for this work to be relevant, merely NP, which factoring is and offhand
> I think discrete logs are (though I'd have to think about it mroe to be
> sure).
>
> /~\ The ASCII                           der Mouse
> \ / Ribbon Campaign
>  X  Against HTML               mouse@rodents.montreal.qc.ca
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

--

---------------------------------------
Gwangsoo Rhee <rhee@sookmyung.ac.kr>
tel: +82-2-710-9429  fax: 710-9296
HP: 011-9691-9541
---------------------------------------


From mouse@Sparkle.Rodents.Montreal.QC.CA Fri Sep  3 02:54:24 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i836sN3a027348
	for <saag@jis.mit.edu>; Fri, 3 Sep 2004 02:54:23 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i836sKuv021623
	for <saag@mit.edu>; Fri, 3 Sep 2004 02:54:21 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA15885;
	Fri, 3 Sep 2004 02:54:19 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200409030654.CAA15885@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Fri, 3 Sep 2004 02:34:02 -0400 (EDT)
To: The Indian Food List <saag@mit.edu>
Subject: Re: [saag] The End of Encryption?
In-Reply-To: <41380ECC.3B004BC2@sookmyung.ac.kr>
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEB25@mou1wnexm05.vcorp.ad.vrsn.com>
	<200409021810.OAA02178@Sparkle.Rodents.Montreal.QC.CA>
	<200409030425.AAA14814@Sparkle.Rodents.Montreal.QC.CA>
	<41380ECC.3B004BC2@sookmyung.ac.kr>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.578391
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 03 Sep 2004 06:54:25 -0000

> The first NP-completeness proof (called Cook's Theorem) shows how we
> can construct polynomial-time algorithms for every NP-complete
> problem once we find a polynomial-time algorithm for a single
> NP-complete problem.

Actually (I just looked it up): it shows how to construct a
(determinstic) polynomial-time algorithm for any NP problem (not just
the NP-complete ones) given a (determinstic) polynomial-time solution
to satisfiability and a nondeterminstic Turing machine to solve the
problem in question in (nondeterminstic) polynomial time.

That's quite enough for our purposes, as it's very easy to construct
suitable nondeterminstic Turing machines for most (all?) of the
interesting NP problems.

> All the texts I read imply that P === NP proof will have to be done
> with an example, and that P != NP proof may need a new paradigm.

That's what I would consider most likely too, but I've been surprised
often enough before that I don't count on such feelings.  (I could, for
example, imagine someone showing P=NP without giving an algorithm for
anything by pulling a contradiction out of the hypothesis that there
exists a problem that's NP but not P.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From jwkckid1@ix.netcom.com Fri Sep  3 03:47:10 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i837l93a028402
	for <saag@jis.mit.edu>; Fri, 3 Sep 2004 03:47:09 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net
	[207.69.200.148])i837l8uv022411
	for <saag@mit.edu>; Fri, 3 Sep 2004 03:47:08 -0400 (EDT)
Received: from 1cust160.tnt36.dfw9.da.uu.net ([67.234.81.160]
	helo=ix.netcom.com)
	by granger.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1C38lF-0005pf-00; Fri, 03 Sep 2004 03:45:30 -0400
Message-ID: <41383C84.5E915C82@ix.netcom.com>
Date: Fri, 03 Sep 2004 02:42:29 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Subject: Re: [saag] The End of Encryption?
References: <00bf01c490ea$ff553de0$0cffa8c0@SCROCKER>
	<200409030623.CAA15784@Sparkle.Rodents.Montreal.QC.CA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.615920
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 03 Sep 2004 07:47:11 -0000

der Mouse and all,

der Mouse wrote:

> > So I view Simsons article as both a challenge and a warning.
>
> I think that a proof that P=NP will have _far_ more wide-reaching
> effects than just cryptography - especially if it does result in
> algorithms fast enough to be useful for the sorts of problems
> encountered in practice.

  I agree.

>
>
> Don't forget that even if (say) factoring is in P, it's still entirely
> possible that the polynomial-time algorithms are faster only for
> problems so huge that it makes no difference in practice, in which case
> such a result won't have much immediate practical effect, for all its
> tremendous theoretical importance.  (And of course it may be otherwise,
> too; it's too soon to tell, at least too soon for _me_ to tell.)

 I disagree with your conclusion here.  The time to tell is now, if
possible.  We at least should put forth our best effort(s) to do
so.  Hence your premise for your conclusion doesn't fit.  But it
was nicely put.  >:)

>
>
> /~\ The ASCII                           der Mouse
> \ / Ribbon Campaign
>  X  Against HTML               mouse@rodents.montreal.qc.ca
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From jwkckid1@ix.netcom.com Fri Sep  3 03:52:58 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i837qv3a028557
	for <saag@jis.mit.edu>; Fri, 3 Sep 2004 03:52:57 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net
	[207.69.200.148])i837qvuv025824
	for <saag@mit.edu>; Fri, 3 Sep 2004 03:52:57 -0400 (EDT)
Received: from 1cust160.tnt36.dfw9.da.uu.net ([67.234.81.160]
	helo=ix.netcom.com)
	by granger.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1C38qu-0006l7-00; Fri, 03 Sep 2004 03:51:21 -0400
Message-ID: <41383DE3.829C2690@ix.netcom.com>
Date: Fri, 03 Sep 2004 02:48:21 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: rhee@sookmyung.ac.kr
Subject: Re: [saag] The End of Encryption?
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEB25@mou1wnexm05.vcorp.ad.vrsn.com>
	<200409021810.OAA02178@Sparkle.Rodents.Montreal.QC.CA>
	<41380ECC.3B004BC2@sookmyung.ac.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.698500
cc: The Indian Food List <saag@mit.edu>
cc: der Mouse <mouse@Rodents.Montreal.QC.CA>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 03 Sep 2004 07:52:59 -0000

Gwangsoo and all,

Gwangsoo Rhee wrote:

> der Mouse wrote:
>
> > >> Also, even if it's proven that P=NP, the proof may not actually give
> > >> a polynomial-time algorithm for solving an NP-hard problem (instead
> > >> merely proving that such an algorithm must exist), [...]
> > > The proof will immediately give polynomial-time algorithms for every
> > > NP-complete problem, because
> >
> > > (1) the proof will involve a polynomial-time algorithm for one of the
> > > NP-complete problems
> >
> > Ah.  That wasn't clear to me; the Technology Review article gives no
> > hint of what form the proof might take (whether by example, as you
> > describe, or one of the various forms of existence proof that does not
> > produce an example).
>
> I'd like to say that a proof not involving an actual polynomial-time
> algorithm is very unlikely in this case.

  Yes at present this is true. The real argument from this perspective
is a matter of how much time, and not in the likelihood of the actuality.

>
>
> >
> >
> > > (3) the polynomial-time transformation for each NP-complete problem
> > > from one of the other NP-complete problems was already constructed in
> > > its NPcompleteness proof.
> >
> > It's not quite that easy.  Solving any NP-complete problem in
> > polynomial time means that all NP problems are solvable in polynomial
> > time, but it does not necessarily give an algorithm for doing so for
> > any particular problem; it merely means that such an algorithm must
> > exist.  (After all, at least one NP-completeness proof must have been
> > done by means other than demonstrating a polynomial-time transformation
> > to some other NP-complete problem!)
> >
>
> The first NP-completeness proof (called Cook's Theorem) shows
> how we can construct polynomial-time algorithms for every NP-complete
> problem
> once we find a polynomial-time algorithm for a single NP-complete problem.
>
> All the texts I read imply that P === NP proof will have to be done with an
> example,
> and that P != NP proof may need a new paradigm.
> If you don't feel that way, I can't give you any proof.
>
> Just in case you (or some other people reading this discussion)
> need a good reference on NP-completeness and NP-hard problems,
> I recommend the following classic text:
>
>  Michael R. Garey and David S. Johnson,
>  Computers and Intractability:
>  A Guide to the Theory of NP-Completeness,
>  Freeman, 1979

 Yes this is "Classic" and as such, dated.

>
>
> >
> > >> And, of course, certain relevant problems have not been proven to be
> > >> NP-hard.  (Factoring and discrete logarithms come to mind, though
> > >> I'm not au courant enough to be sure they are actually examples.)
> >
> > Which was of course me being confused.  They don't need to be NP-hard
> > for this work to be relevant, merely NP, which factoring is and offhand
> > I think discrete logs are (though I'd have to think about it mroe to be
> > sure).
> >
> > /~\ The ASCII                           der Mouse
> > \ / Ribbon Campaign
> >  X  Against HTML               mouse@rodents.montreal.qc.ca
> > / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> > _______________________________________________
> > saag mailing list
> > saag@mit.edu
> > https://jis.mit.edu/mailman/listinfo/saag
>
> --
>
> ---------------------------------------
> Gwangsoo Rhee <rhee@sookmyung.ac.kr>
> tel: +82-2-710-9429  fax: 710-9296
> HP: 011-9691-9541
> ---------------------------------------
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From mouse@Sparkle.Rodents.Montreal.QC.CA Fri Sep  3 03:59:18 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i837xH3a028786
	for <saag@jis.mit.edu>; Fri, 3 Sep 2004 03:59:17 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i837xEuv029999
	for <saag@mit.edu>; Fri, 3 Sep 2004 03:59:16 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA16103;
	Fri, 3 Sep 2004 03:59:13 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200409030759.DAA16103@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Fri, 3 Sep 2004 03:52:51 -0400 (EDT)
To: saag@mit.edu
Subject: Re: [saag] The End of Encryption?
In-Reply-To: <41383C84.5E915C82@ix.netcom.com>
References: <00bf01c490ea$ff553de0$0cffa8c0@SCROCKER>
	<200409030623.CAA15784@Sparkle.Rodents.Montreal.QC.CA>
	<41383C84.5E915C82@ix.netcom.com>
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.576836
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 03 Sep 2004 07:59:19 -0000

>> [...] it's still entirely possible that the polynomial-time
>> algorithms are faster only for problems so huge that it makes no
>> difference in practice, in which case such a result won't have much
>> immediate practical effect, for all its tremendous theoretical
>> importance.  (And of course it may be otherwise, too; it's too soon
>> to tell, at least too soon for _me_ to tell.)
> I disagree with your conclusion here.  The time to tell is now, if
> possible.  We at least should put forth our best effort(s) to do so.

I think you misunderstood my "tell".  I meant, it's too soon for me to
tell whether a P=NP result will have immediate practical consequences.
This is because I haven't seen any such result yet, nor any indication
of whether it will introduce such large constant factors as to wipe out
the polynomial-vs-superpolynomial gain for problems of practical size.

I agree with what I think you meant, though, that being that it's by no
means too soon to start thinking/talking about what it could mean, and
how we might deal with the consequences, if P=NP is proven and the
result brings us *practically* fast algorithms to solve currently-hard
problems like factoring (or for that matter breaking traditional block
ciphers).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From jwkckid1@ix.netcom.com Fri Sep  3 04:40:09 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i838e63a029916
	for <saag@jis.mit.edu>; Fri, 3 Sep 2004 04:40:06 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net
	[207.69.200.148])i838e5Bk004343
	for <saag@mit.edu>; Fri, 3 Sep 2004 04:40:05 -0400 (EDT)
Received: from 1cust160.tnt36.dfw9.da.uu.net ([67.234.81.160]
	helo=ix.netcom.com)
	by granger.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1C39aY-0003KD-00; Fri, 03 Sep 2004 04:38:30 -0400
Message-ID: <413848F1.D040A4E3@ix.netcom.com>
Date: Fri, 03 Sep 2004 03:35:30 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Subject: Re: [saag] The End of Encryption?
References: <00bf01c490ea$ff553de0$0cffa8c0@SCROCKER>
	<200409030623.CAA15784@Sparkle.Rodents.Montreal.QC.CA>
	<200409030759.DAA16103@Sparkle.Rodents.Montreal.QC.CA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.711483
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 03 Sep 2004 08:40:10 -0000

der Mouse and all,

der Mouse wrote:

> >> [...] it's still entirely possible that the polynomial-time
> >> algorithms are faster only for problems so huge that it makes no
> >> difference in practice, in which case such a result won't have much
> >> immediate practical effect, for all its tremendous theoretical
> >> importance.  (And of course it may be otherwise, too; it's too soon
> >> to tell, at least too soon for _me_ to tell.)
> > I disagree with your conclusion here.  The time to tell is now, if
> > possible.  We at least should put forth our best effort(s) to do so.
>
> I think you misunderstood my "tell".  I meant, it's too soon for me to
> tell whether a P=NP result will have immediate practical consequences.
> This is because I haven't seen any such result yet, nor any indication
> of whether it will introduce such large constant factors as to wipe out
> the polynomial-vs-superpolynomial gain for problems of practical size.

 Ah, ok.  My misunderstanding.  However, still given the thoughts
provided in the article which I posted to start this thread, we all should
be able to determine that even without results or hard data, (some of which

I can and have offered to provide BTW when responding to Steve) that
through some basic mathematical thought, extrapolate that the possibility
of P=NP is very likely and sooner than the article concluded.  Hence why
I believe it was posed as a question, and therefore again a challenge
AND a warning.

>
>
> I agree with what I think you meant, though, that being that it's by no
> means too soon to start thinking/talking about what it could mean, and
> how we might deal with the consequences, if P=NP is proven and the
> result brings us *practically* fast algorithms to solve currently-hard
> problems like factoring (or for that matter breaking traditional block
> ciphers).

  Ok good!  >:)  But more than just "Thinking about" is IMHO, necessary.
It seems to me anyway, that it is necessary that we whom are actively
involved in cryptology in earnest, be actually working on this, not just
chatting about it in just very thoughtful ways or with meaningful dialog.

>
>
> /~\ The ASCII                           der Mouse
> \ / Ribbon Campaign
>  X  Against HTML               mouse@rodents.montreal.qc.ca
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From suresh.krishnan@ericsson.com Thu Sep  9 19:32:09 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i89NW83a013375
	for <saag@jis.mit.edu>; Thu, 9 Sep 2004 19:32:09 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3])
	i89NW7M0011947
	for <saag@mit.edu>; Thu, 9 Sep 2004 19:32:07 -0400 (EDT)
Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se
	[138.85.133.51])
	by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i89NW7bj021739
	for <saag@mit.edu>; Thu, 9 Sep 2004 18:32:07 -0500 (CDT)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service
	(5.5.2657.72)	id <RPQP2BJ2>; Thu, 9 Sep 2004 18:31:44 -0500
Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by
	EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service
	Version 5.5.2657.72)	id R8Y2MBYC; Thu, 9 Sep 2004 19:32:06 -0400
Date: Thu, 9 Sep 2004 19:27:28 -0400 (EDT)
From: Suresh Krishnan <suresh.krishnan@ericsson.ca>
X-X-Sender: lmcsukr@localhost.localdomain
To: saag@mit.edu
Message-ID: <Pine.LNX.4.44.0409091910110.26875-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Spam-Alum-Prob: 0.000078
Spam-Alum-Time: 0.529188
Subject: [saag] Throwing away bits in a SHA-1 hash
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Suresh Krishnan <suresh.krishnan@ericsson.ca>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 09 Sep 2004 23:32:10 -0000

Hi Folks,
  I am looking to upgrade an algorithm which uses a MD5 hash to produce 2 
random 64 bit numbers. One of these numbers is used as a history 
value for the next iteration. If I use SHA-1 is it possible to throw away 
32 bits and obtain 2 random 64 bit numbers from the hash? I would 
really appreciate any pointers/suggestions on how to accomplish this 
safely.

Thanks
Suresh
From housley@vigilsec.com Fri Sep 10 15:01:34 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8AJ1X3a018339
	for <saag@jis.mit.edu>; Fri, 10 Sep 2004 15:01:33 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i8AJ1WZk001886
	for <saag@mit.edu>; Fri, 10 Sep 2004 15:01:32 -0400 (EDT)
Received: (qmail 29283 invoked by uid 0); 10 Sep 2004 19:01:26 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.41.133)
  by woodstock.binhost.com with SMTP; 10 Sep 2004 19:01:26 -0000
Message-Id: <6.1.2.0.2.20040910150142.02e13ec0@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 10 Sep 2004 15:02:23 -0400
To: Suresh Krishnan <suresh.krishnan@ericsson.ca>, saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] Throwing away bits in a SHA-1 hash
In-Reply-To: <Pine.LNX.4.44.0409091910110.26875-100000@localhost.localdo
 main>
References: <Pine.LNX.4.44.0409091910110.26875-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.543914
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 10 Sep 2004 19:01:34 -0000

Can you point to the specification that is currently using MD5?  More 
context is needed.

Russ

At 07:27 PM 9/9/2004, Suresh Krishnan wrote:
>Hi Folks,
>   I am looking to upgrade an algorithm which uses a MD5 hash to produce 2
>random 64 bit numbers. One of these numbers is used as a history
>value for the next iteration. If I use SHA-1 is it possible to throw away
>32 bits and obtain 2 random 64 bit numbers from the hash? I would
>really appreciate any pointers/suggestions on how to accomplish this
>safely.
>
>Thanks
>Suresh
>_______________________________________________
>saag mailing list
>saag@mit.edu
>https://jis.mit.edu/mailman/listinfo/saag

From mcgrew@cisco.com Mon Sep 13 13:23:16 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8DHNF3a016389
	for <saag@jis.mit.edu>; Mon, 13 Sep 2004 13:23:15 -0400 (EDT)
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71])
	i8DHNDhD016361
	for <saag@mit.edu>; Mon, 13 Sep 2004 13:23:14 -0400 (EDT)
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 13 Sep 2004 10:32:01 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
	[171.71.163.14])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8DHN5si013650;
	Mon, 13 Sep 2004 10:23:09 -0700 (PDT)
Received: from [128.107.163.74] (dhcp-128-107-163-74.cisco.com
	[128.107.163.74])	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with ESMTP id AXB39634;	Mon, 13 Sep 2004 10:21:55 -0700 (PDT)
In-Reply-To: <Pine.LNX.4.44.0409091910110.26875-100000@localhost.localdomain>
References: <Pine.LNX.4.44.0409091910110.26875-100000@localhost.localdomain>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <928CDF83-05A9-11D9-9DBB-0003935495EC@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Throwing away bits in a SHA-1 hash
Date: Mon, 13 Sep 2004 10:23:05 -0700
To: Suresh Krishnan <suresh.krishnan@ericsson.ca>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.602094
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 13 Sep 2004 17:23:17 -0000

Suresh,

On Sep 9, 2004, at 4:27 PM, Suresh Krishnan wrote:

> Hi Folks,
>   I am looking to upgrade an algorithm which uses a MD5 hash to 
> produce 2
> random 64 bit numbers. One of these numbers is used as a history
> value for the next iteration. If I use SHA-1 is it possible to throw 
> away
> 32 bits and obtain 2 random 64 bit numbers from the hash? I would
> really appreciate any pointers/suggestions on how to accomplish this
> safely.

it sounds to me like you want to use a pseudorandom function to derive 
secondary keys from a primary secret key.  For this case, you don't 
want to use a collision-resistant hash like SHA1.  Instead, you 
probably want to use HMAC-SHA1.  The references are:

Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing for 
Message Authentication", RFC 2104, February 1997.  
http://www.ietf.org/rfc/rfc2104.txt

Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 
2202, March 1997.  http://www.ietf.org/rfc/rfc2202.txt

Throwing away some of the bits from the output of a pseudorandom 
function is a perfectly good thing to do; it just makes it into a PRF 
with a smaller range.

David

>
> Thanks
> Suresh
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>

From suresh.krishnan@ericsson.com Mon Sep 13 19:08:08 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8DN873a007503
	for <saag@jis.mit.edu>; Mon, 13 Sep 2004 19:08:07 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3])
	i8DN86pC004479
	for <saag@mit.edu>; Mon, 13 Sep 2004 19:08:06 -0400 (EDT)
Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se
	[138.85.133.51])
	by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i8DN6xbj006271;
	Mon, 13 Sep 2004 18:06:59 -0500 (CDT)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service
	(5.5.2657.72)	id <RPQPYCLT>; Mon, 13 Sep 2004 18:06:31 -0500
Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by
	EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service
	Version 5.5.2657.72)	id R8Y2M7FN; Mon, 13 Sep 2004 19:06:53 -0400
Date: Mon, 13 Sep 2004 19:02:07 -0400 (EDT)
From: Suresh Krishnan <suresh.krishnan@ericsson.ca>
X-X-Sender: lmcsukr@localhost.localdomain
To: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Throwing away bits in a SHA-1 hash
In-Reply-To: <928CDF83-05A9-11D9-9DBB-0003935495EC@cisco.com>
Message-ID: <Pine.LNX.4.44.0409131855390.31750-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.590055
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Suresh Krishnan <suresh.krishnan@ericsson.ca>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 13 Sep 2004 23:08:09 -0000

Hi David,
  Thanks for the reply. I am trying to generate a 64 bit IPv6 interface 
identifier from the hash and store the other 64 bits as the random input
for the next iteration. I was wondering if it made any difference which 
bits I threw away (32MSBs,32LSBs  etc). 

Regards
Suresh

On Mon, 13 Sep 2004, David A. McGrew wrote:

>Suresh,
>
>On Sep 9, 2004, at 4:27 PM, Suresh Krishnan wrote:
>
>> Hi Folks,
>>   I am looking to upgrade an algorithm which uses a MD5 hash to 
>> produce 2
>> random 64 bit numbers. One of these numbers is used as a history
>> value for the next iteration. If I use SHA-1 is it possible to throw 
>> away
>> 32 bits and obtain 2 random 64 bit numbers from the hash? I would
>> really appreciate any pointers/suggestions on how to accomplish this
>> safely.
>
>it sounds to me like you want to use a pseudorandom function to derive 
>secondary keys from a primary secret key.  For this case, you don't 
>want to use a collision-resistant hash like SHA1.  Instead, you 
>probably want to use HMAC-SHA1.  The references are:
>
>Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing for 
>Message Authentication", RFC 2104, February 1997.  
>http://www.ietf.org/rfc/rfc2104.txt
>
>Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 
>2202, March 1997.  http://www.ietf.org/rfc/rfc2202.txt
>
>Throwing away some of the bits from the output of a pseudorandom 
>function is a perfectly good thing to do; it just makes it into a PRF 
>with a smaller range.
>
>David
>
>>
>> Thanks
>> Suresh
>> _______________________________________________
>> saag mailing list
>> saag@mit.edu
>> https://jis.mit.edu/mailman/listinfo/saag
>>
>
From suresh.krishnan@ericsson.com Mon Sep 13 19:09:18 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8DN9H3a007575
	for <saag@jis.mit.edu>; Mon, 13 Sep 2004 19:09:17 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3])
	i8DN9Fg7003297
	for <saag@mit.edu>; Mon, 13 Sep 2004 19:09:16 -0400 (EDT)
Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se
	[138.85.133.51])
	by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i8DN9Fbj006728;
	Mon, 13 Sep 2004 18:09:15 -0500 (CDT)
Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service
	(5.5.2657.72)	id <RPQPYCS8>; Mon, 13 Sep 2004 18:08:47 -0500
Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by
	EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service
	Version 5.5.2657.72)	id R8Y2M7FV; Mon, 13 Sep 2004 19:09:10 -0400
Date: Mon, 13 Sep 2004 19:04:23 -0400 (EDT)
From: Suresh Krishnan <suresh.krishnan@ericsson.ca>
X-X-Sender: lmcsukr@localhost.localdomain
To: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] Throwing away bits in a SHA-1 hash
In-Reply-To: <6.1.2.0.2.20040910150142.02e13ec0@mail.binhost.com>
Message-ID: <Pine.LNX.4.44.0409131902520.31750-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.584941
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Suresh Krishnan <suresh.krishnan@ericsson.ca>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 13 Sep 2004 23:09:19 -0000

Hi Russ,
  The specification which is currently using MD5 is RFC3041. It uses MD5 
to generate a hash which is used to create a 64 bit interface identifier. 
Since MD5 is no longer a MUST on IPv6 nodes, does it make sense to keep 
it?

Regards
Suresh

On Fri, 10 Sep 2004, Russ Housley wrote:

>Can you point to the specification that is currently using MD5?  More 
>context is needed.
>
>Russ
>
>At 07:27 PM 9/9/2004, Suresh Krishnan wrote:
>>Hi Folks,
>>   I am looking to upgrade an algorithm which uses a MD5 hash to produce 2
>>random 64 bit numbers. One of these numbers is used as a history
>>value for the next iteration. If I use SHA-1 is it possible to throw away
>>32 bits and obtain 2 random 64 bit numbers from the hash? I would
>>really appreciate any pointers/suggestions on how to accomplish this
>>safely.
>>
>>Thanks
>>Suresh
>>_______________________________________________
>>saag mailing list
>>saag@mit.edu
>>https://jis.mit.edu/mailman/listinfo/saag
>
From mcgrew@cisco.com Mon Sep 13 19:26:39 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8DNQc3a008363
	for <saag@jis.mit.edu>; Mon, 13 Sep 2004 19:26:38 -0400 (EDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86])
	i8DNQag7014910
	for <saag@mit.edu>; Mon, 13 Sep 2004 19:26:37 -0400 (EDT)
Received: from sj-core-4.cisco.com (171.68.223.138)
  by sj-iport-4.cisco.com with ESMTP; 13 Sep 2004 16:28:43 -0700
X-BrightmailFiltered: true
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
	[171.71.163.14])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8DNQULt023640;
	Mon, 13 Sep 2004 16:26:34 -0700 (PDT)
Received: from [128.107.163.74] (dhcp-128-107-163-74.cisco.com
	[128.107.163.74])	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with ESMTP id AXB79018;	Mon, 13 Sep 2004 16:24:05 -0700 (PDT)
In-Reply-To: <Pine.LNX.4.44.0409131855390.31750-100000@localhost.localdomain>
References: <Pine.LNX.4.44.0409131855390.31750-100000@localhost.localdomain>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2B257555-05DC-11D9-9DBB-0003935495EC@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Throwing away bits in a SHA-1 hash
Date: Mon, 13 Sep 2004 16:25:15 -0700
To: Suresh Krishnan <suresh.krishnan@ericsson.ca>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.626801
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 13 Sep 2004 23:26:40 -0000

Suresh,

On Sep 13, 2004, at 4:02 PM, Suresh Krishnan wrote:

> Hi David,
>   Thanks for the reply. I am trying to generate a 64 bit IPv6 interface
> identifier from the hash and store the other 64 bits as the random 
> input
> for the next iteration. I was wondering if it made any difference which
> bits I threw away (32MSBs,32LSBs  etc).

no, it shouldn't make a difference.

As an aside, my comments about using a PRF rather than a collision 
resistant hash function may not apply, since IIUC the random value 
isn't being used as a secret.

David

>
> Regards
> Suresh
>
> On Mon, 13 Sep 2004, David A. McGrew wrote:
>
>> Suresh,
>>
>> On Sep 9, 2004, at 4:27 PM, Suresh Krishnan wrote:
>>
>>> Hi Folks,
>>>   I am looking to upgrade an algorithm which uses a MD5 hash to
>>> produce 2
>>> random 64 bit numbers. One of these numbers is used as a history
>>> value for the next iteration. If I use SHA-1 is it possible to throw
>>> away
>>> 32 bits and obtain 2 random 64 bit numbers from the hash? I would
>>> really appreciate any pointers/suggestions on how to accomplish this
>>> safely.
>>
>> it sounds to me like you want to use a pseudorandom function to derive
>> secondary keys from a primary secret key.  For this case, you don't
>> want to use a collision-resistant hash like SHA1.  Instead, you
>> probably want to use HMAC-SHA1.  The references are:
>>
>> Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing for
>> Message Authentication", RFC 2104, February 1997.
>> http://www.ietf.org/rfc/rfc2104.txt
>>
>> Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC
>> 2202, March 1997.  http://www.ietf.org/rfc/rfc2202.txt
>>
>> Throwing away some of the bits from the output of a pseudorandom
>> function is a perfectly good thing to do; it just makes it into a PRF
>> with a smaller range.
>>
>> David
>>
>>>
>>> Thanks
>>> Suresh
>>> _______________________________________________
>>> saag mailing list
>>> saag@mit.edu
>>> https://jis.mit.edu/mailman/listinfo/saag
>>>
>>
>

From ho@alum.mit.edu Fri Sep 17 18:35:43 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8HMZgPU014894
	for <saag@jis.mit.edu>; Fri, 17 Sep 2004 18:35:42 -0400 (EDT)
Received: from mail.rfburst.com (mail.esmartstart.com [66.119.143.50])
	i8HMZeO0021388
	for <saag@mit.edu>; Fri, 17 Sep 2004 18:35:41 -0400 (EDT)
Received: from localhost.localdomain ([66.119.143.202])
	by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id i8HMZY9T019078
	for <saag@mit.edu>; Fri, 17 Sep 2004 16:35:35 -0600
Received: from localhost.localdomain (tobermory [127.0.0.1])
	by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i8HMXTfm019450
	for <saag@mit.edu>; Fri, 17 Sep 2004 16:33:29 -0600
Received: (from ho@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i8HMXSbS019446;
	Fri, 17 Sep 2004 16:33:28 -0600
Date: Fri, 17 Sep 2004 16:33:28 -0600
Message-Id: <200409172233.i8HMXSbS019446@localhost.localdomain>
From: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
To: saag@mit.edu
X-esmartscan-MailScanner-Information: Please contact the ISP for more
	information
X-esmartscan-MailScanner: Found to be clean
X-esmartscan-MailScanner-SpamCheck: 
X-MailScanner-From: ho@alum.mit.edu
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.567625
Subject: [saag] Algorithm recommendations
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 17 Sep 2004 22:35:44 -0000

I'm trying to develop a framework for making recommendations for
using crypto algorithms, as discussed on this list in past weeks.
The general categories are shaping up as follows, and I'd like
comments on the plan:

1. Algorithm has been shown to have non-trivial flaws, do not
use (do not offer, do not accept).

2. Algorithm has been shown to have non-trivial flaws but is safe
if used carefully.  DO NOT offer, but MAY accept.

3. Algorithm can be broken by brute force in a "short time".  It is
not recommended, but MAY be used if the security considerations
justify it on the basis of a well-contained risk environment and a
need for it (performance, backward compatibility).  Any protocols
using it MUST also have a MUST IMPLEMENT algorithm that is
RECOMMENDED for all uses.  Algorithms in this class must have
an attack resistance of at least 64 bits.

4. Algorithm is RECOMMENDED to protect data in transit, but not for
information that is of high value or related to privacy.  Any
protocols using it MUST also have a MUST IMPLEMENT algorithm that is
RECOMMENDED for all uses.  Algorithms in this class must have an
attack resistance of at least 75 bits.

5. Algorithm is RECOMMENDED.  Things in this class must have an
attack resistance of at least 95 bits.




As an aside, I have a cross-reference of RFC's and crypto algorithms.
It is not completely accurate, but I found it an interesting project.
There about 256 (!) RFC's that mention at least one crypto algorithm,
and most of these are since RFC2000.  The major producers of crypto
RFC's are the usual suspects: TLS, Kerberos, IPsec, PKCS and X.509,
SNMP, DNS, S/MIME, and CMS.  There are indications that the number of
crypto RFC's is declining; perhaps we have maxed out on crypto suites.


Hilarie
From mcgrew@cisco.com Wed Sep 22 09:15:10 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8MDFAPU012585
	for <saag@jis.mit.edu>; Wed, 22 Sep 2004 09:15:10 -0400 (EDT)
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71])
	i8MDF87Q021071
	for <saag@mit.edu>; Wed, 22 Sep 2004 09:15:08 -0400 (EDT)
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 22 Sep 2004 06:17:21 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
	[171.71.163.14])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8MDExwp015435;
	Wed, 22 Sep 2004 06:15:00 -0700 (PDT)
Received: from [10.32.254.210] ([10.32.254.210])
	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with SMTP id AXI78260;
	Wed, 22 Sep 2004 06:15:20 -0700 (PDT)
In-Reply-To: <200409172233.i8HMXSbS019446@localhost.localdomain>
References: <200409172233.i8HMXSbS019446@localhost.localdomain>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <69CA0970-0C99-11D9-BDE1-0003935495EC@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Algorithm recommendations
Date: Wed, 22 Sep 2004 06:15:02 -0700
To: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.689436
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 22 Sep 2004 13:15:11 -0000

Hilarie,

On Sep 17, 2004, at 3:33 PM, The Purple Streak, Hilarie Orman wrote:

> I'm trying to develop a framework for making recommendations for
> using crypto algorithms, as discussed on this list in past weeks.

sounds like an interesting and useful project.

> The general categories are shaping up as follows, and I'd like
> comments on the plan:
>
> 1. Algorithm has been shown to have non-trivial flaws, do not
> use (do not offer, do not accept).
>
> 2. Algorithm has been shown to have non-trivial flaws but is safe
> if used carefully.  DO NOT offer, but MAY accept.
>
> 3. Algorithm can be broken by brute force in a "short time".  It is
> not recommended, but MAY be used if the security considerations
> justify it on the basis of a well-contained risk environment and a
> need for it (performance, backward compatibility).  Any protocols
> using it MUST also have a MUST IMPLEMENT algorithm that is
> RECOMMENDED for all uses.

I agree with the intent here.  I do wonder who will enforce the first 
MUST in the last sentence, though.

> Algorithms in this class must have
> an attack resistance of at least 64 bits.

There is a lot of definition hidden in the phrase "attack resistance".  
  For each algorithm, it will depend on key size, the amount of data 
protected by each key, the size of the authentication tag (for MACs), 
and possibly other parameters.  An example of an "other" parameter is 
the length of the largest message that is authenticated, which impacts 
the security of some MACs.

I have recently been reviewing some of the security results for block 
cipher modes (in the formal, concrete security model) and would like to 
connect these results to recommended parameter choices somehow.  One 
problem with doing this is the fact that some current practices would 
be verboten were we to enforce these results.  Many practitioners would 
regard the formal results as too pessimistic, because in those models, 
there is no distinction between a minor breach of security (e.g. a few 
bits are leaked) and a complete loss of security (e.g. adversary gets 
the secret key).  In practice, implementers and users seem willing to 
tolerate minor breaches.  It would be great if we could reconcile the 
recommendations derived from the theoretical results with actual 
practice somehow.

>
> 4. Algorithm is RECOMMENDED to protect data in transit, but not for
> information that is of high value or related to privacy.  Any
> protocols using it MUST also have a MUST IMPLEMENT algorithm that is
> RECOMMENDED for all uses.  Algorithms in this class must have an
> attack resistance of at least 75 bits.
>
> 5. Algorithm is RECOMMENDED.  Things in this class must have an
> attack resistance of at least 95 bits.

Where did the 75 and 95 come from?  I'm not challenging the choices, 
I'm just wondering how they were derived.

IIRC, the NIST recommendations for key sizes are all multiples of 16, 
but each key size has an expiration date associated with it.  Seems 
like a good way to handle key sizes to me, since those numbers are 
usually multiples of 16 (or at least multiples of 8).  OTOH, key size 
is just one aspect of attack resistance.

>
>
>
>
> As an aside, I have a cross-reference of RFC's and crypto algorithms.
> It is not completely accurate, but I found it an interesting project.
> There about 256 (!) RFC's that mention at least one crypto algorithm,
> and most of these are since RFC2000.  The major producers of crypto
> RFC's are the usual suspects: TLS, Kerberos, IPsec, PKCS and X.509,
> SNMP, DNS, S/MIME, and CMS.  There are indications that the number of
> crypto RFC's is declining; perhaps we have maxed out on crypto suites.

Would you mind posting the RFC/algo list?  I'd be interested to check 
it out, and I bet others would be as well.

thanks,

David

>
>
> Hilarie
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>

From smb@research.att.com Wed Sep 22 09:52:14 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8MDqDPU013626
	for <saag@jis.mit.edu>; Wed, 22 Sep 2004 09:52:13 -0400 (EDT)
Received: from machshav.com (machshav.com [147.28.0.16])
	i8MDqCaH019877
	for <saag@mit.edu>; Wed, 22 Sep 2004 09:52:12 -0400 (EDT)
Received: by machshav.com (Postfix, from userid 512)
	id BBF0CFB27F; Wed, 22 Sep 2004 09:52:11 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP
	id 1033EFB279; Wed, 22 Sep 2004 09:52:11 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id C01A11AE84; Wed, 22 Sep 2004 09:52:09 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Algorithm recommendations 
In-Reply-To: Your message of "Wed, 22 Sep 2004 06:15:02 PDT."
             <69CA0970-0C99-11D9-BDE1-0003935495EC@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 22 Sep 2004 09:52:09 -0400
Message-Id: <20040922135209.C01A11AE84@berkshire.research.att.com>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.682841
cc: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 22 Sep 2004 13:52:15 -0000

In message <69CA0970-0C99-11D9-BDE1-0003935495EC@cisco.com>, "David A. McGrew" 
writes:
>Hilarie,
>
>On Sep 17, 2004, at 3:33 PM, The Purple Streak, Hilarie Orman wrote:
>
>> I'm trying to develop a framework for making recommendations for
>> using crypto algorithms, as discussed on this list in past weeks.
>
>sounds like an interesting and useful project.
>
>> The general categories are shaping up as follows, and I'd like
>> comments on the plan:
>>
>> 1. Algorithm has been shown to have non-trivial flaws, do not
>> use (do not offer, do not accept).
>>
>> 2. Algorithm has been shown to have non-trivial flaws but is safe
>> if used carefully.  DO NOT offer, but MAY accept.
>>
>> 3. Algorithm can be broken by brute force in a "short time".  It is
>> not recommended, but MAY be used if the security considerations
>> justify it on the basis of a well-contained risk environment and a
>> need for it (performance, backward compatibility).  Any protocols
>> using it MUST also have a MUST IMPLEMENT algorithm that is
>> RECOMMENDED for all uses.
>
>I agree with the intent here.  I do wonder who will enforce the first 
>MUST in the last sentence, though.

The IESG enforces it -- we won't approve a document that fails that 
test.  Note carefully the distinction between "must implement" and 
"must use".  (Also note that the IESG has no control over what people 
actually build; all we can do is say "this is our best professional 
judgment and if you want to be RFC-compliant here's what you have to 
do.")
>
>> Algorithms in this class must have
>> an attack resistance of at least 64 bits.
>
>There is a lot of definition hidden in the phrase "attack resistance".  
>  For each algorithm, it will depend on key size, the amount of data 
>protected by each key, the size of the authentication tag (for MACs), 
>and possibly other parameters.  An example of an "other" parameter is 
>the length of the largest message that is authenticated, which impacts 
>the security of some MACs.
>
>I have recently been reviewing some of the security results for block 
>cipher modes (in the formal, concrete security model) and would like to 
>connect these results to recommended parameter choices somehow.  One 
>problem with doing this is the fact that some current practices would 
>be verboten were we to enforce these results.  Many practitioners would 
>regard the formal results as too pessimistic, because in those models, 
>there is no distinction between a minor breach of security (e.g. a few 
>bits are leaked) and a complete loss of security (e.g. adversary gets 
>the secret key).  In practice, implementers and users seem willing to 
>tolerate minor breaches.  It would be great if we could reconcile the 
>recommendations derived from the theoretical results with actual 
>practice somehow.
>
I'd love to see that analysis published.  As for use of such things 
within the IETF -- security is always a judgment call, trading off 
engineering and economic reality against the need for confidentiality/
integrity/availability.  Often, the right answer for IETF purposes is 
to document the limitations of the chosen scheme in the Security 
Considerations section. of the RFC.

		--Steve Bellovin, http://www.research.att.com/~smb


From jwkckid1@ix.netcom.com Wed Sep 22 23:42:43 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8N3ggPU006746
	for <saag@jis.mit.edu>; Wed, 22 Sep 2004 23:42:42 -0400 (EDT)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net
	[207.69.200.246])i8N3gfha020582
	for <saag@mit.edu>; Wed, 22 Sep 2004 23:42:41 -0400 (EDT)
Received: from 1cust46.tnt36.dfw9.da.uu.net ([67.234.81.46]
	helo=ix.netcom.com)
	by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1)
	id 1CAKVA-0003fS-00; Wed, 22 Sep 2004 23:42:36 -0400
Message-ID: <4152616B.6526AD6B@ix.netcom.com>
Date: Wed, 22 Sep 2004 22:38:53 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: "Steven M. Bellovin" <smb@research.att.com>
Subject: Re: [saag] Algorithm recommendations
References: <20040922135209.C01A11AE84@berkshire.research.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.721232
cc: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 23 Sep 2004 03:42:44 -0000

Steven and all,

  Let's not forget that RFC's are not standards, but "Requests for Comments".
Hence when any RFC has a "Must" clause in it not complying is hardly
a serious consideration...

Steven M. Bellovin wrote:

> In message <69CA0970-0C99-11D9-BDE1-0003935495EC@cisco.com>, "David A. McGrew"
> writes:
> >Hilarie,
> >
> >On Sep 17, 2004, at 3:33 PM, The Purple Streak, Hilarie Orman wrote:
> >
> >> I'm trying to develop a framework for making recommendations for
> >> using crypto algorithms, as discussed on this list in past weeks.
> >
> >sounds like an interesting and useful project.
> >
> >> The general categories are shaping up as follows, and I'd like
> >> comments on the plan:
> >>
> >> 1. Algorithm has been shown to have non-trivial flaws, do not
> >> use (do not offer, do not accept).
> >>
> >> 2. Algorithm has been shown to have non-trivial flaws but is safe
> >> if used carefully.  DO NOT offer, but MAY accept.
> >>
> >> 3. Algorithm can be broken by brute force in a "short time".  It is
> >> not recommended, but MAY be used if the security considerations
> >> justify it on the basis of a well-contained risk environment and a
> >> need for it (performance, backward compatibility).  Any protocols
> >> using it MUST also have a MUST IMPLEMENT algorithm that is
> >> RECOMMENDED for all uses.
> >
> >I agree with the intent here.  I do wonder who will enforce the first
> >MUST in the last sentence, though.
>
> The IESG enforces it -- we won't approve a document that fails that
> test.  Note carefully the distinction between "must implement" and
> "must use".  (Also note that the IESG has no control over what people
> actually build; all we can do is say "this is our best professional
> judgment and if you want to be RFC-compliant here's what you have to
> do.")
> >
> >> Algorithms in this class must have
> >> an attack resistance of at least 64 bits.
> >
> >There is a lot of definition hidden in the phrase "attack resistance".
> >  For each algorithm, it will depend on key size, the amount of data
> >protected by each key, the size of the authentication tag (for MACs),
> >and possibly other parameters.  An example of an "other" parameter is
> >the length of the largest message that is authenticated, which impacts
> >the security of some MACs.
> >
> >I have recently been reviewing some of the security results for block
> >cipher modes (in the formal, concrete security model) and would like to
> >connect these results to recommended parameter choices somehow.  One
> >problem with doing this is the fact that some current practices would
> >be verboten were we to enforce these results.  Many practitioners would
> >regard the formal results as too pessimistic, because in those models,
> >there is no distinction between a minor breach of security (e.g. a few
> >bits are leaked) and a complete loss of security (e.g. adversary gets
> >the secret key).  In practice, implementers and users seem willing to
> >tolerate minor breaches.  It would be great if we could reconcile the
> >recommendations derived from the theoretical results with actual
> >practice somehow.
> >
> I'd love to see that analysis published.  As for use of such things
> within the IETF -- security is always a judgment call, trading off
> engineering and economic reality against the need for confidentiality/
> integrity/availability.  Often, the right answer for IETF purposes is
> to document the limitations of the chosen scheme in the Security
> Considerations section. of the RFC.
>
>                 --Steve Bellovin, http://www.research.att.com/~smb
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From kent@bbn.com Thu Sep 23 08:06:49 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8NC6nPU021367
	for <saag@jis.mit.edu>; Thu, 23 Sep 2004 08:06:49 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i8NC6kfW015493
	for <saag@mit.edu>; Thu, 23 Sep 2004 08:06:47 -0400 (EDT)
Received: from [10.84.131.128] (ramblo.bbn.com [128.33.0.51])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i8NC6ijf013879;
	Thu, 23 Sep 2004 08:06:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06110400bd786bd781f8@[10.84.131.128]>
In-Reply-To: <4152616B.6526AD6B@ix.netcom.com>
References: <20040922135209.C01A11AE84@berkshire.research.att.com>
 <4152616B.6526AD6B@ix.netcom.com>
Date: Thu, 23 Sep 2004 08:05:28 -0400
To: Jeff Williams <jwkckid1@ix.netcom.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] Algorithm recommendations
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.42
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.543989
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 23 Sep 2004 12:06:50 -0000

At 10:38 PM -0700 9/22/04, Jeff Williams wrote:
>Steven and all,
>
>   Let's not forget that RFC's are not standards, but "Requests for Comments".
>Hence when any RFC has a "Must" clause in it not complying is hardly
>a serious consideration...

CCITT documents were titled "recommendations" but were really de jure 
standards.

Not RFCs are standards, but many, maybe most are, and are so 
identified via the status  portion of the RFC header.

Steve

From hugo@ee.technion.ac.il Thu Sep 23 12:15:41 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8NGFePU014332
	for <saag@jis.mit.edu>; Thu, 23 Sep 2004 12:15:40 -0400 (EDT)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6])
	i8NGFcT0004867
	for <saag@mit.edu>; Thu, 23 Sep 2004 12:15:38 -0400 (EDT)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com
	[129.34.20.41])i8NGCZe138012;	Thu, 23 Sep 2004 12:12:36 -0400
Received: from e54.watson.ibm.com (localhost [127.0.0.1])
	(8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i8NGCrW53076;
	Thu, 23 Sep 2004 12:12:53 -0400
Received: from localhost (hugo@localhost)i8NGCnX29378;
	Thu, 23 Sep 2004 12:12:49 -0400
X-Authentication-Warning: e54.watson.ibm.com: hugo owned process doing -bs
Date: Thu, 23 Sep 2004 12:12:49 -0400 (EDT)
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
X-X-Sender: <hugo@e54.watson.ibm.com>
To: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Algorithm recommendations
In-Reply-To: <69CA0970-0C99-11D9-BDE1-0003935495EC@cisco.com>
Message-ID: <Pine.LNX.4.33.0409231211480.29367-100000@e54.watson.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.754560
X-Mailman-Approved-At: Thu, 23 Sep 2004 17:10:06 -0400
cc: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 23 Sep 2004 16:15:42 -0000

I would also recommend moving (or at least cc-ing) this thread to
the cfrg list.

Hugo

On Wed, 22 Sep 2004, David A. McGrew wrote:

> Hilarie,
> 
> On Sep 17, 2004, at 3:33 PM, The Purple Streak, Hilarie Orman wrote:
> 
> > I'm trying to develop a framework for making recommendations for
> > using crypto algorithms, as discussed on this list in past weeks.
> 
> sounds like an interesting and useful project.
> 
> > The general categories are shaping up as follows, and I'd like
> > comments on the plan:
> >
> > 1. Algorithm has been shown to have non-trivial flaws, do not
> > use (do not offer, do not accept).
> >
> > 2. Algorithm has been shown to have non-trivial flaws but is safe
> > if used carefully.  DO NOT offer, but MAY accept.
> >
> > 3. Algorithm can be broken by brute force in a "short time".  It is
> > not recommended, but MAY be used if the security considerations
> > justify it on the basis of a well-contained risk environment and a
> > need for it (performance, backward compatibility).  Any protocols
> > using it MUST also have a MUST IMPLEMENT algorithm that is
> > RECOMMENDED for all uses.
> 
> I agree with the intent here.  I do wonder who will enforce the first 
> MUST in the last sentence, though.
> 
> > Algorithms in this class must have
> > an attack resistance of at least 64 bits.
> 
> There is a lot of definition hidden in the phrase "attack resistance".  
>   For each algorithm, it will depend on key size, the amount of data 
> protected by each key, the size of the authentication tag (for MACs), 
> and possibly other parameters.  An example of an "other" parameter is 
> the length of the largest message that is authenticated, which impacts 
> the security of some MACs.
> 
> I have recently been reviewing some of the security results for block 
> cipher modes (in the formal, concrete security model) and would like to 
> connect these results to recommended parameter choices somehow.  One 
> problem with doing this is the fact that some current practices would 
> be verboten were we to enforce these results.  Many practitioners would 
> regard the formal results as too pessimistic, because in those models, 
> there is no distinction between a minor breach of security (e.g. a few 
> bits are leaked) and a complete loss of security (e.g. adversary gets 
> the secret key).  In practice, implementers and users seem willing to 
> tolerate minor breaches.  It would be great if we could reconcile the 
> recommendations derived from the theoretical results with actual 
> practice somehow.
> 
> >
> > 4. Algorithm is RECOMMENDED to protect data in transit, but not for
> > information that is of high value or related to privacy.  Any
> > protocols using it MUST also have a MUST IMPLEMENT algorithm that is
> > RECOMMENDED for all uses.  Algorithms in this class must have an
> > attack resistance of at least 75 bits.
> >
> > 5. Algorithm is RECOMMENDED.  Things in this class must have an
> > attack resistance of at least 95 bits.
> 
> Where did the 75 and 95 come from?  I'm not challenging the choices, 
> I'm just wondering how they were derived.
> 
> IIRC, the NIST recommendations for key sizes are all multiples of 16, 
> but each key size has an expiration date associated with it.  Seems 
> like a good way to handle key sizes to me, since those numbers are 
> usually multiples of 16 (or at least multiples of 8).  OTOH, key size 
> is just one aspect of attack resistance.
> 
> >
> >
> >
> >
> > As an aside, I have a cross-reference of RFC's and crypto algorithms.
> > It is not completely accurate, but I found it an interesting project.
> > There about 256 (!) RFC's that mention at least one crypto algorithm,
> > and most of these are since RFC2000.  The major producers of crypto
> > RFC's are the usual suspects: TLS, Kerberos, IPsec, PKCS and X.509,
> > SNMP, DNS, S/MIME, and CMS.  There are indications that the number of
> > crypto RFC's is declining; perhaps we have maxed out on crypto suites.
> 
> Would you mind posting the RFC/algo list?  I'd be interested to check 
> it out, and I bet others would be as well.
> 
> thanks,
> 
> David
> 
> >
> >
> > Hilarie
> > _______________________________________________
> > saag mailing list
> > saag@mit.edu
> > https://jis.mit.edu/mailman/listinfo/saag
> >
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 

-- 


From jwkckid1@ix.netcom.com Fri Sep 24 01:35:31 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8O5ZUPU008612
	for <saag@jis.mit.edu>; Fri, 24 Sep 2004 01:35:30 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net
	[207.69.200.148])i8O5ZTLN018572
	for <saag@mit.edu>; Fri, 24 Sep 2004 01:35:29 -0400 (EDT)
Received: from 1cust243.tnt36.dfw9.da.uu.net ([67.234.81.243]
	helo=ix.netcom.com)
	by granger.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1CAijl-0000Ei-00; Fri, 24 Sep 2004 01:35:18 -0400
Message-ID: <4153CD52.4136A138@ix.netcom.com>
Date: Fri, 24 Sep 2004 00:31:34 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] Algorithm recommendations
References: <20040922135209.C01A11AE84@berkshire.research.att.com>
	<p06110400bd786bd781f8@[10.84.131.128]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.584043
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 24 Sep 2004 05:35:32 -0000

Stephen and all,

Stephen Kent wrote:

> At 10:38 PM -0700 9/22/04, Jeff Williams wrote:
> >Steven and all,
> >
> >   Let's not forget that RFC's are not standards, but "Requests for Comments".
> >Hence when any RFC has a "Must" clause in it not complying is hardly
> >a serious consideration...
>
> CCITT documents were titled "recommendations" but were really de jure
> standards.

  De jure?  Hummm?  Well I am very sure that de jure is not adequate
for the commercial world to take seriously to any great degree as
being a serious decision making factor.

>
>
> Not RFCs are standards, but many, maybe most are, and are so
> identified via the status  portion of the RFC header.

  No few are..

>
>
> Steve

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From pbaker@verisign.com Fri Sep 24 14:35:53 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8OIZqPU029971
	for <saag@jis.mit.edu>; Fri, 24 Sep 2004 14:35:52 -0400 (EDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	i8OIZpvT000972
	for <saag@mit.edu>; Fri, 24 Sep 2004 14:35:51 -0400 (EDT)
Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com
	[65.205.251.33])
	by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i8OIZh3M017543;
	Fri, 24 Sep 2004 11:35:43 -0700 (PDT)
Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <SRGB4ZR7>; Fri, 24 Sep 2004 11:35:43 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEBF5@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Stephen Kent'" <kent@bbn.com>, Jeff Williams <jwkckid1@ix.netcom.com>
Subject: RE: [saag] Algorithm recommendations
Date: Fri, 24 Sep 2004 11:35:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.572082
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 24 Sep 2004 18:35:54 -0000

Before we get too far into this, by the time NEWTRK has finished
there might actually be a meaningful standards designation.



> At 10:38 PM -0700 9/22/04, Jeff Williams wrote:
> >Steven and all,
> >
> >   Let's not forget that RFC's are not standards, but 
> "Requests for Comments".
> >Hence when any RFC has a "Must" clause in it not complying is hardly
> >a serious consideration...
> 
> CCITT documents were titled "recommendations" but were really de jure 
> standards.
> 
> Not RFCs are standards, but many, maybe most are, and are so 
> identified via the status  portion of the RFC header.
> 
> Steve
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 
From pbaker@verisign.com Fri Sep 24 14:35:57 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8OIZoPU029969
	for <saag@jis.mit.edu>; Fri, 24 Sep 2004 14:35:55 -0400 (EDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	i8OIZmkn025235
	for <saag@mit.edu>; Fri, 24 Sep 2004 14:35:48 -0400 (EDT)
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com
	[65.205.251.55])
	by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i8OIXrLg017423;
	Fri, 24 Sep 2004 11:33:54 -0700 (PDT)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <SRF9S96J>; Fri, 24 Sep 2004 11:33:53 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEBF4@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Steven M. Bellovin'" <smb@research.att.com>,
   "David A. McGrew"
	 <mcgrew@cisco.com>
Subject: RE: [saag] Algorithm recommendations 
Date: Fri, 24 Sep 2004 11:33:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 1.792172
cc: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 24 Sep 2004 18:35:58 -0000


> One problem with doing this is the fact that some current 
> practices would be verboten were we to enforce these results.   

This is why I think that it is very important to differentiate
between ideal practice and acceptable practice.

I would not want to see a new spec go forward that used MD5 for
any purpose. But that does not mean that we should make HTTP
digest authentication obsolete or that we would provide a 
security benefit in doing so. If you analyze the specific 
security requirements the system is acceptably secure.



From mcgrew@cisco.com Fri Sep 24 15:23:12 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8OJNCPU001540
	for <saag@jis.mit.edu>; Fri, 24 Sep 2004 15:23:12 -0400 (EDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87])
	i8OJN9kn003713
	for <saag@mit.edu>; Fri, 24 Sep 2004 15:23:10 -0400 (EDT)
Received: from sj-core-3.cisco.com (171.68.223.137)
  by sj-iport-5.cisco.com with ESMTP; 24 Sep 2004 12:23:30 -0700
X-BrightmailFiltered: true
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
	[171.71.163.14])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8OJN63c010434;
	Fri, 24 Sep 2004 12:23:07 -0700 (PDT)
Received: from [10.32.254.210] ([10.32.254.210])
	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with SMTP id AXL16446;
	Fri, 24 Sep 2004 12:23:41 -0700 (PDT)
In-Reply-To: <20040922135209.C01A11AE84@berkshire.research.att.com>
References: <20040922135209.C01A11AE84@berkshire.research.att.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2789DFE8-0E5F-11D9-BAD2-0003935495EC@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Algorithm recommendations 
Date: Fri, 24 Sep 2004 12:23:03 -0700
To: "Steven M. Bellovin" <smb@research.att.com>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.710068
cc: "'cfrg@ietf.org'" <cfrg@ietf.org>
cc: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
cc: "'saag@mit.edu'" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 24 Sep 2004 19:23:13 -0000

Steve,

On Sep 22, 2004, at 6:52 AM, Steven M. Bellovin wrote:

> In message <69CA0970-0C99-11D9-BDE1-0003935495EC@cisco.com>, "David A. 
> McGrew"
> writes:
>> Hilarie,
>>
>> On Sep 17, 2004, at 3:33 PM, The Purple Streak, Hilarie Orman wrote:
>>
>>> I'm trying to develop a framework for making recommendations for
>>> using crypto algorithms, as discussed on this list in past weeks.
>>
>> sounds like an interesting and useful project.
>>
>>> The general categories are shaping up as follows, and I'd like
>>> comments on the plan:
>>>
>>> 1. Algorithm has been shown to have non-trivial flaws, do not
>>> use (do not offer, do not accept).
>>>
>>> 2. Algorithm has been shown to have non-trivial flaws but is safe
>>> if used carefully.  DO NOT offer, but MAY accept.
>>>
>>> 3. Algorithm can be broken by brute force in a "short time".  It is
>>> not recommended, but MAY be used if the security considerations
>>> justify it on the basis of a well-contained risk environment and a
>>> need for it (performance, backward compatibility).  Any protocols
>>> using it MUST also have a MUST IMPLEMENT algorithm that is
>>> RECOMMENDED for all uses.
>>
>> I agree with the intent here.  I do wonder who will enforce the first
>> MUST in the last sentence, though.
>
> The IESG enforces it -- we won't approve a document that fails that
> test.  Note carefully the distinction between "must implement" and
> "must use".  (Also note that the IESG has no control over what people
> actually build; all we can do is say "this is our best professional
> judgment and if you want to be RFC-compliant here's what you have to
> do.")

good, this sounds like the right process.  What I was wondering about 
is the question of what happens to existing RFCs that contain Category 
3 algorithms but do not meet the requirement of having a MUST IMPLEMENT 
Category 1 algorithm.  This question is something of a nit, but it 
probably ought to be addressed.  There will be RFCs that fall into this 
category (I think; Hilarie is the one who did the study of RFCs, so she 
will know), and it would be good to clear up what their status is in 
the text.

>>
>>> Algorithms in this class must have
>>> an attack resistance of at least 64 bits.
>>
>> There is a lot of definition hidden in the phrase "attack resistance".
>>  For each algorithm, it will depend on key size, the amount of data
>> protected by each key, the size of the authentication tag (for MACs),
>> and possibly other parameters.  An example of an "other" parameter is
>> the length of the largest message that is authenticated, which impacts
>> the security of some MACs.
>>
>> I have recently been reviewing some of the security results for block
>> cipher modes (in the formal, concrete security model) and would like 
>> to
>> connect these results to recommended parameter choices somehow.  One
>> problem with doing this is the fact that some current practices would
>> be verboten were we to enforce these results.  Many practitioners 
>> would
>> regard the formal results as too pessimistic, because in those models,
>> there is no distinction between a minor breach of security (e.g. a few
>> bits are leaked) and a complete loss of security (e.g. adversary gets
>> the secret key).  In practice, implementers and users seem willing to
>> tolerate minor breaches.  It would be great if we could reconcile the
>> recommendations derived from the theoretical results with actual
>> practice somehow.
>>
> I'd love to see that analysis published.  As for use of such things
> within the IETF -- security is always a judgment call, trading off
> engineering and economic reality against the need for confidentiality/
> integrity/availability.  Often, the right answer for IETF purposes is
> to document the limitations of the chosen scheme in the Security
> Considerations section. of the RFC.

Thanks for your encouragement here.  I do not have anything that is 
written up well enough to contribute publicly; not yet anyway.  As Hugo 
suggested, it is probably a good topic for CFRG as well.

David

>
> 		--Steve Bellovin, http://www.research.att.com/~smb
>
>

From kent@bbn.com Fri Sep 24 15:34:20 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8OJYKPU001846
	for <saag@jis.mit.edu>; Fri, 24 Sep 2004 15:34:20 -0400 (EDT)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	i8OJRHvT013515
	for <saag@mit.edu>; Fri, 24 Sep 2004 15:27:17 -0400 (EDT)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i8OJREjf000541;
	Fri, 24 Sep 2004 15:27:15 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06110401bd79e014ac34@[128.89.89.75]>
In-Reply-To: <4153CD52.4136A138@ix.netcom.com>
References: <20040922135209.C01A11AE84@berkshire.research.att.com>	
 <4152616B.6526AD6B@ix.netcom.com> <p06110400bd786bd781f8@[10.84.131.128]>
 <4153CD52.4136A138@ix.netcom.com>
Date: Fri, 24 Sep 2004 10:33:08 -0400
To: Jeff Williams <jwkckid1@ix.netcom.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [saag] Algorithm recommendations
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.42
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000007
Spam-Alum-Time: 0.518896
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 24 Sep 2004 19:34:21 -0000

Jeff,

Whoops.  My mistake. For a moment I forgot with whom I was 
communicating. I'll just update my e-mail  kill filter and move on.

Steve
From ho@alum.mit.edu Fri Sep 24 15:53:13 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8OJrCPU002382
	for <saag@jis.mit.edu>; Fri, 24 Sep 2004 15:53:12 -0400 (EDT)
Received: from mail.rfburst.com (mail.esmartstart.com [66.119.143.50])
	i8OJrBvT004962
	for <saag@mit.edu>; Fri, 24 Sep 2004 15:53:11 -0400 (EDT)
Received: from localhost.localdomain ([66.119.143.202])
	by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id i8OJr5RL013545
	for <saag@mit.edu>; Fri, 24 Sep 2004 13:53:05 -0600
Received: from localhost.localdomain (tobermory [127.0.0.1])
	by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i8OJtPfm011389
	for <saag@mit.edu>; Fri, 24 Sep 2004 13:55:27 -0600
Received: (from ho@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i8OJtPJC011385;
	Fri, 24 Sep 2004 13:55:25 -0600
Date: Fri, 24 Sep 2004 13:55:25 -0600
Message-Id: <200409241955.i8OJtPJC011385@localhost.localdomain>
From: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
To: saag@mit.edu
In-reply-to: Yourmessage
	<C6DDA43B91BFDA49AA2F1E473732113E010BEBF4@mou1wnexm05.vcorp.ad.vrsn.com>
X-esmartscan-MailScanner-Information: Please contact the ISP for more
	information
X-esmartscan-MailScanner: Found to be clean
X-esmartscan-MailScanner-SpamCheck: 
X-MailScanner-From: ho@alum.mit.edu
Subject: RE: [saag] Algorithm recommendations
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.587970
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 24 Sep 2004 19:53:13 -0000

While it may be OK to use MD5 for backwards compatibility, I think
we've got a real problem with it.  Its second pre-image resistance is
lower than previously realized, and I believe its level of resistance
would not be considered acceptable for any alternative algorithm.  So,
it falls into the class of "acceptable for some purposes (HMAC,
non-security-critical digest or random number) if you are already
using it", but it should not be used for anything new.

Hilarie

>  From: "Hallam-Baker, Phillip" <pbaker@verisign.com>

>  > One problem with doing this is the fact that some current 
>  > practices would be verboten were we to enforce these results.   

>  This is why I think that it is very important to differentiate
>  between ideal practice and acceptable practice.

>  I would not want to see a new spec go forward that used MD5 for
>  any purpose. But that does not mean that we should make HTTP
>  digest authentication obsolete or that we would provide a 
>  security benefit in doing so. If you analyze the specific 
>  security requirements the system is acceptably secure.


From smb@research.att.com Fri Sep 24 16:15:50 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8OKFnPU003061
	for <saag@jis.mit.edu>; Fri, 24 Sep 2004 16:15:49 -0400 (EDT)
Received: from machshav.com (machshav.com [147.28.0.16])
	i8OKFlkn012933
	for <saag@mit.edu>; Fri, 24 Sep 2004 16:15:48 -0400 (EDT)
Received: by machshav.com (Postfix, from userid 512)
	id 3051BFB252; Fri, 24 Sep 2004 16:15:47 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP
	id 7EAA3FB24A; Fri, 24 Sep 2004 16:15:46 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 4244F1AE88; Fri, 24 Sep 2004 16:15:45 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [saag] Algorithm recommendations 
In-Reply-To: Your message of "Fri, 24 Sep 2004 12:23:03 PDT."
             <2789DFE8-0E5F-11D9-BAD2-0003935495EC@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Sep 2004 16:15:45 -0400
Message-Id: <20040924201545.4244F1AE88@berkshire.research.att.com>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.619151
cc: "'cfrg@ietf.org'" <cfrg@ietf.org>
cc: "The Purple Streak,     Hilarie Orman" <ho@alum.mit.edu>
cc: "'saag@mit.edu'" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 24 Sep 2004 20:15:50 -0000

In message <2789DFE8-0E5F-11D9-BAD2-0003935495EC@cisco.com>, "David A. McGrew" 
writes:

>>> I agree with the intent here.  I do wonder who will enforce the first
>>> MUST in the last sentence, though.
>>
>> The IESG enforces it -- we won't approve a document that fails that
>> test.  Note carefully the distinction between "must implement" and
>> "must use".  (Also note that the IESG has no control over what people
>> actually build; all we can do is say "this is our best professional
>> judgment and if you want to be RFC-compliant here's what you have to
>> do.")
>
>good, this sounds like the right process.  What I was wondering about 
>is the question of what happens to existing RFCs that contain Category 
>3 algorithms but do not meet the requirement of having a MUST IMPLEMENT 
>Category 1 algorithm.  This question is something of a nit, but it 
>probably ought to be addressed.  There will be RFCs that fall into this 
>category (I think; Hilarie is the one who did the study of RFCs, so she 
>will know), and it would be good to clear up what their status is in 
>the text.
>
Just as a matter of process, amending an old standards-track RFC's
requirements would require a new RFC.  As a matter of practice, we're 
not likely to suddenly reclassify such protocols as "Historic", but if 
there are crucial weaknesses the IESG would likely try to get a 
revision or a supplement done fairly promptly.

Let's get the data first; we can then look at things, one protocol at a 
time, and figure out what to do.  (To simplify things in terms of 
process, the current philosophy is that crypto algorithms should be in 
a separate RFC that can be changed more easily than, and independent 
of, the base spec.  In most cases, that's what would be done for any 
revisions necessitated by this work.)

		--Steve Bellovin, http://www.research.att.com/~smb


From jwkckid1@ix.netcom.com Fri Sep 24 23:38:40 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8P3cdPU015090
	for <saag@jis.mit.edu>; Fri, 24 Sep 2004 23:38:39 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net
	[207.69.200.148])i8P3cbu3024016
	for <saag@mit.edu>; Fri, 24 Sep 2004 23:38:38 -0400 (EDT)
Received: from 1cust206.tnt36.dfw9.da.uu.net ([67.234.81.206]
	helo=ix.netcom.com)
	by granger.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1CB3OI-0001Zu-00; Fri, 24 Sep 2004 23:38:31 -0400
Message-ID: <4155036F.EB7965AA@ix.netcom.com>
Date: Fri, 24 Sep 2004 22:34:44 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: Re: [saag] Algorithm recommendations
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEBF5@mou1wnexm05.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.592330
cc: 'Stephen Kent' <kent@bbn.com>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 25 Sep 2004 03:38:40 -0000

Phillip and all,

  This would be a good idea and very long overdue yet suggested some
6 years ago now to the IESG.  However the debates on what the criterion
for such meaningful and measured consensus based method were
inconclusive as I recall..  However I don't recall Stephen ever
participating
in those debates or discussions...

Hallam-Baker, Phillip wrote:

> Before we get too far into this, by the time NEWTRK has finished
> there might actually be a meaningful standards designation.
>
> > At 10:38 PM -0700 9/22/04, Jeff Williams wrote:
> > >Steven and all,
> > >
> > >   Let's not forget that RFC's are not standards, but
> > "Requests for Comments".
> > >Hence when any RFC has a "Must" clause in it not complying is hardly
> > >a serious consideration...
> >
> > CCITT documents were titled "recommendations" but were really de jure
> > standards.
> >
> > Not RFCs are standards, but many, maybe most are, and are so
> > identified via the status  portion of the RFC header.
> >
> > Steve
> >
> > _______________________________________________
> > saag mailing list
> > saag@mit.edu
> > https://jis.mit.edu/mailman/listinfo/saag
> >

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From jis@MIT.EDU Sat Sep 25 01:25:36 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8P5PZPU018377
	for <saag@jis.mit.edu>; Sat, 25 Sep 2004 01:25:35 -0400 (EDT)
Received: from jis.tzo.com (JISVPN.MIT.EDU [18.100.101.102])
	i8P5PXkJ010722
	for <saag@mit.edu>; Sat, 25 Sep 2004 01:25:34 -0400 (EDT)
Received: (from jis@localhost)
	by jis.tzo.com (8.12.8p2/8.12.8) id i8P5PVrm029367
	for saag@mit.edu; Sat, 25 Sep 2004 01:25:31 -0400
X-Authentication-Warning: jis.tzo.com: jis set sender to jis@mit.edu using -f
Date: Sat, 25 Sep 2004 01:25:31 -0400
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: saag@mit.edu
Message-ID: <20040925012531.B28572@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
Spam-Alum-Prob: 0.000000
Spam-Alum-Prob: 0.000053
Spam-Alum-Time: 0.545796
Spam-Alum-Time: 1.861621
X-Scanned-By: MIMEDefang 2.42
Subject: [saag] Lost (and found) Mail
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 25 Sep 2004 05:25:36 -0000

Around the end of August/Early September a transient disk full on
jis.mit.edu (which handles saag@mit.edu) resulted in some messages to
the saag list being "stuck" in mailman. These were messages that were
held for moderation for some reason or other.

I am about to re-send these messages to the list. Some are on threads
that are still active, so be wary of the message timestamps when you
see these, to avoid re-hashing settled issues.

Within a few months, the mailing list will move to a new server (just
set up today) which will have more then enough disk space (not to
mention cpu and memory) so we shouldn't have a repeat of this problem.

			-Jeff
From bill@strahm.net Thu Aug 26 03:42:17 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7Q7gG3a017636
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 03:42:16 -0400 (EDT)
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56])
	i7Q7gFRu003067
	for <saag@mit.edu>; Thu, 26 Aug 2004 03:42:15 -0400 (EDT)
Received: from mobilebill (c-24-6-192-177.client.comcast.net[24.6.192.177])
	by comcast.net (sccrmhc12) with SMTP
	id <2004082607421401200p1vb6e>; Thu, 26 Aug 2004 07:42:15 +0000
From: "bill" <bill@strahm.net>
To: "'Paul Hoffman / VPNC'" <paul.hoffman@vpnc.org>, <cfrg@ietf.org>,
	<saag@mit.edu>
Subject: RE: [Cfrg] RE: [saag] Cryptography Algorithm Choice
Message-ID: <000001c48b40$28e23e20$1e02a8c0@mobilebill>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <p0611046bbd515aec9f1c@[10.20.30.249]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Length: 3992
Lines: 103
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Sat, 25 Sep 2004 05:38:28 -0000
X-Original-Date: Thu, 26 Aug 2004 00:41:49 -0700
X-List-Received-Date: Sat, 25 Sep 2004 05:38:28 -0000

As I recall - Win2K was roundly blasted by critics for falling back to
DES when it tried to connect to a machine that would only enable DES
(Export version)

I know for a FACT that I tested DES IPsec in interoperation at the VPN
interop in 1999.

These things aren't that old (I saw the NIC that I worked on at Fry's
tonight when I was there) so I guess you have your evidence now Paul

Bill

> -----Original Message-----
> From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On 
> Behalf Of Paul Hoffman / VPNC
> Sent: Tuesday, August 24, 2004 2:10 PM
> To: cfrg@ietf.org; saag@mit.edu
> Subject: [Cfrg] RE: [saag] Cryptography Algorithm Choice
> 
> 
> At 1:47 PM -0700 8/24/04, Hallam-Baker, Phillip wrote:
> >  > Is there any evidence for that statement? Almost no vendors 
> > currently
> >>  ship VPNs with the default settings of DES. VPNC has never tested 
> >> DES  conformance or interoperability, and we have never 
> had a single 
> >> VPN  user ask us to do so (or ask us why we didn't). No 
> VPNC member 
> >> has  told me that they any customer demands for DES.
> >
> >Paul, there are many VPN vendors that do not use IPSEC or for that 
> >matter SSL.
> 
> Of course.
> 
> >DES VPNs really do exist, hopefully they are fading away but I would 
> >not bet on it having been completed :-(
> 
> Sorry, but it's hard to take that on faith without seeing any 
> evidence of it. And, yes, this is relevant to the discussion at hand 
> because this group might act differently if we believe that weak 
> encryption is commonly used in IETF-created protocols.
> 
> And, although I have no hard facts, when I spoke to link-layer 
> encryption vendors 18 months ago, they all said the same thing: there 
> was essentially no current market for DES or anything with keys less 
> than 112 bits of effective strength for anything called a VPN.
> 
> >Put it this way there are plenty of 40 bit SSL browsers 
> arround and I 
> >am not aware of anyone ever having broken the crypto to actually do 
> >something malicious. Although at this point it is clear that the 
> >phishing gangs will be doing this at some point.
> 
> This has nothing to do with VPNs, only with SSL-enabled sites. None 
> of the SSL VPN vendors that I know of allow DES as an acceptable 
> connection algorithm by default. If you are saying that a significant 
> number of users who have SSL VPN systems have turned this on this 
> option, it would be good if you also supplied some evidence for this.
> 
> Of course, the algorithms being negotiated in the wild can actually 
> be measured by ISPs who do a bit of port sniffing. If anyone has such 
> numbers, it would greatly help to have them published!
> 
> >  > This ties closely to the request for tracking of the algorithms
> >>  allowed, suggested, and mandated in IETF standards. Even 
> today, DES  
> >> is the MUST-level algorithm for IKEv1 (the IPsec WG never 
> got around  
> >> to changing it). IKEv1 is a great example of a protocol where you  
> >> cannot determine what security algorithms are being used 
> by looking  
> >> at the RFC.
> >
> >I agree, I think we need a process and a set of use levels 
> for crypto 
> >algorithms. I think that this is an independent axis from 
> the standards 
> >level consideration. MD5 still makes a fine database hash.
> >
> >In your example DES is still a MUST for conformance testing 
> but it is a 
> >SHOULD NOT as far as security goes.
> 
> Huh? Where in RFC 2407 do you see that? The RFC is completely clear: 
> MUST support DES, "strongly encouraged" to support TripleDES. The 
> waffly words in the IESG note do not say "SHOULD NOT", and the 
> prediction that "it is very likely that the IETF will deprecate the 
> use of ESP_DES as a mandatory cipher suite in the near future" never 
> came to pass.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
> 
> 




From HugheJP@LOUISVILLE.STORTEK.COM Thu Aug 26 00:23:09 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7Q4N83a012574
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 00:23:08 -0400 (EDT)
Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146])
	i7Q4N5xW000840
	for <saag@mit.edu>; Thu, 26 Aug 2004 00:23:07 -0400 (EDT)
Received: from sherman.stortek.com (localhost [127.0.0.1])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id i7Q4N4KP001946
	for <saag@mit.edu>; Wed, 25 Aug 2004 22:23:04 -0600 (MDT)
Received: from lsv-msg07.louisville.stortek.com
	(lsv-msg07.louisville.stortek.com [129.80.18.77])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id i7Q4N3Cr001943;
	Wed, 25 Aug 2004 22:23:03 -0600 (MDT)
Received: by lsv-msg07.louisville.stortek.com with Internet Mail Service
	(5.5.2653.19)	id <QY0F3WF2>; Wed, 25 Aug 2004 22:23:03 -0600
Message-ID: <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
From: "Hughes, James P" <HugheJP@LOUISVILLE.STORTEK.COM>
To: "'kent@bbn.com'" <kent@bbn.com>
Subject: Re: [saag] Bad day at the hash function factory
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Length: 4436
Lines: 104
X-Mailman-Approved-At: Sat, 25 Sep 2004 01:40:40 -0400
cc: "'cfrg@ietf.org'" <cfrg@ietf.org>
cc: "'saag@mit.edu'" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Sat, 25 Sep 2004 05:38:27 -0000
X-Original-Date: Wed, 25 Aug 2004 22:22:57 -0600
X-List-Received-Date: Sat, 25 Sep 2004 05:38:27 -0000

Thanks Steve [Kent] and sorry about confusing the quotes. As you correctly
noted, I was was trying to comment on the absolutes in David's statement.  

Thanks Phillip [Hallam-Baker] about the fundamental differences in MD5 and
HMAC algorithm and generally agree, but would add that MD5 and SHA are
diffent "sized" algorithms and 128 vs 160 or 256 bits is not an
inconsequential difference and should be considered when discussing what
kinds of HMAC is recommmended. (Similar to the TDES vs AES discussions.)

Thanks Steve [Bellovin] for the "ad on" statement. I would like to agree and
even suggest that it goes without saying that you may want future new
applications of HMAC to pass over MD5 (for SHA-x where x>0) if they have the
option. 

Thanks! I thought this was a very civil conversation!

Jim




-----Original Message-----
From: Stephen Kent <kent@bbn.com>
To: Hughes, James P <HugheJP@LOUISVILLE.STORTEK.COM>
CC: saag@mit.edu <saag@mit.edu>; cfrg@ietf.org <cfrg@ietf.org>
Sent: Wed Aug 25 10:56:09 2004
Subject: Re: [saag] Bad day at the hash function factory

Jim,

>On Aug 23, 2004, at 8:32 PM, Stephen Kent wrote:
>>At 8:59 PM -0400 8/19/04, james hughes wrote:
>>>One comment and two discussion points.
>>>
>>>Can we withdraw the MD5 RFC as obsolete?
>>>
>>>On Aug 19, 2004, at 12:23 PM, David A. McGrew wrote:
>>>>>WHAT'S SAFE?
>>>>>First, anything that's already been signed is definitely safe.  If you
>>>>>stop using MD5 today, nothing you signed already puts you at risk.
>>>
>>>I sign a document (in the clear) which says "... pay me $100.00 ...
>>>" and now I can create a document that to  "... pay me $10,000 ... "
>>>with a collision. Just because the original is old, why are old
>>>these documents safe?
>>
>>because you would have to generate a collision with a fixed value,
>>the old has, and the techniques presented do not do that. They find a
>>collision for MD5 based on the ability to create both messages from
>>scratch. This is fundamentally different, in the same way that
>>"birthday paradox" attacks have always been different from fixed
>>message attacks.
>
>Yes, but...
>
>What you are saying is that even though MD5 is not collision 
>resistant and it has been demonstrated that there is a class of 
>messages that are not 2nd preimage resistant, that this class of 
>messages is small small enough that _any_ message is not a member of 
>this class even though the specific characteristics of this class 
>has not been determined.
>
>I could argue that saying that "nothing you signed already puts you 
>at risk" is being hopeful. It really depends on the numbers of 
>messages that have been signed and the percentage of this class. If 
>billions of messages have been signed, are _all_ of them safe? 
>Aren't we talking about probabilities? If we are talking about 
>[unknown] probabilities, isn't this statement false in a rigorous 
>logical [legal] sense (even though it may turn out to be true from a 
>practical sense)? I am quibbling with your words "definitely" and 
>"nothing" as being too absolute given the factual information that 
>is out there.

I'm looking at the text of my message that you copied  above and I 
don't see the words "definitely" or "nothing" in what I said, only in 
what David said :-)

But, I concede your point that IF the signed messages of interest 
have a prefix that falls into the class noted, then there could be a 
problem. I didn't attend Crypto, but the examples were shown for 
messages that were 1024 bits long, and the prefix was 512 bits. If 
the length is a critical feature of the attack capability, that would 
limit the set of vulnerable messages.

>
>I would suggest better wording of this statement would be
>>[...] anything that's already been signed has a high probability of 
>>being safe.  If you stop using MD5 today, there is a high 
>>probability that nothing [previously] you signed already puts you 
>>at risk.
>
>Even then, this begs the issue of trusting the timestamp.

Time stamp? The usual concern re time stamping is compromise of a 
private key and being able to distinguish what was signed before 
detection of the compromise, vs. afterwards. In this context, a 
secure time stamp would help IF it used a different hash algorithm. 
In the current Internet context, most of the persistent, signed 
objects are X.509 certificates, and the syntax of these certs does 
not accommodate time stamps from other parties.


Steve


From kivinen@iki.fi Thu Aug 26 07:00:18 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QB0H3a021752
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 07:00:17 -0400 (EDT)
Received: from mail.kivinen.iki.fi ([83.145.195.1])i7QB0FIO020347
	for <saag@mit.edu>; Thu, 26 Aug 2004 07:00:16 -0400 (EDT)
Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1])
	by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i7QB07ai019360
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Thu, 26 Aug 2004 14:00:12 +0300 (EEST)
Received: (from kivinen@localhost)
	by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i7QB04kN019342;
	Thu, 26 Aug 2004 14:00:04 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to
	kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16685.49844.415733.252266@fireball.kivinen.iki.fi>
From: Tero Kivinen <kivinen@iki.fi>
To: sommerfeld@sun.com
Subject: [saag] naming/use of rfc2412/rfc3526 groups by other protocols
In-Reply-To: <200408252136.i7PLaoOY023143@thunk.east.sun.com>
References: <200408252136.i7PLaoOY023143@thunk.east.sun.com>
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Edit-Time: 19 min
X-Total-Time: 29 min
Content-Length: 2080
Lines: 55
X-Mailman-Approved-At: Sat, 25 Sep 2004 01:40:40 -0400
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Sat, 25 Sep 2004 05:38:28 -0000
X-Original-Date: Thu, 26 Aug 2004 14:00:04 +0300
X-List-Received-Date: Sat, 25 Sep 2004 05:38:28 -0000

Bill Sommerfeld writes:
> rfc2412 (oakley) defines several "MODP" diffie-hellman groups of
> varying sizes in appendix E.  Several larger groups were defined in
> RFC3526.

And their numbers are handled by the IANA registry for the Internet
Key Exchange (IKE) attributes
(http://www.iana.org/assignments/ipsec-registry).

> SSHv2 uses one of these groups, and also includes an extension to
> allow the group to be dynamically negotiated.
> 
> Muddying the waters, SSHv2 defined its own group-numbering space;
> diffie-hellman-group1-sha1 is the same as IKE's "group 2".

Yes, that is correct, it should use its own number space, as it wants
to control what groups are allowed etc. Thats why it should have its
own registry listing the groups. 

> Do any protocols other than SSHv2 reuse IKE's MODP Diffie-Hellman
> groups?

Yes. 

> If so, what naming convention, if any, is used in that protocol?

iSCSI RFC 3723 (Securing Block Storage Protocols over IP) uses same
prime number, but different generator for those groups, and names them
with nameslike "MODP-XXXX" where XXXX is the number of bits. Their
groups are named in their own IANA registry
(http://www.iana.org/assignments/iscsi-parameters). 

draft-clancy-eap-pax-00.txt uses the 3072 bit group and gives it
number 0x01. 

draft-moskowitz-hip-09.txt uses 1536-8192 bit groups, and gives them
their own numbers from 3-6.

draft-riikonen-silc-ke-auth-08.txt uses 1024-2048 bit groups, and
gives them their own name diffie-hellman-group1 - diffie-hellman-group3.

draft-tuexen-sctp-auth-chunk-01.txt uses all IKE modp groups, and uses
the same numbers than IKE, but it seems they will allocate their own
IANA registry for number, the initial values will simply be same. 

draft-cam-winget-eap-fast-00.txt uses 2048 bit group, but I think they
send the whole group every time, i.e the groups do not have registry
or name.

draft-ietf-tls-srp-07.txt also uses 3072-8192 bit groups, but
different generators, and they send the whole group every time (I
think), thus there is no registry or name. 
-- 
kivinen@safenet-inc.com


From ggr@qualcomm.com Thu Aug 26 16:22:07 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7QKM63a008626
	for <saag@jis.mit.edu>; Thu, 26 Aug 2004 16:22:06 -0400 (EDT)
Received: from garie.qualcomm.com (garie.qualcomm.com [203.30.171.17])
	i7QKM4ua004637
	for <saag@mit.edu>; Thu, 26 Aug 2004 16:22:04 -0400 (EDT)
Received: from grose1.qualcomm.com ([1.1.1.4])i7QKL3Q4004336;
	Fri, 27 Aug 2004 06:21:04 +1000
Message-Id: <6.0.0.22.2.20040827061612.03b4c3d0@203.30.171.17>
X-Sender: ggr2@203.30.171.17
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Greg Rose <ggr@qualcomm.com>
Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory 
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEAE0@mou1wnexm05.vcorp
	.ad.vrsn.com>
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEAE0@mou1wnexm05.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 1350
Lines: 26
X-Mailman-Approved-At: Sat, 25 Sep 2004 01:40:40 -0400
cc: "Hughes, James P" <HugheJP@LOUISVILLE.STORTEK.COM>
cc: "'kent@bbn.com'" <kent@bbn.com>
cc: "'cfrg@ietf.org'" <cfrg@ietf.org>
cc: "'saag@mit.edu'" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Sat, 25 Sep 2004 05:38:28 -0000
X-Original-Date: Fri, 27 Aug 2004 06:21:04 +1000
X-List-Received-Date: Sat, 25 Sep 2004 05:38:28 -0000

At 10:32 2004-08-26 -0700, Hallam-Baker, Phillip wrote:
>RC4 has been compromised by Shamir & co, but as a general rule I don't think
>any stream cipher should ever get a higher status than acceptable. A stream
>cipher always allows a person who has a plaintext and ciphertext
>corresponding to a key to encode or decode all messages with that key that
>are shorter or the same size. In effect all stream ciphers are vulnerable to
>a trivial form of known plaintext attack, the attack does not reveal the key
>but this is not necessary.

That's a completely bogus argument. The industry has already accepted that 
one needs to use block ciphers correctly (unpredictable random IVs, for 
example, and no ECB mode). Well, guess what, you need to use stream ciphers 
correctly too. That includes some kind of nonce mechanism. The 
new-generation stream ciphers (since NESSIE required it) all support 
Nonces, and usually with no hard-to-meet requirements about 
unpredictability. Efficiency always matters. So I don't think this position 
is justifiable.

Greg.

Greg Rose                                    INTERNET: ggr@qualcomm.com
Qualcomm Australia       VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,             http://people.qualcomm.com/ggr/
Gladesville NSW 2111/232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C



From HugheJP@LOUISVILLE.STORTEK.COM Fri Aug 27 00:16:43 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7R4Gg3a020418
	for <saag@jis.mit.edu>; Fri, 27 Aug 2004 00:16:43 -0400 (EDT)
Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146])
	i7R4GgNr028660
	for <saag@mit.edu>; Fri, 27 Aug 2004 00:16:42 -0400 (EDT)
Received: from sherman.stortek.com (localhost [127.0.0.1])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id i7R4GfKL024056
	for <saag@mit.edu>; Thu, 26 Aug 2004 22:16:41 -0600 (MDT)
Received: from lsv-msg07.louisville.stortek.com
	(lsv-msg07.louisville.stortek.com [129.80.18.77])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id i7R4GeCr024053;
	Thu, 26 Aug 2004 22:16:40 -0600 (MDT)
Received: by lsv-msg07.louisville.stortek.com with Internet Mail Service
	(5.5.2653.19)	id <QY0FP0BK>; Thu, 26 Aug 2004 22:16:40 -0600
Message-ID: <151A63B4E33B4F49896AC6D1BA788A6E15C594@EXCHVS2.louisville.stortek.com>
From: "Hughes, James P" <HugheJP@LOUISVILLE.STORTEK.COM>
To: "'pbaker@verisign.com'" <pbaker@verisign.com>, "'saag@mit.edu'"
	<saag@mit.edu>
Subject: Re: [saag] Bad day at the hash function factory
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1122
Lines: 39
X-Mailman-Approved-At: Sat, 25 Sep 2004 01:40:40 -0400
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Sat, 25 Sep 2004 05:38:28 -0000
X-Original-Date: Thu, 26 Aug 2004 22:16:29 -0600
X-List-Received-Date: Sat, 25 Sep 2004 05:38:28 -0000

"Strength" is the hash length. I would suggest they are talking about -any-
hash algorithms with 160 (or fewer) bits, public or not. I could read this
to include block cipher based hash algorithms with results < 160 bits too. 

I am surprised that they consider the recent news enough to announce that
sha-1 is "done" too. 

My personal comments to this is "wow" and "interesting". 

Based on this, I will change my suggestions to replace MD5 with SHA-x, where
x>1 because changing to something with a life of <6 years would not be so
smart. 


Thanks!!

Jim




-----Original Message-----
From: saag-bounces@mit.edu <saag-bounces@mit.edu>
To: saag@mit.edu <saag@mit.edu>
Sent: Thu Aug 26 20:54:23 2004
Subject: RE: [saag] Bad day at the hash function factory


> For planning purposes by
> Federal agencies and others, note also that the use of other
> cryptographic algorithms of similar strength to SHA-1 will also be
> phased out in 2010.

Anyone got an idea what this might refer to? DSA? 3DES?
_______________________________________________
saag mailing list
saag@mit.edu
https://jis.mit.edu/mailman/listinfo/saag


From alten@EscalonNetworks.com Sat Aug 28 22:15:58 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i7T2Fw3a001702
	for <saag@jis.mit.edu>; Sat, 28 Aug 2004 22:15:58 -0400 (EDT)
Received: from degas.netvista.net (mail.netvista.net [206.170.46.14])
	i7T2Fn9v017016
	for <saag@mit.edu>; Sat, 28 Aug 2004 22:15:49 -0400 (EDT)
Received: from alten.comcast.net (64.124.189.124.gatespeed.com
	[64.124.189.124])	(authenticated)
	by degas.netvista.net (8.11.6/8.11.6) with ESMTP id i7T2FYO26764;
	Sat, 28 Aug 2004 19:15:34 -0700
Message-Id: <4.3.2.7.1.20040828191644.017a7348@mail.netvista.net>
X-Sender: alten@mail.netvista.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Russ Housley <housley@vigilsec.com>, james hughes <jim_hughes@stortek.com>
From: Alex Alten <alten@EscalonNetworks.com>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
In-Reply-To: <6.1.1.1.2.20040820101325.03cbfad8@mail.binhost.com>
References: <2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
	<20040818191747.E2C147199@sierra.rtfm.com>
	<1B38BDAC-F1FC-11D8-B277-0003935495EC@cisco.com>
	<2FBAEDD6-F244-11D8-8FDC-000A95A27482@stortek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-MailScanner: Found to be clean
Content-Length: 560
Lines: 27
X-Mailman-Approved-At: Sat, 25 Sep 2004 01:40:40 -0400
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Sat, 25 Sep 2004 05:38:28 -0000
X-Original-Date: Sat, 28 Aug 2004 19:17:54 -0700
X-List-Received-Date: Sat, 25 Sep 2004 05:38:28 -0000


RADIUS is in the same situation too.  - Alex

At 10:17 AM 8/20/2004 -0400, Russ Housley wrote:
>Jim:
>
>>Can we withdraw the MD5 RFC as obsolete?
>
>Nope.  There are a lot of mechanisms that use it.  And MD5 is the only 
>integrity mechanism that we have for BGP (see 
>draft-iesg-tcpmd5app-00.txt).  It will take a long time to completely move 
>away from MD5.
>
>Russ
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@ietf.org
>https://www1.ietf.org/mailman/listinfo/cfrg

--

Alex Alten
alten@EscalonNetworks.com
(510)-353-1104



From sommerfeld@east.sun.com Thu Sep  2 09:40:38 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i82DeW3a029749
	for <saag@jis.mit.edu>; Thu, 2 Sep 2004 09:40:37 -0400 (EDT)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	i82DeVYs029228
	for <saag@mit.edu>; Thu, 2 Sep 2004 09:40:31 -0400 (EDT)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49])
	i82DeU35025945; 	Thu, 2 Sep 2004 06:40:30 -0700 (PDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	ESMTP id i82DeTQH006151;	Thu, 2 Sep 2004 09:40:29 -0400 (EDT)
Received: from thunk (localhost [127.0.0.1])i82DeTaE019399;
	Thu, 2 Sep 2004 09:40:29 -0400 (EDT)
Message-Id: <200409021340.i82DeTaE019399@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@east.sun.com>
To: "Steve Crocker" <steve@stevecrocker.com>
Subject: Re: [saag] The End of Encryption? 
In-Reply-To: Your message of "Thu, 02 Sep 2004 08:47:25 EDT."
	<00bf01c490ea$ff553de0$0cffa8c0@SCROCKER> 
Sender: sommerfeld@east.sun.com
Content-Length: 923
Lines: 24
X-Mailman-Approved-At: Sat, 25 Sep 2004 01:40:40 -0400
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: sommerfeld@east.sun.com
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Sat, 25 Sep 2004 05:38:28 -0000
X-Original-Date: Thu, 02 Sep 2004 09:40:29 -0400
X-List-Received-Date: Sat, 25 Sep 2004 05:38:28 -0000

> I don't follow the literature very closely, but I have not seen
> *any* evidence to suggest P = NP.  Does anyone have such evidence?
> By evidence, I mean anything reasonably suggestive, not necessarily
> something as strong as a proof.

If you merely want *suggestive*, look at this bit of hype in the
referenced article:

    That means that if a solution for any NP-complete problem could be
    found that could be solved in polynomial time, then a short-cut
    solution could be found for every NP problem.

    In practical terms, that would spell the end of encryption as we know
    it. The Internet would be vulnerable to hackers and computer
    viruses. 

As we well know, the internet is already vulnerable to hackers
and computer viruses..  So this must already have happened :-)

(And if you believe that, I have some nice nondeterministic polynomial
prime development swampland for sale..)

						- Bill


From pbaker@verisign.com Sat Sep 25 09:30:55 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8PDUsPU002958
	for <saag@jis.mit.edu>; Sat, 25 Sep 2004 09:30:54 -0400 (EDT)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	i8PDUrH5015639
	for <saag@mit.edu>; Sat, 25 Sep 2004 09:30:53 -0400 (EDT)
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com
	[65.205.251.54])i8PDUhWa024500;	Sat, 25 Sep 2004 06:30:43 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <SRFYTB0R>; Sat, 25 Sep 2004 06:30:43 -0700
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEBFC@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Jeff Williams'" <jwkckid1@ix.netcom.com>,
   "Hallam-Baker, Phillip"
	 <pbaker@verisign.com>
Subject: RE: [saag] Algorithm recommendations
Date: Sat, 25 Sep 2004 06:30:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.637944
cc: 'Stephen Kent' <kent@bbn.com>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 25 Sep 2004 13:30:56 -0000

The NEWTRK group has been started to do just that.

My concern wrt crypto algorithms is that what we really need here is
process. If the institutional sclerosis of the IETF means that it will take
us six years to establish a process the effort is not going to have much
significance.`

Another concern is that this is an area where there really needs to be
agreement across all the standards organizations in the Internet space and
with the crypto community.

The crypto folk seemed to enjoy the AES contest and a logical outcome of any
process would be a conclusion of the form 'we need a better algorithm to do
X'. There is apparently a contest on to create a new stream cipher, it may
be appropriate to look at a new digest algorithm in a year or two.

> -----Original Message-----
> From: Jeff Williams [mailto:jwkckid1@ix.netcom.com]
> Sent: Saturday, September 25, 2004 1:35 AM
> To: Hallam-Baker, Phillip
> Cc: 'Stephen Kent'; saag@mit.edu
> Subject: Re: [saag] Algorithm recommendations
> 
> 
> Phillip and all,
> 
>   This would be a good idea and very long overdue yet suggested some
> 6 years ago now to the IESG.  However the debates on what the 
> criterion
> for such meaningful and measured consensus based method were
> inconclusive as I recall..  However I don't recall Stephen ever
> participating
> in those debates or discussions...
> 
> Hallam-Baker, Phillip wrote:
> 
> > Before we get too far into this, by the time NEWTRK has finished
> > there might actually be a meaningful standards designation.
> >
> > > At 10:38 PM -0700 9/22/04, Jeff Williams wrote:
> > > >Steven and all,
> > > >
> > > >   Let's not forget that RFC's are not standards, but
> > > "Requests for Comments".
> > > >Hence when any RFC has a "Must" clause in it not 
> complying is hardly
> > > >a serious consideration...
> > >
> > > CCITT documents were titled "recommendations" but were 
> really de jure
> > > standards.
> > >
> > > Not RFCs are standards, but many, maybe most are, and are so
> > > identified via the status  portion of the RFC header.
> > >
> > > Steve
> > >
> > > _______________________________________________
> > > saag mailing list
> > > saag@mit.edu
> > > https://jis.mit.edu/mailman/listinfo/saag
> > >
> 
> Regards,
> 
> --
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
> "Be precise in the use of words and expect precision from others" -
>     Pierre Abelard
> 
> "If the probability be called P; the injury, L; and the burden, B;
> liability depends upon whether B is less than L multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> ===============================================================
> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> IDNS. div. of Information Network Eng.  INEG. INC.
> E-Mail jwkckid1@ix.netcom.com
>  Registered Email addr with the USPS
> Contact Number: 214-244-4827
> 
> 
From jwkckid1@ix.netcom.com Sat Sep 25 22:39:52 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8Q2dpPU021198
	for <saag@jis.mit.edu>; Sat, 25 Sep 2004 22:39:51 -0400 (EDT)
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net
	[207.69.200.157])i8Q2dnlL008497
	for <saag@mit.edu>; Sat, 25 Sep 2004 22:39:50 -0400 (EDT)
Received: from 1cust39.tnt36.dfw9.da.uu.net ([67.234.81.39]
	helo=ix.netcom.com)
	by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1CBOwt-0000fm-00; Sat, 25 Sep 2004 22:39:40 -0400
Message-ID: <41564728.DE591C62@ix.netcom.com>
Date: Sat, 25 Sep 2004 21:35:54 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: Re: [saag] Algorithm recommendations
References: <C6DDA43B91BFDA49AA2F1E473732113E010BEBFC@mou1wnexm05.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.685785
cc: 'Stephen Kent' <kent@bbn.com>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 26 Sep 2004 02:39:52 -0000

Phillip and all,

Hallam-Baker, Phillip wrote:

> The NEWTRK group has been started to do just that.

  Yes I am and have been aware of this group for awhile now
and have one of our staff members keeping me informed and
regularly updated as to the discussion and progress or lack there
of.

>
>
> My concern wrt crypto algorithms is that what we really need here is
> process.

  Yes a very good process that is very inclusive, open and transparent
would be a good thing.  However if not very inclusive, open and transparent
than such a process would be counter productive and possibly disruptive
and dangerous.

> If the institutional sclerosis of the IETF means that it will take
> us six years to establish a process the effort is not going to have much
> significance.`

  I agree. And this was indirectly my earlier point.  However as
the IETF/IESG are a very deliberate and untimely organization
in many areas of IT standards development based on recognized
and existing need, I an sometime saddened to say that perhaps,
like the UN, the IETF may not be the proper organization to
drive such endeavors.

>
>
> Another concern is that this is an area where there really needs to be
> agreement across all the standards organizations in the Internet space and
> with the crypto community.

  Very much so.  And this could be a daunting task if the IETF/IESG
is self considered the driving organization by which this level of cooperation
is to be achieved as the definite and obvious need for a very  inclusive, open
and transparent process to certainly be inclusive of commercial IT industry
members/participants and professionals is advisable or required.

>
>
> The crypto folk seemed to enjoy the AES contest and a logical outcome of any
> process would be a conclusion of the form 'we need a better algorithm to do
> X'. There is apparently a contest on to create a new stream cipher, it may
> be appropriate to look at a new digest algorithm in a year or two.

  I am not sure that contests are a good venue by which to determine what
is or is not a good process by which a good algorithm to do X' can be
developed.

>
>
> > -----Original Message-----
> > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com]
> > Sent: Saturday, September 25, 2004 1:35 AM
> > To: Hallam-Baker, Phillip
> > Cc: 'Stephen Kent'; saag@mit.edu
> > Subject: Re: [saag] Algorithm recommendations
> >
> >
> > Phillip and all,
> >
> >   This would be a good idea and very long overdue yet suggested some
> > 6 years ago now to the IESG.  However the debates on what the
> > criterion
> > for such meaningful and measured consensus based method were
> > inconclusive as I recall..  However I don't recall Stephen ever
> > participating
> > in those debates or discussions...
> >
> > Hallam-Baker, Phillip wrote:
> >
> > > Before we get too far into this, by the time NEWTRK has finished
> > > there might actually be a meaningful standards designation.
> > >
> > > > At 10:38 PM -0700 9/22/04, Jeff Williams wrote:
> > > > >Steven and all,
> > > > >
> > > > >   Let's not forget that RFC's are not standards, but
> > > > "Requests for Comments".
> > > > >Hence when any RFC has a "Must" clause in it not
> > complying is hardly
> > > > >a serious consideration...
> > > >
> > > > CCITT documents were titled "recommendations" but were
> > really de jure
> > > > standards.
> > > >
> > > > Not RFCs are standards, but many, maybe most are, and are so
> > > > identified via the status  portion of the RFC header.
> > > >
> > > > Steve
> > > >
> > > > _______________________________________________
> > > > saag mailing list
> > > > saag@mit.edu
> > > > https://jis.mit.edu/mailman/listinfo/saag
> > > >
> >
> > Regards,
> >
> > --
> > Jeffrey A. Williams
> > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
> > "Be precise in the use of words and expect precision from others" -
> >     Pierre Abelard
> >
> > "If the probability be called P; the injury, L; and the burden, B;
> > liability depends upon whether B is less than L multiplied by
> > P: i.e., whether B is less than PL."
> > United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> > ===============================================================
> > Updated 1/26/04
> > CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> > IDNS. div. of Information Network Eng.  INEG. INC.
> > E-Mail jwkckid1@ix.netcom.com
> >  Registered Email addr with the USPS
> > Contact Number: 214-244-4827
> >
> >

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From smb@research.att.com Sun Sep 26 11:54:27 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8QFsQPU009616
	for <saag@jis.mit.edu>; Sun, 26 Sep 2004 11:54:26 -0400 (EDT)
Received: from machshav.com (machshav.com [147.28.0.16])
	i8QFsOwq017276
	for <saag@mit.edu>; Sun, 26 Sep 2004 11:54:25 -0400 (EDT)
Received: by machshav.com (Postfix, from userid 512)
	id 5B133FB251; Sun, 26 Sep 2004 11:54:24 -0400 (EDT)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP
	id A818BFB24A; Sun, 26 Sep 2004 11:54:23 -0400 (EDT)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 1F55F1AE84; Sun, 26 Sep 2004 11:54:22 -0400 (EDT)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Hughes, James P" <HugheJP@LOUISVILLE.STORTEK.COM>
Subject: Re: [saag] Bad day at the hash function factory 
In-Reply-To: Your message of "Wed, 25 Aug 2004 22:22:57 MDT."
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 26 Sep 2004 11:54:21 -0400
Message-Id: <20040926155422.1F55F1AE84@berkshire.research.att.com>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.554990
cc: "'kent@bbn.com'" <kent@bbn.com>
cc: "'cfrg@ietf.org'" <cfrg@ietf.org>
cc: "'saag@mit.edu'" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 26 Sep 2004 15:54:27 -0000

In message <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.c
om>, "Hughes, James P" writes:

>Thanks Steve [Bellovin] for the "ad on" statement. I would like to agree and
>even suggest that it goes without saying that you may want future new
>applications of HMAC to pass over MD5 (for SHA-x where x>0) if they have the
>option. 
>

That statement is, in fact, not obvious -- there are respected members 
of the community (like Hugo) who feel that MD5 is fine with HMAC.  I'm 
not saying you're wrong -- but it doesn't "go without saying".

		--Steve Bellovin, http://www.research.att.com/~smb


From jwkckid1@ix.netcom.com Sun Sep 26 22:53:34 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8R2rXPU023538
	for <saag@jis.mit.edu>; Sun, 26 Sep 2004 22:53:33 -0400 (EDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net
	[207.69.200.148])i8R2rWIa008758
	for <saag@mit.edu>; Sun, 26 Sep 2004 22:53:32 -0400 (EDT)
Received: from 1cust20.tnt59.dfw5.da.uu.net ([67.203.43.20]
	helo=ix.netcom.com)
	by granger.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1CBldr-0003wE-00	for saag@mit.edu; Sun, 26 Sep 2004 22:53:32 -0400
Message-ID: <41579CC7.FAE4F7AF@ix.netcom.com>
Date: Sun, 26 Sep 2004 21:53:28 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: saag <saag@mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000031
Spam-Alum-Time: 0.544237
Subject: [saag] Cybersecurity leadership will not move to White House
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 27 Sep 2004 02:53:34 -0000

All,

  Seems that DHS has for the time being preserved it cybersecuity
predominance and effective control despite industry concerns...

See: http://www.govexec.com/dailyfed/0904/092404h1.htm

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From mouse@Sparkle.Rodents.Montreal.QC.CA Fri Oct  8 13:27:55 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i98HRt6A001798
	for <saag@jis.mit.edu>; Fri, 8 Oct 2004 13:27:55 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i98HRrMh025051
	for <saag@mit.edu>; Fri, 8 Oct 2004 13:27:53 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA04568;
	Fri, 8 Oct 2004 13:27:49 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200410081727.NAA04568@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Fri, 8 Oct 2004 13:12:16 -0400 (EDT)
To: saag@mit.edu
Subject: Re: [saag] Algorithm recommendations
In-Reply-To: <4152616B.6526AD6B@ix.netcom.com>
References: <20040922135209.C01A11AE84@berkshire.research.att.com>
	<4152616B.6526AD6B@ix.netcom.com>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.534766
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 08 Oct 2004 17:27:56 -0000

> Let's not forget that RFC's are not standards, but "Requests for
> Comments".

It's been a long time since that name was even vaguely appropriate.
"Requirements for Compliance" is a more appropriate expansion today.
Even drafts have a bureaucratic process and a bunch of unnecessary
fiddle-faddle requirements these days; there appears to be nothing
functionally equivalent to what RFCs were originally intended to be.
(For example, I have a document describing how I made SLIP support
IPv6; what should I do with it to float it for evaluation?
ftp.rodents.montreal.qc.ca/mouse/misc/ipv6-slip in case anyone is
interested.)

Furthermore, quite a number of RFCs actually _are_ standards.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From mouse@Sparkle.Rodents.Montreal.QC.CA Sat Oct  9 20:57:16 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9A0vF6A011072
	for <saag@jis.mit.edu>; Sat, 9 Oct 2004 20:57:16 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i9A0vEBj010095
	for <saag@mit.edu>; Sat, 9 Oct 2004 20:57:14 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id UAA19299;
	Sat, 9 Oct 2004 20:57:11 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200410100057.UAA19299@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Sat, 9 Oct 2004 20:47:07 -0400 (EDT)
To: saag@mit.edu
Subject: Re: [saag] The End of Encryption?
In-Reply-To: <200409021340.i82DeTaE019399@thunk.east.sun.com>
References: <200409021340.i82DeTaE019399@thunk.east.sun.com>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.571905
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 10 Oct 2004 00:57:17 -0000

> If you merely want *suggestive*, look at this bit of hype in the
> referenced article:

>     That means that if a solution for any NP-complete problem could
>     be found that could be solved in polynomial time, then a
>     short-cut solution could be found for every NP problem.

Yes (for theoretical values of "short-cut").

>     In practical terms, that would spell the end of encryption as we
>     know it.

No.

It is entirely possible that P==NP but that the resulting
polynomial-time algorithms have such huge constant factors, or
ridiculously high exponents, that the polynomial-time algorithms are
faster only for problems of impractically large size.

Suppose, for example, that it turns out to be possible to factor a
number of N bits in N^131072 time.  This _is_ polynomial time, and it
_is_ faster than current (exponential-time) algorithms for sufficiently
large N, but, absent some truly microscopic constant multiplier, the
point at which it becomes faster is _well_ above any number that
current (or even reasonably foreseeable) cryptography cares about.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From paul.hoffman@vpnc.org Tue Oct 19 20:25:05 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9K0Ox6A006634
	for <saag@jis.mit.edu>; Tue, 19 Oct 2004 20:25:04 -0400 (EDT)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	i9K0Owwa016872
	for <saag@mit.edu>; Tue, 19 Oct 2004 20:24:58 -0400 (EDT)
Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net
	[66.125.125.65])	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i9K0OoQY072317
	for <saag@mit.edu>; Tue, 19 Oct 2004 17:24:51 -0700 (PDT)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p0611043ebd9b600d3917@[10.20.30.249]>
Date: Tue, 19 Oct 2004 17:24:53 -0700
To: saag@mit.edu
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000004
Spam-Alum-Time: 0.568364
Subject: [saag] Security considerations for Unicode document
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 20 Oct 2004 00:25:06 -0000

Greetings again. The Unicode Consortium has begun to prepare a 
technical report on the security considerations for protocols that 
use Unicode. The first version (which has many TBDs in it) is at 
<http://www.unicode.org/reports/tr36/tr36-1.html>.

They are very open to suggestions for additions and changes. The 
description of the public review and how to comment are at 
<http://www.unicode.org/review/>. This is a good opportunity to get 
any concerns listed in what will be the final document.

--Paul Hoffman, Director
--VPN Consortium
From Mailer-Daemon@adelaidebank.com.au Wed Oct 20 12:01:02 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9KG116A028787
	for <saag@jis.mit.edu>; Wed, 20 Oct 2004 12:01:01 -0400 (EDT)
Received: from ableml01 (wwwproxy.adelaidebank.com.au [203.33.102.2])
	i9KG0wX9001477
	for <saag@mit.edu>; Wed, 20 Oct 2004 12:00:59 -0400 (EDT)
Received: from Unknown [172.17.5.100] by ableml01 - SurfControl E-mail Filter
	(4.7); Thu, 21 Oct 2004 01:30:58 +1030
Received: from ABDOMAIN-MTA by adelaidebank.com.au
	with Novell_GroupWise; Thu, 21 Oct 2004 01:30:56 +0930
Message-ID: <s1771150.034@adelaidebank.com.au>
From: "Paul DEWSNAP" <pdewsnap@adelaidebank.com.au>
To: <saag@mit.edu>
Date: Thu, 21 Oct 2004 01:30:32 +0930
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mailer: Novell GroupWise Internet Agent 6.0.2
X-SEF-AD9338D1-8359-424E-984B-C89FFC78DAE5: 1
Sender: Postmaster@adelaidebank.com.au
Errors-To: Postmaster@adelaidebank.com.au
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.606978
Subject: [saag] Re: saag Digest, Vol 21, Issue 3
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: pdewsnap@adelaidebank.com.au
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 20 Oct 2004 16:01:03 -0000

I am out of the office until Monday 25th of October. Your email has not
been forwarded. If this matter is urgent please contact the HelpDesk on
8300 6555 or helpdesk@adelaidebank.com.au 

Regards,
Paul

>>> saag 10/21/04 01:30 >>>

Send saag mailing list submissions to
	saag@mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
	https://jis.mit.edu/mailman/listinfo/saag
or, via email, send a message with subject or body 'help' to
	saag-request@mit.edu

You can reach the person managing the list at
	saag-owner@mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of saag digest..."
____________________________________________________________________

This e-mail and any files transmitted with it are confidential and 
are only for the use of the person to whom they are addressed.

If you are not the intended recipient, you are hereby notified that 
any use, dissemination, forwarding, printing, copying or dealing 
in any way whatsoever with this e-mail is strictly prohibited.

If you have received this e-mail in error, please reply to us 
immediately and delete the document.

It is the recipient's duty to virus scan and otherwise test the 
enclosed information before using the information or loading 
attached files onto any computer system.  Adelaide Bank Ltd 
does not warrant that the information contained in this e-mail 
is free from viruses, defects, errors, interception or interference.

Any views expressed in this message are those of the individual 
sender, except where that sender specifically states them to be 
the views of Adelaide Bank Ltd.
____________________________________________________________________

From housley@vigilsec.com Wed Oct 27 16:24:46 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9RKOj6A018940
	for <saag@jis.mit.edu>; Wed, 27 Oct 2004 16:24:45 -0400 (EDT)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	i9RKOgtE028955
	for <saag@mit.edu>; Wed, 27 Oct 2004 16:24:42 -0400 (EDT)
Received: (qmail 32057 invoked by uid 0); 27 Oct 2004 20:24:22 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.131.70)
  by woodstock.binhost.com with SMTP; 27 Oct 2004 20:24:22 -0000
Message-Id: <6.1.2.0.2.20041027162204.04d4b0b0@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Wed, 27 Oct 2004 16:24:16 -0400
To: saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=====================_3148827==_"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000508
Spam-Alum-Time: 0.586048
Subject: [saag] Fwd: Counter-Spam
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 27 Oct 2004 20:24:47 -0000

--=====================_3148827==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

This message is being forwarded at the request of Charles W. Kellum.

Russ

= = = = = = = = =

Dear Sirs:

     A hardware-based alternative to the Sender-ID specification has been 
developed and patented. It is software independent. Thus, it is not 
vulnerable to cyberattack. The technology is described in the attachment 
TN006. Additional information is available, if there is interest.

Sincerely,
Charles W. Kellum


--=====================_3148827==_
Content-Type: application/pdf; name="TN006.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="TN006.pdf"

JVBERi0xLjMNJeLjz9MNCjE4IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAyMCANL0ggWyA4
ODAgMjg5IF0gDS9MIDExMzQ3MCANL0UgOTA3NzUgDS9OIDQgDS9UIDExMjk5MiANPj4gDWVuZG9i
ag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4cmVmDTE4IDIyIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA3ODcgMDAwMDAgbg0KMDAw
MDAwMTE2OSAwMDAwMCBuDQowMDAwMDAxMzIzIDAwMDAwIG4NCjAwMDAwMDE0OTQgMDAwMDAgbg0K
MDAwMDAwMTk4MCAwMDAwMCBuDQowMDAwMDAyNTQyIDAwMDAwIG4NCjAwMDAwMDI3NjggMDAwMDAg
bg0KMDAwMDAwMzAwOSAwMDAwMCBuDQowMDAwMDAzMDQ4IDAwMDAwIG4NCjAwMDAwMDM5MDQgMDAw
MDAgbg0KMDAwMDAwNDMzNSAwMDAwMCBuDQowMDAwMDA0NTY4IDAwMDAwIG4NCjAwMDAwMDUwMTUg
MDAwMDAgbg0KMDAwMDAwNTIzNSAwMDAwMCBuDQowMDAwMDA3OTEyIDAwMDAwIG4NCjAwMDAwMzAy
OTYgMDAwMDAgbg0KMDAwMDAzMDM3NCAwMDAwMCBuDQowMDAwMDU5NjY4IDAwMDAwIG4NCjAwMDAw
NzY3NTggMDAwMDAgbg0KMDAwMDAwMDg4MCAwMDAwMCBuDQowMDAwMDAxMTQ4IDAwMDAwIG4NCnRy
YWlsZXINPDwNL1NpemUgNDANL0luZm8gMTYgMCBSIA0vUm9vdCAxOSAwIFIgDS9QcmV2IDExMjk4
MiANL0lEWzxlNjI0OWJjMzFiOTZkYWYwZWVmNWRjNGJhYWQ1MzI5Zj48Nzc4YTRmNjE1YjhmN2Iy
ODcxMThhNjhhY2ZmMTI1YjE+XQ0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAgDTE5IDAgb2JqDTw8
IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDE1IDAgUiANL01ldGFkYXRhIDE3IDAgUiANL1BhZ2VM
YWJlbHMgMTQgMCBSIA0+PiANZW5kb2JqDTM4IDAgb2JqDTw8IC9TIDEzMiAvTCAxOTkgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzOSAwIFIgPj4gDXN0cmVhbQ0KSIliYGBgBqICBlYgeY1B
kAEBBIFirAwsDBwVDAxrzrTNdrqSwMBQs+QAXAFnxCklhVNzZv1yvJhwyamTLei5muP6XhlHkTSn
iOtHgeoYRSM6OhpASpU6IAyXNAgDyG+AmwkEXAyMcwuBtBAQi4JF1Bn4GZ4xCfD+UNggnmDUwMBs
yCzAzMFzgDvQ8+olB+FP7q1mN3hYJnBtSmqAuIaXgXGTOZBmAmJvgAADAJJCMksNZW5kc3RyZWFt
DWVuZG9iag0zOSAwIG9iag0xNzYgDWVuZG9iag0yMCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q
YXJlbnQgMTUgMCBSIA0vUmVzb3VyY2VzIDIxIDAgUiANL0NvbnRlbnRzIDI3IDAgUiANL01lZGlh
Qm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAg
DT4+IA1lbmRvYmoNMjEgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8
PCAvVFQyIDIyIDAgUiAvVFQ0IDIzIDAgUiAvVFQ2IDI4IDAgUiAvVFQ4IDMwIDAgUiA+PiANL0V4
dEdTdGF0ZSA8PCAvR1MxIDM0IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyNiAwIFIgPj4g
DT4+IA1lbmRvYmoNMjIgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUg
DS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjIgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDI1MCAzMzMgMjUwIDI3OCA1MDAgMCA1MDAgNTAwIDUwMCA1MDAgNTAwIA01MDAg
NTAwIDUwMCAwIDMzMyAwIDAgMCAwIDkyMCA2MTEgMCA2NjcgNzIyIDYxMSAwIDAgMCAzMzMgMCAw
IDAgDTAgNjY3IDcyMiA2MTEgMCA2MTEgNTAwIDU1NiAwIDYxMSA4MzMgMCAwIDAgMCAwIDAgMCAw
IDAgNTAwIDUwMCANNDQ0IDUwMCA0NDQgMjc4IDUwMCA1MDAgMjc4IDAgNDQ0IDI3OCA3MjIgNTAw
IDUwMCA1MDAgNTAwIDM4OSAzODkgDTI3OCA1MDAgNDQ0IDY2NyA0NDQgNDQ0IDM4OSBdIA0vRW5j
b2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9BSElEQUorVGltZXNOZXdSb21hbixJ
dGFsaWMgDS9Gb250RGVzY3JpcHRvciAyNSAwIFIgDT4+IA1lbmRvYmoNMjMgMCBvYmoNPDwgDS9U
eXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAx
NDggDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDc3OCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUw
IDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIA01MDAgNTAwIDUwMCA1MDAgMCAyNzggMCAwIDAgMCAw
IDAgNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDAgDTMzMyAwIDcyMiA2MTEgODg5IDcyMiA3
MjIgNTU2IDAgNjY3IDU1NiA2MTEgNzIyIDcyMiA5NDQgMCAwIDAgMzMzIA0wIDMzMyAwIDAgMCA0
NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzggNTAwIDI3OCA3NzggDTUwMCA1
MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDQ0NCAwIDAgMCAwIDAg
MCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDMzMyA0NDQgNDQ0IF0gDS9FbmNv
ZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0FISURFSitUaW1lc05ld1JvbWFuIA0v
Rm9udERlc2NyaXB0b3IgMjQgMCBSIA0+PiANZW5kb2JqDTI0IDAgb2JqDTw8IA0vVHlwZSAvRm9u
dERlc2NyaXB0b3IgDS9Bc2NlbnQgODkxIA0vQ2FwSGVpZ2h0IDY1NiANL0Rlc2NlbnQgLTIxNiAN
L0ZsYWdzIDM0IA0vRm9udEJCb3ggWyAtNzcgLTIxNiAxMDA5IDg3NyBdIA0vRm9udE5hbWUgL0FI
SURFSitUaW1lc05ld1JvbWFuIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDk0IA0vWEhlaWdodCAw
IA0vRm9udEZpbGUyIDM1IDAgUiANPj4gDWVuZG9iag0yNSAwIG9iag08PCANL1R5cGUgL0ZvbnRE
ZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdodCA2NTYgDS9EZXNjZW50IC0yMTYgDS9G
bGFncyA5OCANL0ZvbnRCQm94IFsgLTE3MiAtMjE2IDk4NiA4ODAgXSANL0ZvbnROYW1lIC9BSElE
QUorVGltZXNOZXdSb21hbixJdGFsaWMgDS9JdGFsaWNBbmdsZSAtMTUgDS9TdGVtViA4My4zMTc5
OSANL1hIZWlnaHQgMCANL0ZvbnRGaWxlMiAzMyAwIFIgDT4+IA1lbmRvYmoNMjYgMCBvYmoNWyAN
L0lDQ0Jhc2VkIDMyIDAgUiANXQ1lbmRvYmoNMjcgMCBvYmoNPDwgL0xlbmd0aCA3ODIgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInMVt1v0zAQf89f4UdHWjx/JrF4YXQDgTSEaAQP
Ew9R5m2FJkFJwxh/PeePJulEKYNJo62cc32+O/9+57u8KKLjouCIoeIqYpRQjih8vZTBT6Yk5xSW
6+h40aeo6r0C6qsmOn61ZOi6jygqKjvcRvgsLj5bk9KbpE7b6lKSMprDpDiNcBK0to5nWkIoEbQW
v7GVysxrQaRUWP8XuK1jJonEKP5UvJmZnwJmRHEW9tk9+HS/i4zLNARidsOlREoRzOCrexYIz5Sc
QmPSYQOSBfEWojRNb45iRTRGr+HBcBMnjKS4Iv5PhOL016N/7Fv9D8Y/URzJST1gghMulZoQo2qL
WABs+bWs0cJSm+M2FkThAZDKLW6ANt6YrjZxBlIZJxxWe7/cmf5eHiTCJbNESZqRVAO9e0lSuaTg
U5PMWrX01KYDJwIisCnWoPcwkxCJnxVhtYsZjGVl4hyYfWo+Hm30pAF8mudsogruEuCWOOBSD5zf
8Q6Oz/GNJUgDYiHL7cQ8c+SgzP1J3Sj8UqJTmlC4Ws5ZsvUG6DMpsv1cLYfVxli3gtNHOeuYyk8G
t3se1vSsCMJylc4ukBgvEJ+TcuCwFfli1uuhhhum8XOb9Bp/M93qR5wCl21DGrMJzASPjhk9McNG
ZqT3e7I238vmsluVR+jDCVwQ5k7FuYAYnzqn/yojDtQ/x4ciSuf5rAWosT1e4IeYDNUrdBZFpN42
nbPFaVK8TeDW2e6TsIxYj1BJ80xOzY2F1hQqLQNic9+9ncQVlE8kcwaGYQodfmqUyUQofjtYO1OP
ZtDitA/Eq7l8wx/NKvjL7zdTqJ9Uy3nfRbuhQSBK8Blk3GkVprpp2nV7fbdrmaXji4qTmMoIHFxK
TfLMH2UsStXIAbydLE01dAYt2roemlVVblZt06OXXdtsEtNcovP2clibA7DZwgTOmCZii1vI+VAL
t85c32qHxnWosh9sR9o9Bx1NOwleuISmhDF7qepZ8iTzeofCB2qnwv8kzuQHbDt3YnmHOJQal6Rn
RfRTgAEA3KX9hQplbmRzdHJlYW0NZW5kb2JqDTI4IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1
YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTIxIA0vV2lkdGhzIFsg
MjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgDTAgMCAwIDY2NyAwIDY2NyAwIDAgMCAzODkgMCAwIDAgMCA3MjIgMCAwIDAgMCA1
NTYgNjExIDcyMiAwIDg4OSANMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDAgNDQ0IDAgNDQ0IDMzMyA1
MDAgNTU2IDI3OCAwIDAgMjc4IDc3OCA1NTYgDTUwMCA1MDAgMCAzODkgMzg5IDI3OCA1NTYgMCAw
IDAgNDQ0IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0FISURKTytU
aW1lc05ld1JvbWFuLEJvbGRJdGFsaWMgDS9Gb250RGVzY3JpcHRvciAyOSAwIFIgDT4+IA1lbmRv
YmoNMjkgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA4OTEgDS9DYXBI
ZWlnaHQgNjU2IA0vRGVzY2VudCAtMjE2IA0vRmxhZ3MgOTggDS9Gb250QkJveCBbIC0xNzAgLTIx
NiAxMDA5IDg4NyBdIA0vRm9udE5hbWUgL0FISURKTytUaW1lc05ld1JvbWFuLEJvbGRJdGFsaWMg
DS9JdGFsaWNBbmdsZSAtMTUgDS9TdGVtViAxNDIuMzk3IA0vRm9udEZpbGUyIDM3IDAgUiANPj4g
DWVuZG9iag0zMCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0Zp
cnN0Q2hhciAzMiANL0xhc3RDaGFyIDEyMSANL1dpZHRocyBbIDI1MCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAwIA0wIDAgMCAwIDAg
MCAwIDAgMCAwIDcyMiAwIDcyMiAwIDAgNjExIDAgMCAzODkgMCAwIDAgOTQ0IDAgMCA2MTEgDTAg
NzIyIDU1NiA2NjcgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDU1NiA0NDQgNTU2IDQ0NCAz
MzMgMCANNTU2IDI3OCAwIDAgMjc4IDgzMyA1NTYgNTAwIDU1NiAwIDQ0NCAzODkgMzMzIDU1NiAw
IDAgMCA1MDAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvQUhJRE5N
K1RpbWVzTmV3Um9tYW4sQm9sZCANL0ZvbnREZXNjcmlwdG9yIDMxIDAgUiANPj4gDWVuZG9iag0z
MSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdo
dCA2NTYgDS9EZXNjZW50IC0yMTYgDS9GbGFncyAzNCANL0ZvbnRCQm94IFsgLTI4IC0yMTYgMTAw
OSA4OTEgXSANL0ZvbnROYW1lIC9BSElETk0rVGltZXNOZXdSb21hbixCb2xkIA0vSXRhbGljQW5n
bGUgMCANL1N0ZW1WIDE2MCANL0ZvbnRGaWxlMiAzNiAwIFIgDT4+IA1lbmRvYmoNMzIgMCBvYmoN
PDwgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0xlbmd0aCAyNTc1IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+IA1zdHJlYW0NCkiJnJZ5VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkIARJC
SNgFQUQFFEVEhKqVMtZtdEZPRZ0urmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3d+/v
3d+9953zAKAnpaq11TALAI3WoM9KjMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyLnl4H
kGm9IkzKwDDw/4kt1+kNAEAZOAcolLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved85jna
xAqNVoGzKWedQqMw8WmcV9cZlTgjqTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZD2e6
PidLgvMCAMh01Ttc+g4blA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRao5Np
GwGYv/OcOKbaYniRg0WhwcFCfx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re20i0A
jK8EwPLmW5vL+wAw8b4dvvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/Jgccoy
mbHKgJnqJq+uqjbqsVqdTK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/UxN/
ZdhPND/XuLhjrwGv2AewLvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NWrZqL
k2TlYHKjvm5+z/RZAgKgAibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAddIEe
sB5sAsNgOxgDu8F+cBCMg4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflDYigS
iodSoSyoACqBVJAWMkIt0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vBvrAY
joFT4Bx4CayCa+AmuBNeBw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQheqQV6UYG
kVFkP3IMOYtcQSaRR8gLlIhyUQwVouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbBluBFCCNI
CYsIKkI9oYswSNhJ+IhwhnCNME14SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPES8S7xFkSiWRF8iJF
kNJJMpKB1EXaQtpH+ox0mTRNek6mkR3I/uQEciFZS+4gD5L3kD8lXybfI7+isCiulDBKOkVBaaT0
UcYoxygXKdOUV1Q2VUCNoOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gcuidd
Qi+iG+nr6B/Sj9O/oj9hMBhujGhGIcPAWMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElhujJj
mEuZTcxB5iHmReYjFoXlxpKwZKxW1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifnA84p
zl0uwnXmSrhy7gruGPcMd5pH5Al4Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+H/8g
/zr/pYWdRYyF0mKNxX6LyxbPLG0soy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt6623WZ+x
fmTDswm3kdt02xy0uWkL23raZtk2235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4DpEO
aocBh88c/oqZYzFYFTaEncZmHG0dkxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4uKS5
tLjsdbnpSnEVu5a7bnY96/rMTeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUeWz2+
9IQ9gzzLPUc8L3rBXsFeaq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S303eB7
1ve1X5Bfld+Y3y0RR5Qs6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauCTgb9
IzgkWB+8P/hBiEtISch7ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0CwQLlg
bMHdCKcIWcSOiMlILLIk8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBImWSY5
HofEJcZ1x03Ec+Jz44fjv05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcln06hp2Sn
DKd8k+qZqk89lganJadtTLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc7OLs
PdlPc2Jz+nJu5brnGnNP5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL4xdvWjxd
FFTUVXR9iWBJw5JzS62XVi39pJhZLCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3yx8qohUDigfK
CGW/8l5ZRFl/2X1VhGqj6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86oCFrSjRHtRxtpfZ0
tX11Q/UlnZeuSzdZE1azqWZGn6LfWQvVLqk9YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrYDdqGC42e
jWsa7zUlNP2mGW2WN59scWxpb5laFrNsRyvUWtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/In/F
sU67zuWdd1cmrtzbZdal77qxKnzV9tXoavXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW/riu
bN1EX3DftvXE9dr11zdEbdjVz+5v6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCkAVv+
mLiZJJmQmfyaaJrVm0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFak
x6U4pammGqaLpv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFg
sdayS7LCszizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+
/796v/XAcMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1
zTXNtc42zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvb
gNwF3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb
6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6
V/rn+3f8B/yY/Sn9uv5L/tz/bf//AgwA94Tz+wplbmRzdHJlYW0NZW5kb2JqDTMzIDAgb2JqDTw8
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjIyOTMgL0xlbmd0aDEgMzA2MjggPj4gDXN0
cmVhbQ0KSIlcVgt0jVcW/vY+/39vmhDRVOIRcuMmQR5CpOKRREguKVKJx5KoMbkij4ZwEYShpTqI
qFdJPdsxnal4NTeI10xHRhlKjaUZhLGUzlCPUrTKSPL/s3PbNaudu9e/1jnn3+c/3/72t/e5IAAt
sRAKGSNGxcQ614x1AXOCZPXV3GKn6+8x/+kEzKwEaF3u7BKb8ZstM+TdVcDqyncVFB/KrK4FvIYD
emLBlLn5bXYYCUAHmY++XZjnnLR/2ld35XtTZE/vQlnwnaHvkQNXyDy0sLik9G13f1+ZuwHlmjIt
14m4SvF3xcm8pNhZ6tJn43NgdqP426Y6i/MGBtXVALPGC56trmkzS8zv5Q1mJTS/d83Ic+GEdzrQ
2gZ4R+orBdVwBMsTpKajLWDekOd282MMNRv1ybAbheZXKkl2r//p+fEXhkqsJB8swFtwIBZ/wGlM
hguZqEICHtIlDIEmXnPQDcloQgA5MZjiZbYSgeZpefOaeYdvgbERi/AYs3ARufgbLNhEvRCKPhJV
olkAf70evbEE681/wqrF4Y+oN6+aBtLwe9RTAo1SC/UkjMU8zMcKCqQI6kPzES4YSvEJatnvhRq0
QDpexWhkoQD7NZIzdWSgii6oFDkpC+X0MtWau2ETVOGIxkDqzZHmEXRCBOLQHwPwW6zDBlyi7pSo
emqHESgxOXGYfCmAOtNRcwuCxdIxXpCuQAV24gzOUDCN5hiVo+8wbsMX0wThApTjAh6RN42lUj6k
9hgDzCJzn3lcdsfLOakYKrgX4D2JbjsOoBZ/FU7qqSNl0Hv0QCvRY5sWGeeN62aA+QitBOsYFGIq
3kSZ5OZ9HMMV/BvPSCMvak3HuAdfUb7a+3qgCXNpswIQg4HCVimWYpnYYdlxgmzUlXpRCV1kX27F
U/gN3sXfqDJVrf6lfW2mmJXmp8L5HVhhFwvHSMnqAsnaKsndbnyMGhzCKdzFQ3wvTBZROVVTDT3l
l3gPX9Aa9Xr9obnVbISPsB2GKPQQ6yUMDsErgmUqNkmmPsNZqZnneE4dqC+9QUtpOa2k9VRBX9IP
vITP8TVVoXYotzqlkRarFenl+nVLptVpVBibzGESnb98O050kyQc5okWZ4omtgiPe3EQRwXbUzQI
L/4SbSj1p5FUSvNpEa2i39FlTuMinsYuRaqjsqsuapkWrO3SzmtX9Hl6uRFuZJvd0awbb1FDf8Gd
JfZr5Msp88TKhYcq/FmydVJUe0fU/AQNchpLnn2oDYVQF3KIjZGsZ9EEclIhLaAPaRddoQfsx225
M6/idfwhf8Ffq+nqXbVZ7VN1ytBM3UePFRumZ0u8u/THljGWMusg60Trdq/PmyKaTjVdM1oYbYwu
xijjbeNPZpY525xjbjO3m3vMKrPWU6lKtNtR9GUT64LuUjnDMBwTBP9kTBdNLsdqrBHbLjHsw34c
F8Wdxxe4hi/FbuG2ZPaeJ6YnaJSY2pKdeope4mk8TaR8ctE8j71FG2gjbSY3HaVaOk11dInq6brY
D/SUnvGL7M8xHM+pPIRH8EjO5Tx28Zu8gTfzR3yQj/AJyfJFvsQ32VBBkgmHSlO/UhOEkblqkdqm
Dqp/qAuqXt1Qz4QbTXIUotm1MK2fVqAt1q7rXYWnSXqR/oHYMYuPpchSZdlnOWO5bbVYu1rTrBnW
j6x7raZUShXWSpX+7CeKq6Ru/JqgVPQp76d36Szv1e6zL2XTPAWO1qJE4+m4xWUqjJJUKXWQOn4H
r7ASDn15Kw8RdTf/RkoV9xIdjtbrtDa0HeAlVCj95pzoZ5j4LMMRhJn1aI015mTUUKBUVJ65UWph
IQ2jWqmhAp7Od7VG5ScKvaEui25uSe3HUYXlDMZzpKgtER8gAH0ln9cwl2zcHeOwUS2TTIegHSK0
Kbr0cHqs9mInV3AZ7zc/Y+Ab6XvjtCEE7br0/QgE0z18LNhOcx2XUY1moW00QjAEKS/Rx0mE8lbk
qVmk8UL+TqvHZe7L41QUPdZ6KrkNJU+LkU33yAu7qYKfUQjW00KJ/ibd45sowXdkcpNaxYV0ik5S
AEfSINUDBt+giYImFA/0QPLieKkji+jqFu9U+bQZdfoxdVVLVweg0V8onhuVjVMpXfUx7yPM8ky1
NC6YKUhl01yr+TR9K+xMx2XzuIrWnNrQhpqGcxxIa1WxnmU+NhboizkJ+fodayLmcop0iHNyF1Uh
gr7l9sJ7sKz0E6YCtdUNDZyJjvyQnqCUVkl1hEoko6VzVKGAKsVXl7tpgNwCz3mXdM10NUv6zAEc
F7XPl97uz7lyzxTSSLDcEprnPtgkanikvY658u8hA5/ok5OTkwckJSb079e3T/zLcb1ie/aI6R4d
FRnRrWuX8LBQe+cQW3CnjkEd2rdrGxjQ5iX/F1v7tfJt2cLH+wUvq0XXFBOiHPbBOTZ3eI5bC7en
pUU3z+1OWXD+bCHHbZOlwb/0cdtyPG62X3omi2f+/3km/+iZ/D9P8rMlICE6yuaw29xnU+22QzQu
M0vG76Tas23u+55xume82jNuKeOQENlgc7QtTLW5KcfmcA+eXbjckZMqn6v28U6xp+R5R0eh2ttH
hj4ycgfaXdUUmESeAQc6+lUzvFoKKHd7e6rD3c6e2ozArcIczknujMwsR2qHkJDs6Cg3peTaJ7ph
H+RuFelxQYrnGLclxW31HGN7vTkalNuqo2qXrzjkh4k5kS0m2Sc5x/+X8WqBjeI4wzO767uz8eLD
mBjb4WbP613A5we3e4C5lHgdYwNxeT96BhfbBBwgSFBI0kIUGQhSlAVCIqK2IRRIH1Jlk3hZEzge
AaSoUCpRElSpEk0VFGgbtYXQqJGSFrz9Zu9s7FZqy/mbf/73/88MuzspR+xs5TnGxJB3llO8/fb4
hyyCFzamXh6uLRPtpvHrFc7a9suKc3RRarg2ysfWVsSAr6A1d9jNSL2XL+L4WhTCy+etZJpaqzZx
SccGxclVn1DX2Rs6sB+ltkMWb4u6paXWae8mKW1S7KUpNerUl6mtnbMePV5E7MXb+ksspWSkprrq
eHhMZjWPjy7ITvLl4ZO1Qzp/5pvzWcvioeWkvCJ1Lk6BozyloJKUikbq+LC2jthP1cEM/1opvJw1
2Ib1Tm5jhx1Ocjn3d3K0sKrYXxJsu3rnryMlnVlJQAt/SfiUH46h8wX94NyJxZzKSn4ugo3YSNT4
uM9Pra56Pi3cVTeHFRAsH1mYgltrshZrHo3yXd2TtshqMM6ORakMr5DVZS6xamOtjtDBNRcHNeOW
cc2OQc2Qe4eK43uC8I//cU5IH/orCD8ytmld0qGP/Bf12oy+ZYnasmhFSmmyO7Jr27J0BJfR1w3p
sjNnbGNKLBOyM6FM9LU4iW1DxpxJ5TuShr+Af5LXpIMhHEVfQpVmJ9wxJzO25kWj/6dT2rvHvXzy
0C1bppOMjeQfG8GPKC/fFlGwpAstS1fYdt4IXTMeO7bdrCrNdofdmfZ2rFaVsGqfxqedY29u6hjc
0bR3Zk+Z07y3FU2so8lq/zWNW1V0oIl8K0QG3hp4NrQMd5bg8Pc4+Tgwg/K7GV62WfSQg2Ib1SVC
DgDLAz3ktcAMspqepDJ0e4UeLyoRWp7TRc4LxPsLZNPg1yTM8M7CfjvwIqAAswALmAvsBD4D5gOP
wWc7UIEY3wd+ySnkl4JtpFO65R0CPspZTuycy94HmF8Hfp1zmbwK/lfIf1Hc553JWe5dkbZ65wM9
3vuYX4Z+O+yugfIYHyHeaGkr2Q/+hnSLEvTxNeTfhSwNv/viBCILM8gNcYJnih2kTiLe50IPXQe/
KcA0cR+XkYmgljBj4C3or4CfDJ8U+KOQF2G+APFVbgd8AzYR0GrErkTcO9Av5XLYVqEfFXWngTbo
Losm2SeY5I5oek9LS0lRtu/DvG/e82BPfv2Zmv4DiMtjW8ORqe8hHtb2P/F71PQb0C1AHL3cF66S
d6RaslEiA6cCRWQPR/C32Pce+iaQH5zgvYH65khryFTYfyEd8q4LU4krvEBuo49qxMnh+4/1eC27
xwLA10QLTqB52Z4P8T6D+0g1fKYhzl3EvSNtpTbwHPK4wOs8B9auA/t3Cv4rcH6eBWpgfwvn73XM
G6CLhAjpzsa9Poxe5+dmOLJrO4gbg/DXrQdfXT3kEvK+CNvfgS7m5wn7do/vGc7hh+Cn81r8mnDu
+N7ndNHtQhf5CbAJ2B0g5O0sdsH+F0IvvduQiyvGKUIBfDYSJp4Ud7pJVtBQLPaTML5AFWAhsBm4
CQTINWg+AT4HPEAiheLP3U9fYefFI/QZehBBfkgOhKiVz7ql7hzcEbpFof2s4BDqXaTFbkmXkfYu
9q8t7TJOezvoVi54X9xNi3l+rEafGzetNEiNT/onTTZ8qk/M0KiWoY8qPnXVjHWJefSc0Ecc4KbQ
955oidHJSPRFf1KfaZwTd/EfSYbIe8zS2sxIGn22rYHB3X6txiwC2x+rMdafF3fiMWX742guqzXC
XLdopZHP6fxFRjmns+cZo3mIZjMPxMrVZxuFWmPKN3INk/u4lWYhN50+0yg8i4Azien93RqnzTTH
a1NXGmFNTxgBrdLMR/60N2BVaNVmfrLWNN7UerQz2hVNytGmQWvUGSXJycm6pDheK0bAE5O0Ok06
hzsVfkQLESvMChgvnn2PCaPYFBNd/a2f+W3v4D/CYFTE2oN9QaEdtyqh/BjMc4/VIu/HVt4xVm6U
q7HFvKNud7Lpk3K+Jt1uREGwP52KxEwjgrU4jadd98lvLjAMvcpsyPPuit24x5jeV6Ax0D/DJWkq
8OyvbzYinNYmjUIeqcb02crqTBrdlDg798kEp1hHn0TN8SBW/gSzXJ9iGOW6WYf8X1l5OpLn6mVR
wz6PVFTs5j+io69qxgK1gfqAeEToEy7gDiodEfvEC+I1UdoEo/2iyMRasV5cILaLOQUNU4U72Np2
jEeATwCR1GKsBzb5XB9OECULMCIiXkK1GOv9WT0/w76m/d80/H8HFV3RFe7g5+CHKFYJJVOohcsR
JbkUX8OkuBivtMIxIathlPCCoJIEkelMf5zuj2VWaULen5B3J+R1Cbk1IS9NyHMSclVCnpSQG8J4
mCl4TZTxkd73xw/8caE/VlmlinxPkc8r8huKvE2RNyhypyK3K/IsRW6Q6eO0jshkpj9O8ccJfKQP
ThTMKyC5F+gDMo/I4nEs7DjChHGunmBpocjV60FCbuQsaygRAnimUWhzgF5AylKRMInLKYnzRwD9
J1HpctB3Xb2Spek7GdLLYzaM4zcy7kV/RiJUA/0p6fX5H5O4T9/O0h+56ka4HeKkIRfXS5UnQQLT
T/K8q9dAvdGNb2ENY+gzyMnF60iFb9aEA8JpfdZNdSOH2TlcdCMCZ8kJfRt7AH/NZf8w0yHqsq8r
0kKvyz7T0xTcH6A76LLbcXDWKHYrfpt9Gn+FXdfTAj3JPtSvsqtaWoLhqbhv+K7uBzkWgRD2h+Or
2A/0w+xAJrZd4Ru9hMXstcayXWjpOfU224wwa9QtbFUm1LdVv4Jlf/S5JagHZIHpC+frPPBYNjv+
NGvWe1lj/Cp7XF3Fkgzyk2xGxW02XfVz1ai+e2UEzVl5bLLayybGe9myc/QSCVIbiFk1we7gd4Lr
g13BlqAVrAtOC1YHy4PRYFGoMBQOjQ7lh/JCoVAgJIWEEAkVpb2bVox/wxUFwpwEJD5K/jws8FHI
fOIJNCSQJ4kzVmwRWpY84UyPtaSD3mKnLtbi5C5cmTpO6aut/2K92oOjvKr4fXyP3e/b3exuNvvI
Y59JSPjcJGTzMM3CLjFJbZcAEkazlEWKQAivkiYhDpDwappWgZqq1HG0FqiCiQ4bQmg2oRLH6OA4
dqZ/WMfR6WMMaRUyVA0Rgc167rdpqY6j/3j3++69e87v3nu+c84991wciU9+CUW2uOPzzb4xLEEG
yvvqcNwcQZH1dXYAx8lzYxitbxnDKTaiL4fd5RIILNF3Moe10b6T0Siy7g/ZQ+YVpprG+v9QbV6s
lYfFrvxLAfHsefHTkeaW+GBeNF7OOqm8aCT+aLN7Y0uC9JCDDfUJcog10ZYEbiQ9DesYHTfWRz+G
gUcdAhh49aE07DByMhi492EVtikNc8FogBWwhsEuIJcKc+ELDAZ+xnDDQ66G+mGXS8Vw+9CQihni
9qUxBSpm5hMY3ohmVMwMb1SXs6mQ/HyALMtnkGFvPgCG870q+3MP2b40uyfN7lHZex+yA2n2YJo9
CGzl/1S21f0vRENbcx2OrG0Z1qC6KNx91NZq3LdC9QTT6PIjOeM4l/4OyXD9k3x1cdlXh0Ihu2IM
4tKYoIsLQBPhZfBaj703ZxyuChdUuA7I+kWWf6V/JWOBQzOWAcgZiyx7b60HFrmwyDIC2QSLMJ+O
lzSDb+5qiC/dDI2vPorsDW318Cw2HVC6uro6Ojq7WFGHFDZH4svh8jVcWNgQd2yujyoN9rb6zv+i
AxSJL4VBITZIFBviYRjU0QGTqSMVpSvd6epSu/9eOtM0FYqUjo/pmM0M8rEuKHYs9faIM1c9ekeV
gL1QCSRSH9Kjw+YAA0dxRycbzXY27HAefnBKiih0meC7gjhGtoczIbG+S5EkcncxcmgE/i6hY/jx
Ee3ZP4A15oPJ4GrjXLApGUQh6BsfQLWszGPymAqggiCCHrjp5IMwj+7DTW0S8sSbCylsRJeRBZWG
dchiuR0y4MMGbDCN407EkdHX0ArZkbXnjl2BiZtuTc+i0lj7rPGXy8rEquqqyoolJXhJYWVFVaDc
mmURxKxIab7AlVGxtqg4dKLvPW9FUYE5Q1OmNVmVFXXl0SvlELiqIFvehlPwbbkj6DjBY9R0hScO
bs8ptsp0k3EalSaXlWHRU022FSfvFeNUXx+Ma0j9CWQdQTJyJkAzA5cEGT6+c1Tr0H0kIKQXMLJa
FcbnZYINKrXBpUtra0dqWQ0vhM7UROo9qudPgQSNYW8r+jI9jyiFSFdMqIUQ1iVYpjGUzeMYCDaO
b4E2FldYbZxnywRDwX6+ROnvmQJJY1rsw1SfFFpIij91r5n/MdgQHUh9QP/G70BmlI9OhFdXWmvd
nxUeFx9zrnGtcq+3bXBvtW617XXude1y78/osHbael0H3cesfbaT7m9aB2wvu89lvWo9YxtyXnQn
yOWsS9bLtted19z5mf9AfO4Ybg1nS3rH0BE91jsKvENHIBF7h96mKcrT7MJxnIetqsjzMSbzXIwJ
PRuaZdJiph8iCmJaR9Xm6iqbVyAiybJYA+XVVZlmU0UhmTpy8dj+Ta3BNccutrS+0nb8ke7Dj0Q2
hJcrHev6NvA73nr/FwtbX+qudL71wY33seHExoonFt7948Jv39zRWrQb83gIy0+1gdXcYKpJ0EIe
OhP2vKB5Vv6O5rT0I82Q7ppmXPeG5g27dJv+mbtpvW3jZF3e6/gcciAH7ka5+NPhrDxqs3NWHgTL
pGaB2jgrh+UxQsI67VAG77DPgDV1umvEBlvm78iJBMg58gi5ZM52jeN5fDutgabpWeP8NNjMmAyG
ktNmWw02QQVPyewtZExi5s8ohmPFuBJlglcX+rzikhVYdWqmJuwpr6oOkJ8lY4T7QdOR7Sef8AWm
nj4ad5UdnVpI4PXrdtqKCvAUxt3HdxzvNx59Ybi3JdI18PbCO/U17KiuB084AzooQb9OIEtqMtxo
yg3F/Hv8nYU9/lP+b/u/L/3QftE/QSbEUSlhv+Y3bEJfxGSbpctCeKLN0BVTgVppvuW7/kH/T/x3
skTOYrEQyzg9BdPPjWBs8I5TAyqCDC1HL1/FLyGJQB4Mfw28whIxG9UjHnuuhE241IRN1/DLqAxJ
eA7JNAO83TZS6sKuq+Dypeg63YhYMInNzYHaYLfPsV01Nx2anTXXlM5Ox5iu2ttxe0zBlWoQ+KS6
BNGJsywG7PMuxgWbkwTKAVSCcc1fuz+/9dF9XyioOPfk/hefP79j59fuf6V3pRIoyM429jQWbOha
M0hu5BXsWtW2pvWrcmf3yd0bBz+jnGnvuf/8p5xFvnIN32h7c//m0zHYXWHQ6Q1+FZIgsV4dVgwy
PijjDKLRBVAVVy13SP18v/Ar+nsqaWWtbpvUJXHrJbxdwjyLwjZHhQBtOAgdrCMQVjUU8aKGyoJe
R2QB8fyMIFsEQZa02ns62aLTanSyRivJOr3IUQgPGQbtBP4WCKIj50apRsMjcMzvhSWpSEKcUMTr
6QQ5D2xCyAjSStIYvndF1iKk5fkxWjSqham12nHQvobgUZ1er5PlCVqMtDCfHJYFQ5FsFGyCQbqe
wDfBHnDWKkpQMU7iOeXAu9heCrYwJqfVI1g58BcgKGrPyHjQfAgNuLzCTgLFOItMgIfT4Ibq+f2a
EoXvMU71l9gVaDKgQFxQlKfb22NgWy0OiD7qy/RUY4o99MZC8mz+q21f37lgXUpLX0wm8AC/6sEz
hxa+gXefoLsXFpLPgo8/Bvb4DdjDi34afkrwmms4eD2i4i4Tg+61/Dphrfgkv0XYIrZz7UKHeIw7
JjwjDnADwivcOWGUS7itvRzW5Npz68Wzwh2B99it1GnGJF9jz/F4syjH3fMii9eLvBxFnNPMUa/X
QOgMnGo5cDN5zaA3O3zOIc1VooV4e12NfsZ5CH2ghaZZdhyCBszpnd9vSH8/04pKqqlhZBYb21EM
zmoPpOdWm5U5MguSH7kykBZ9eQkx4p+XLLRFzm74J99VHtzEdYffe7ur1Wmt11rdkrW7km0s10ck
bGwrtiTbgMHGHrCZOI6mZMaAOWzjYgwpabjqQqAJR6HhLBATk2AmpD6FMYakOYaklGlLmg6dlqNc
SSDMtA6FUq37VnJop390NKPdfZJ29L79rt+2xXvqOzoXFmf406aGMqyco31s4cGNVNVbx62zV/1u
2/W9WYEsZ7bbN5XXqK4P/Oi9mUmYFRsm7pJ+7AgGjNcHg0rWzCKzzMcqU6FTMBUKXD7h48JEmFtq
/6F9o2a9ZXvqLs1uy37nMeKU7qix1zlA9NODxlH7h5xRaTNxZhtRTjYk4+JAcibOSroIBBRReKDf
5dJCnBVDgLI+1uocUcgHNTmqUhXSq1JVSCV7qeoShNDqNvXqR/FkIeLkCHyHHQ6P8UgkkRwYvlgy
BiqOmM8HZNPEJoDhwtbJKQCdKAEgniksKMiHiTxh4wahIP290thLy8vX9Uu/7nvz+BisONUsEduX
T1/5ScdcsZRqTs+QJi5kRw8+kN59cOgi3A6d5Rmxo9KlS8vWwpo/d643yU56F+OWG1f9sdOAnDjf
X1Lrx4KOH0n5KD4bvw7q8EkhKsLuqaZIMgoPBbUEMhAEIgk1Aur4vimFzB7sjCNEBlDB5qFUNVRb
NOQofIL7QBqgiLUDMBVBNIplqkVsApfxSABbYiJSMbdkZt1kMX+esioeJzAS7388B9MhLyhoEb6G
umPKWrRPGut6MTiFqhL+OeYhj+Q04hYyB2vnS8wGE2ZuLvgIzy2YCkuYQjp5mbbL1GUhLVSRrjC9
UjcrvQ42wRXUKvfa3E2wy7zJ3ZW5Neuw5oBuv/1A2p7MX+SeYHrt3e53PKdy34Oj2lHdCHPO/nWW
y2PW4p3q4wev8zFLeR8rdHwv0DN6pB/Bjz0DvhnUJDhhycvuJUbg34ANr+lKuQXceu4aR3LWZ7AX
PS0VsYcJDGIPJ/mRPBmr8t6xiKCcA5MlrCAb/qcjlsAEITiDyUgnwThH5BBB/QsaHg11Xzx+t6H0
kzd2DP3s0+WrV0YaWh2Zjj37Nrf+4GAj+kfzUGP33z/+cfuVhS2vT+8639PWOsB43m5ZtGpFQ1lh
3c2Srze3dB1pqzuNFVaMMb0fx9QD3j8NeIxotanQhsVFCmVTi8gxzacWgnaazUYnUUzNphalvmzu
TN1q2ygcMh+w7RZOUic1J5J7zb32HuEMNZjK1hsgBAqz1exQiBQJVFhdw6IIHI/1lKywIAt01t42
9hqLWGu6HqZC5MJq67+mhVrMtsE2LDIL7mX7JiEcl6V1P5LA8v8KTGaSCSdtCSyQcxUDCuJQIoCb
SUJdCaXlFy+u2vxF3bPlmW8cgQWnDp8YlcZ+uQTGXls2o/NXbXVpQbPLmDnryg4n+5tXH8D5D458
JnVINyqmoAbovN6yRhr665q1Jrm5uqUJZCe24KbNg/I+La+IEjuDKkDzD9ZZoEUu3X2qlXZ5RNCj
waBOW6I3phqR0SK01k5u7d5NzA88K+BtxbfxX40cygT4n7lBQcOhzAAu6oFiad+SZ2jie6QykJ5Z
MjtsbiG2FHvlz7zFT/YHylwGvcqnSTZkloSnlm3ws9Pk//uiNJ3Own0+DOpwF+joAT2heyGCxk7Y
aSTwzJBxtvay8S74KvSwgupiNxl7uB7judxzeWd99LzkuY55FfUzGmubmCaOdrNeu3tGsW62rjy5
nKObwUK02LEZkC+BreBJiAiFw74wqJmbFw4hQGpIa2ZNyIfIMhsYRWOgBF0DZWhsCISZMArro+jq
QBoI0/YoGhuwYDXZQlr0F1CFboB84ERXgQl9Dmh8zEbDffnquSP4FiT600BeXv18zShez0RRYEVX
g4we/9Y6v9Cjr1xfeaSSqBxBV0AKujqkF6BgqZ9/Fv0R8OhDdBaYYUGX1ztHtqZYJOHf2Kvk7I/d
AqXjMdzoYrcjzK1S/Fgi38ZuyXqFbDz88JeYC5uZpMAk6SKRadNwF4DEdxLFTENuUSAx11jS5wIp
PgR4wY2mMizmI8liQk7OE5MsxWMFfrymAlqQO3T8JpjCstSp9atCdq+r8uKut6TfD92ROu58Bldc
hjR8p6PoeSlN+u03UvONR/Dck0uw+t3uf71aVc3u7iuf0Xr24MrGsgaG/2B2dXtt8YysovU/dU2r
JMak9mtr3K6sXXBmXy8UDnwr+R/dlra8D61QL30jnbwODz2CSngBwl5p+PSwtO/YzNC0xv6l65bu
hM3t8yoqWlNqOj7a8VxpzXPDLxxuCs/BnJo4CAC5gFqG89kDdwY3EBwwkmaCVwpqUeGmtSLMEUvF
GvH7Ypv4ivi6uF88I95xPXRpKJ4SKXcu7xNy3RWOCqFeaHE0CYvcnYZVwtvCZe5z/gvxD+6UNCHX
kMvlOcgpIMuWY89xkOlBS5E/LZhS5E/xiKzBLYocLwguNatxqB08H0W24CyBdzocKqh0qOyczWEX
OU7kBQPPCyIrcqwTAtmj3B6DR0xJUQmAcNjtarVKSQjJAhKAyHMGN8mm5XKQk7NSU+TnokR4WHxF
CFpsfmFyTYgSJYNAXgGTKyAKw0EdDDJFfj3MgTW4FkaJOYNp20QBuEaI54nGeEMdj3jHvd6HXu/4
bW9kklMReezCr1K5ft3HJ3JKKuXumYTLJ4lPzIC5D5nzT9+V955e0UlMgKaYQIAOBOIFFbMSRACe
PSARzw+jj+YL5JEVvwp4WiGzzISX8vPj1ZVMXazUp4SqNbGvNKbQFAejUTPSy1tzzP6ARmrTzGpf
QWR2S6thPbXsyd4aSwbnsHs89pSs1JUnz5QWmF3ZyOMhInvJOVJ/7EvcPrZOXKeOYk6kg+1Bt5sp
05QxLygWazrUnZrVzp8wP2eOgyEwoNX1sB+zSKGHKAqrgyqle5fSl+4iuChKGU5uMquAjD/h7ENb
cHCE+9K3yDgPGArBeFKUWPdvtqs1NorrjM6d2dfs7HNmdmZnd2ZfM7Ov2Uew116WOt5BAWwCTiJB
QkMw1BAnETQIiiDh6aWAIbFEFJrGIjSlhUAEKEXEDwyhQJK2+ZcSEqkKlVqiGgQFU5Bo1Ah76b2z
Ng+RXWm+O/fevVrdc77znU+nRb1lVkHU2dJeEYidyc6NNVHVtLarYxrM52F4qWPD5aaR655hoxkD
7YCQEzlCvp9psF+1mOSYgvJQQdYVTZl/36mYzErr8if6uo90PHN5qOfb9vzy6u1PDt7Fum+AvV8v
Wd/o9ytp87LqzOVNC6cnFm8cPvXpn69t2Hz0QM/o2/8AH9zMs2weZsfnGGbeD31YAMti/zyBiXev
6PXeUl6bF1ybWKf1JAZCFifrkpzAh0kgKIoh1gc7Vp+cc2ZyAHfa2FzSx3pSJ4kuzAI5FufLlpOA
x/LQuZFMaUUe5IPfiCcJgPmI6f20mwXsEFg1mCNZns3ZT4JV8NzxngjezMonFvz0BMberaBz2CEY
k34j6lQWTuj+Eqt7S8iPac+DtuGx4ac87ZCmbVfRAZBrSA1HJtzbQ3Q0fBwoRiNI3ly4SY4aVGss
MkbbawYG4eDdKsXGWiUGGQc4BhhA/vaFVTeq/z439pnz6WCSkZSbYmE2aKteiProwJT3gfO5dbsu
/q3BnFA3VW/t2Xand3Ceiju8UrqLKHQUE+n4KPmLoCdkJqfq7WDGuWuXoPu9ex7euhveehEc0g/q
Qr+AbxN+LRwQiO1id+JdsTf7YfDD7CemAXpAPJ61vyyuEbsxwuxm3TMFol4PQufjKwkxxtccCAK3
GwNujwezZlyuRTbJKilQWnKFYvF0XspZWnG8wyxZglt5/mZACpoyIKNqUgbzeEJQXhRFLeYyeM7l
dvsyOJ+TbMrkpKp4LIesukyX81ZgFQ8Fdd5fCEJmH5daCsFduV1Z5Mu5gFjYm/1PFs8GSvhhkHcd
dh/CdnsQ1KoBtQIUtI9i+YICUaugdwj9ZFLhlckG9FMegB4mRQ19BbJI9JaVoRoLlHEWoDgISaBA
EjxAgNuXb19G1VFruz2qacP5dm14ggsjZShUTY8Soj03ch3z/Bc8FIyV2tDQqe337L82LlYwM41k
JGTEmLgs14Srvjb5MJ3kYtTYlogn4jLeu6drx7qM2pOk5ccXb97CCN5pr39+rV2t3LnifCqYpIPq
DbGhzecgvpyrWgOxqY99ZCbGrsxZUWWbM1pBqJanxgKs680j1e2QWLSY2kLULSnENbV6IhduUHJ+
GjHqLIYRrZBRIfCrfhBzlzjUhOpuphkLuyP4s/xupi9IVCIAJwkJJ2lA+xmJBgJMaq/dI3n9ghAi
7SxJ2mkvjgMbGU7aSY//FM5gAkTUjjO6l0ZdRZ7sIt8izWTFXyIhvB9rDSgcr28g9XiigMY6n2yo
kGfJc+RF8ibcCbEndbe3mUToh0mSJ8MG+swD6MM7NkBFFNB9pE5TZVJnHfDBOeGDd5WNk0lIDFIP
0cZbX4RB0WAJOc4SY94dMuLHiVLtRz65TFbcQm2RoidisxFl472ik5BbpJ5kjdVjbI1jD39qjJug
FyyEiFiuHyl8iGT3Zad9paap1ocIEocEscZhlbMiEnEc+IEaO++aG8z4ovL1UKChzYE7KD2czavX
IkJRVZGghPJribqXCgGFUVXgZp/sGv1yZViQGYj9F3e/s/gh9ikwR19tZXg6yTbSU+IzsOl0i+8V
fC3+gZ+ay6zx9/uJLQBQtEOiDJFIqUkpZcdJyS5y0IRgABjqDnDWhwMgMzTLAIyhVUWROfQ3fSmK
stsxXBJtLENyTDpJMz7OA/IMNBo6y+pFEYp0nVDW2RVshf0da2KHiGwfie1Gma9THNrAoQ0cwodB
JD3bl8oWjCgpRtSFQEOZe5rr4t7ijnJmblOaZHiOZ7i0HR5y7E8GaSBrDJdifMDIsAYVQANVBI4B
Tw2fmmGZQGm7DfqUe4NHKsSjT1SRIXwA1JI6lqiBhnoc2bAtNYdifEE8nijis8D+f4mFFoeTAv2O
adE8H4lWP1Wqj98KTlpgrz7neiaYYiUFOBPPL6TMs+98SwQWN6ppgAD1RfOr7+wzvT7a97P6eMKK
IKelzCbiaFOWUGFntA46ltPQsXigj/3DQCQGk4BHKd4KBwVhijglNk1oFWfF5uLzXHPYZ33zpYWh
Tt9ScWl4DbNO3BDexu6Uei3vML8R35P6fWekP4aCVpeNwb31GBGot5E8MixeB/QqDn1Bg0NvebHg
6JQjaNZv0qNTyyYd5pEJrpnQmkkXGkxDgB9cAWW9c4Ff87R/b4Bx1YPiVSS/I0YDAnGp41CTC01M
HJmYRoWPWe67G6PcEre2n1szVn3lwvtfdx6vgkjlxTOnZi3Y1fvC0UWv7dtlXrb60voL1ehoz/Cy
02DVD936ku8GL36x8+/zX30DHBra8RX0MX+FLv9/MAdELAkKumDBObwlukN9J7pHPWA9GBm0DkTt
FjtII4Ytgv7c5k9FfxKdYZ6XXK/ux49EB50no6dViot5St6Y29MsJe12KZmkaA7qJMaLEualoE4m
KSrE8TAXeLtNCsdzmK0+HPZiOO212SWZSyV5ziMjM2QCfF86+Q2F6iGPM/10hQMcUsAUCX1GyuDy
5gfKn1H7uJqaGekA1QzGynGoSxyseWhugC5xE/7nngH6fsL9wPavhGiP7LlnxFuiSz/qhO4b8iar
a9yMa9jKdhCtgyghq5m4x+26cb1KMAiqWhZYgY5z589trY72Lnz75/HGl+xjl6ilcx67mCx1/GXl
9Ff7OjdsmtZhnj3wy5c/Wxur7tyajqQtqjrzAGHqycs589hH0vz+js41XtSbfQVR2wdRi2OTwJv6
RhtHJprSrdjs9JPafGwpth57Lbw2+67lvezh9An+TPpMznvQ0m/FLSInvpEliMSkSSYH45QclMku
UQFWkALxmCrFJ5lMIYZlGYaFjVcIAyyskFGQyucCqRzsqwJ4/P98V2tsE9kVvnfGscev8YzH48c4
Y3vGsR0y8diO7SQGEw/sFgGBJiHb8FLYqqU8xfJYQcuyKdnCLgEtsIIiIcouRdpWWzUUCAoEdimi
UKlU/OkKqUKtViChFf0RbdVGW1WQpOeO7X30NXZ8zr1zx+PM+e53vs/lcjoRoyoYWVqFtmafwLWS
qkXIg08XIqQAjZFqFIIQCdLzOJ97YCEF9VHCuECalFDrP4LZQqBkguEJdQm1BiPU6icsCJbI3FVv
CdqomZK7CLW7mKfgLsMCFghC2oDwhLavsF1dIH151MUv2Wtf1j9Qqnu0GgaqEGDrJu3/ct4hrjx0
t0Z5Cm1NVeVN4OuNy9ZRRYlNiOCADRNUVEFB9z9c1rs7IPu/Y5/+u3OpNEeIxSeD3Ytc+MYnd+9d
PJj99lbn9CqjbfR3Q0OxVuok5mY29Ha0BL0MGDNQy5nv0/kVad3AiQ8OH3goz7x6YpU1Qf3JfuvY
9j0MVA+xs48tA8B/8/C3jDffbH0jQ61zr2PXeba4t7PbPdu5Ifd+dr9nHzecHtbPut9lz3q4ZtTi
LqRfSm9U1qdfZ/axu/TDzFstb6V/4jrDnuFO5T9AF1wX2YueUe5n+i8y1/GvXR+xt7gr+tXMlB7x
633OXle/e236pYzVCm5lqWsxu5Q7qFs9abdusTXLYPwMR/N6Mf6Zoog09SHWEUIlmORt+UIB2TnN
6xiNZbNZKgtLx+MjamxEBZs4HlUeKZRS7YAkXAmFCyQaYTVVyCgVZVihFWm+Nuo19KL3PpjLeaa/
HD+HHkEnIHILFiIjUEQ3cDsq4/bLVWMJO3n5E6j7lDZpauIvxoMECgQbYDQnSYCEB7iQcu/Cg2gn
3hkQ8jVGrsrWFFB1O7GbAX/VctaEb1wlyxABgRUIPUWKz+5QbRePHhiJZu5/t1F/8PPOtuiKuVYW
PFBjcpNq+emBTT/qx9qqbff3ljftSknzlCj+x5Ls4dHzm1/s7P/D+lzf6mO/d1rVAEVHcjNd5cTe
M6/1Lto/8/j82o23t/g1Ty/U/zg4pjZgCgVrRpwme88NVD3uxoLkkwWvk5e9DfQIFRtRKA5bMf6Q
ZpADKcSA8CWFQ1m0gzw7mjG4MOcAFpfCPkkK2xsd4Ql81vAhSrmJEeUQvIykNoc558deidQGSmlG
Ta/G+JxqjMTMaDiDUmG/dE66KNHSBBW5ptqlgKQ6Nl6nl9b1bbUUmgYUPy4RVUsuHAuUpJr+JPGa
V+iSiDKqcfukVlOZWqX8vMxNl8vlOptrr3F/HcTBjEayR5B0amBVJrnp0n8YXg3XfUg8bjrcfB72
c76tox0US5x04ThutVi3J4W0enTrzFTe6NNd02NO6ZstcqYFh/p2H1/VmGhYNnO6p2tJovH5mktz
krlEIsSvfoe+U961GRQjAl1yz6zLEsNAduRw8IyPCVsVq8gbHOXt5OeL80KlWElZzC3jh/jXhWP8
cfFd31nxpsh+L7o+Rp3lf8V/xNOxOI6bql4tkDgmF82hFDaHV/S5ZjRaW4p2j0O2S7GwLDHYJjMh
PiiHPOBnCc9zPMI8x8WVmE9RYhOzewwvh5SYFArZ7QylIHuGx/wEdWSM+6Fyg+6Cf2DhODKAuMm2
MjgQBh4UArAMIwsKqfYJuu/yb4J1/gXW/XzqySCqK0vtkOXfpOX/ZNeqkTStZLXVR2c/GYPHMmGG
yBeeYzXh3waTazUMepPFIDdpDARM2jBMWMkUxh07mBcWNzmogHPlAsHh7KX4Ab9Hr7jwaUdO7ti2
Z9oStWweiKTLoC3VOf6Nz/9IfbxbjwbCzZZEwuKRtpx/9jfYVf+cfWw7CtXL4UcGb23FbovT4+ZZ
weOz6lY3ee6w0cwu6PQUyNjgIcFunFVdngJrwIdptZxFhpycdBYFAxb4yAcTAbsY8yQc6Qa9IZdJ
MKIu5nqUHrUn1aP1pNdF16X3svvUI8IR33vCe74fa2MaX0n3RHtidCVV0SqtdEWtJCpJuhKtxCoK
raf1LBVozLB6lPb4oj7Kxwqyj2Mw47LLDCdiMeyXxVS6WU7ZsFW2eZKZJJWMghyIRiJxPe3T9XQ4
Eolksr5MJJrJsm53PJf15XJZl9ttgsfNAh5c7iwbbpQj0bQTpZJJEQwRw9ioXEZH9iwbCUfT1gws
olF+gh4Y00cyE9TIWG7ExI8zNAfwEwWiCbXdwD8wKcCEzvLJqcknfCAPb0BPuYYf8gIWBvRoQ1zD
XUBTsJow9aQ+E/yaq/wvRrMeTMNZPapKAe0kcmEnqoHK9DAmor6KJytF4y5cmzEhB+4PY3G3beGA
Ez93buhmu2HJwm0MlXC+rAQVBw1femFRU3Yug084iis6Y+unVyZemV4ZtWxZEJ9bpgB23Semm+iw
j+0s24jBcebm8TMrZo5Rb28diDRqIAktrV1NZ559apGefQpaEGVnn9K36cOgBYv4oRG0xxiliA/i
gy2n8OnwyZbT+mj+qubMEtMTcPkq7/vfz1HtLUtjlEsNFV2s2lxgybkSJJVAT+DlAD0/i10GDF1g
Vq77HyafJmlMWSwI1HsCKuty+1OZtmTCb8mJrXk5OUGfMgSUalJVZGtGFktUTPpEMZmZmP3zFXBZ
mQlaN9ySxDnF9uakyLmPuG7iF5CFopEIv5++lrwgGrBOJEhg44kCEjkxK9LvADJBCI71F8Wb1CnU
Sr+BvEgmlFYoyGRtIJkqyMP9xXPyZzIlt7WLAbHd0Xan2j1qys/kDHJRb3OFXHQFWoUZg7UxmDMz
emrz8EPMKFTHlwOlunZcvfwvU9ogwGIKesbnk1XxaIoDra4WNeBDohKeYL4EyoEvwRtBgrl7h8h5
BpoRd/cuARsCTttFuG0QdV9q6e++NLdvzapbqDj7ABXgr3n2KUrNPu2EA6hNw4OYtpnCkjShjoCp
IYqFjg7wg2bm7QDR4Q902FQApalHTOajb9/x0w7G5RZTC9RvnOjSNL944JWeZUu23Dr56ob5fWLT
b43FG8692Lpt+JcL6cPTa9a67ZzL/i+uyzy4jfIM4/vtrrTSKrtaaSVL1tqSJa12V5Zt+dDKkQ9p
4yP4UpzLCTlMTMjpHERpKHWTABmacRuomSa4DCmNSVNC2xCgDmFEOUpp6EyGzsAfnXZKOw2dujMk
jIbOEDqlrdW+nyTTwh+7r9bSSp/3eX/P97xC7RbvngOxaMvq4Ut9LVOTc+juyfXG0OGarrHi/HTf
6Pnf/nlsBPdeEveeaYbwEDIyGcIWCVlYxFjXEBtNr9bQSiWo42oY1b6Ew4RQWPZ6CU8/f0uravZk
vRwK+hBPEBoBf/UGON7FcXxQ9qeCKs1wCz7ZZuMiGs8J/jx1wrAzoPdjzLsMGWAQs937GjSRB8kE
Bz9U31xy2nlNLxWlVPDPc2WL8SXe5N7j/sZRXB51Xo1wHi7C5snATysNs5Q2FgqL4AE3l+QtFDJl
fS1lfWFaxIo6U58WYv9Gn07jeRDnf5TDUoKkVBq14axP4okQlUNEiNEpHAad5SDIkKNvTzy26uCj
+eKt6SfmUHNY8DS6Y9EdI3e+/siW9Pi8YppZzO4YOn38fPEX8znaM+X2cU5G+ec/2k+g1qe27pk9
CXtQFzz7/cC9hjhjJaRaPqPhUxPRgGJqk5Ym0qjDlFbT2qPkI8FvqZfIH8pXA1dkIQBznI+uNvnU
gGY+qaCvq6fUi0GqyoTq8XNz6KVSVSrAoz6nvaCRGijEVTvyiH6pVmaZCDjGFUnIQP2jEfKnIipl
I667DlWrHAgU5zLcKLeNo+1cgCM5X30Ia+c3w1sZ86h5m/leM/2Q+Wnzi+Y3ze+ZTebqaGxD2fBz
MJWtEoq4FgoL8PRjMVAAwQNPCdfHy2Egh4kJAjFNQMyrEAg+hPHzQ8wJxHHQMFKBwymXdKgAkibL
SpiZSlxvp6Q9v/nqzNwlFHzkwH6lJhqI2uOsWKtvf7Nv7ZEd2Sfuev/4fU9PP4m0V7b0pBtCml+s
a3TZ3Lzr1INnz+66P7sT+h8QpddD/8dhvnrLOMf4kStUbc/YwDhZOGxGsivB4pPNm9ATNqO1DS5b
9YTE+mx72b22G+yfbOaMe9S9zT3WRv/vtlBHIqkP+gc7x5qm9e+i77nOui8SL6M8e7X2pcQVnV9P
IAWhT3S0zAsfZfHnSzd1GxG92wjL8KJGd7ncYVlRxP0sYm3xopJHnxiK1tQcz4ZdbalmRepIhl2U
iNmjiDgVEBWXKCptch2Tyv/n/Xl/KoWd2+b18jaxS1NEAcYA6orygmjDncEmYZ2t5xK2UyzO4UlY
ee+5BJtHvQZLLcRnCVEQSbFs4OLPwMCT0AO8BD0gwSIlo1ZOSGVcpVI+Alf/WEJSdZfoEbvY1me/
SCVYb25h8e+xGHSEcPsL5psp/D+euFWc2HwxpRVIoXVKnFpKoJbdPAc7PXhw7DA6vGTwxLi1HPZL
FsujUt9k0JcsVixlygrUGGeidAtBry/+qMZh5Zyh1aGBM0aowa9+5/61wyO5N546uju5StluY5bZ
3UGPLg2lHih+3NO0B/Cc+deOCT/r5LwT7h3HmhtSE8c+2NA5fWQWrZ0ca2hDWyNVms/NO5jI4leM
VcWJN4ZH0VvYdw1gPwfs+4gIUTSSdsEW8QreCE1YBAvpXGdZYyU1a31kubXTP8AMWgatA+wWy0Zh
LHKG/gH9jDhPvxwRVPzYuxXdGqpxZCwhCKwWq8VqkgiL1V1HnJIMC5vmpFopLlGSZAvLTsak2mx1
HXZ3wE26fSoxSGKsPTxIyj+krc7wBnzRHI/4aiX2S+/SDpz9bGEVqJgtAM2ZgjMVH48VKioRDox1
WRLwztJebQVjgaVYscE42IylUhlcrcvS+HoeanlHxqFfXOLZ8yXsGbMKUiXLlnubeWDzwMmH3YXf
nX48j6rOTO7q2fjjQ9ceHz96VG/Z9Vc01RrcdLxzZ+1H+Xtn0fLLGzrXjdzTHfU5ou1P9tcnfk8Q
qDhXXEldB9Z7kfoKQcFyNjdmKPwMxbFYxmx4Vnh6UgTt7De0aHnk8lWHE4QBp35Avt+ogsMLBy8k
+vHbjZweDKlqgCJ7e+iwTAfIXrUH0lNAdcEhzEpts91yI4HCBnx/OI/2GaIsE2ZJttoDfZoaEJId
qZbmPFmc97RweZIyhGbRAOQu9wU8gT629Q8Vgm6PLxYWC58jUwBoFmNdmcUFYWEptyCcVECS6WvX
+GvTJuEa3/U5KJUMRcM/DOsgcVSU4AUd6vJnSKPLlQmFGjdngvjUb4hLaWkTwnMfE6ZIpsSPCsok
K8KUY0waAWViuL38orJpliVc4gvuZMh7nKcPDg7tndq6tas+0BaRIm6BsYqxbUNBvvv55/l1Pe0N
ncmhCwMjW5vkgOqzctWZ1l5dGqByPcXh4o1zN8ZWyNVaXTxUVSXyjNXEJPftrP+IfKbHs2LT13o2
bco2hpvlaiFu4RlW03OdtwgQ93pxJR0DvuJENzGCWCN1uve88yfipaoLvZfveNH5c/+rgSu9rHNS
mByeEqaGzw4/N2x22O2B9JArnR6yO9JDdDroVVKnLHmqbb6BAFLOGIH4r9rkBqZf9tqdDtcAGact
SnMyHVwWRrP0QIvrdaqVqCGaIefSVIthjS7rCO+PruioeQ0CDpgnEQW3rNejuHfsipYQoui9KIq+
kn1nxIt9ModdsiDgdHpTWIQQihUtHeVS4u92AdQvAHspmJ8q6rc0l9i7OhziqjJ2DNpStQtpAQMH
tSIqSFqBq7SPBlCVB66xVzbBHAS8tWP92ksX2C2ZEn0lQtMk4lFZ+9IQpdCx2mfFQ7m3J3WXPPjW
+UTb1M1vH/v1namY9EDTmocPnvjs3eGJxuymgdyZu3r1e/q0YnDNuq4NFx97Z3h/JzW8Jxn/xu7d
troGweEKOhqVhN6/9pvZzh16bNwv3iHHtM1J98zGmQ/8dd9fvfUvR7PbO3adW7wvcmR5Tyx9d1Zd
WbUMMlQUfPQ5YDqJRo0DzvXMhuiFKLXXvNe6z79fnbJO+Y8qR1XLOmKfQq7T8d6ui3AgRNbHGhr+
y3fZxzZxn3H8fj4nxuezfb47+3xxcmf7YvvOPseO47PjOze5QFJiQnhJQlhCDGUaGmOU19Ly0gqt
GpTQbt2qQScV1la0m0ZFaQNkKWwdf6BOTJs2qVL/mbT947FKa8Q/qNKkYfa7OyeYwRbF9/h+fomi
5/t9vp8HoejCUNe0qGQLo0BIgy4EceA4HwrToVAYkZGCzKe76HS6S+i2O9IyFnSFimI41JUm6NMU
zMkruCMWXgCdc3gsZASkbEPnCp+nDWqFsGrUOaZklnbFPIW5btZk3qw6qSp30yDNFkNMmgkVsdxJ
y/JLo9eYvjXYcigJc19pTID+MozMFisyoQaCKViRZbJdisxXCM9Lt+DGYg4CGJYjH+UgcxUgc30c
jvZCKUDJ6E4QxEtd8AEZ4K/zFN1HR60RMOUEZMPvaFOm2qy1hbKmsiUjLxBA0bj1AsU2Vf/H/B+q
Wb39KONzuX2lXj56ZHM0lhEOBli6IzY4FTyVDOlnQUVI8WTM3/LDfyuAvLqyuHJrvbp2hYd0y+so
5Xh3JiYfBj8aSdHBQPIA/5enx/9oP/xim9iKJoz0/MaDL21dLQHEhUigU08we1Ql8LyqkCmdVFI6
G8pP4YAVoLSloci0KGalURzZ17qAntPbcIeIe3HJy3MRmuMiIReXFCMcwZwOwIZe9Tr3ofgCWD2H
PuNdAMKvpN0kp4cUzmiaquW5RvOMqjthNzmdD1t3FBXIZ7nXORvHJjmGS2IvnHxkj7XGsO7ijIzl
dDe8GF8WcJu1saVOjdbu1+4QjW6bvW5CI+TrRWKpuca+UjW/8hqj43S/22xfiYHdM55e85YY3Vtq
THI4yJtmM9XUzyU0Wm6oAn6fVDVJ0tTiZzTl9vpLqjA4M9gn5dmXw3woMNQSUJOSpklJtX7w/qrV
HoIm0uPMztVKdyw2CW7uaQ+0u2CPABKEzvwndGYPOKhvxqN0SdHd3ryi+xVFJxTMheFBF4uPISd8
7xOOItOvPM1MMvZQjI23pVHUZrcDiqaDcMp0JnwA2BNiwiciHO/2ebJu3O7K4j311AJo1/1iLtsz
itDBIN8Zpzs748AOELuRtjlfgvb5EiARp+14AsANCIJyj8hLKVqSUm68VRIx7kxbIupKSYS7TeFO
8wvgk/lgrXOBrsU/RTNQaj9ARLihpsCNudznkmnsUF6yHG3eQlSQGqIw5zqmKhKblxgTf2HrGx6u
3b/zNXTx/cV1xB3YWaR/9H4Nuri85GLLvdC+1lBfNrYx3YNIo+sIsQigJMwrcduxgiivKL9iXF8y
Qt9D3DK32KqpNqeRybCnXSAFihGHBxg2haOeaYLjRBx1oNC6S623ravXDtzoJXFBFlzgGjbybM+O
8GQgXKAo2sfkNeHZ57JJRqzOfvscWNveEhOYHLSvtP1na1m3k8DicXsiPtKxdvh7X4iiLz7Ozm6O
aODsC/Xz9kPbWSoYxgRDF+uhd7dDXXQASV/jRACJ8IDX25QJZKL9Lv8vxo6FXVmX7trgsrs6hvzT
Ynu2YxS2DkU6UJ700yTp97pITvSTxMM37saugxvwKzt1HI2RCAlukn8mbeQC0HSMc5IMyWEvrG3M
ViNpTSIiYd8YTz9pmjnH9pO6SJt3V2IB65QS/PA0Ak914406EbJe97KNT3kYeOq23n0tWCL1wBI/
LVHUYu3eV9X/NjNs91JLq4aVqymw35wOLuPvYMYFQBd/LJSs0G5ea5YtC5b7tr1+kaU8cACVuG0b
NCXeEwbeSFxkMnA9mZ6ivbRPmuRPKvF8tHMfevGgL8g7YrATwoMvW/ZARhq3DenfZwEge9NgyrkF
3+beTM/0VtWqtrW8aWwn9Z3ALvkIfiRwVD5cnkVflV8tz646j77leatwftUvwAfud4u/7L1cuqxe
1j4sXxy8MHStd16dH459t7CzuGsQHUOmBsfG0NnCqcGfDqE7SkcLh9Rjg88PXyi1iiBWSqzObNo7
0RKJjtdHDDtPiGPZ8VHErTpAZcCNqQAZyXf7fAPdDsf4Z4iDZlleykL/ZjFV5bU+WtP6kGFkfJiv
jNCVykjcVRke1jQVkybg2O/TRipE9HTEyGqWjmUXDIGwMUn3KM9If5Ns0oItP79XBZdVoBoA7td0
QdH0UHt+rwa0DRjAYn2XtOvgJjJsQ6+OXBq7XbFC3SyCYhbeLFfgh8xb1rpNyuatzmTy+b2VuxVb
hZ2QGI2pMNLEw5xvSgdjSizeu7dYJSAHLlb3w/Om3G8IyHzWv5z9LY0R0QQBtTIBCdFc0HwWD8Df
5tiomj+W3nxumPxl+ECieGkNrAXjP/CWvCYzluxWQazDcaswDVCIRqlmrRurHGrgYwMaHGSxCR+Y
x/ih2LwjCMs8AbcNVKCWRlIC/PrlzU9tm1bU3Epm9YU3Nq7v0sg9nc5WDGNLuQh7fDouZKQtvA11
4d5k5vTh9UNvftAeICKx8m/y7NaffBJ0iLxbc6Kz9afe3vBib1jPda+vg+5jg/0r1YH6seMeD+ag
5GG/+FouK2R/DAb24hTJejyp439/8ytb9ZuRUFsw8QA5VKx/YTs1QTkDAm44JwGz7RJ0TgG8bhFU
ukFQ+rkGQq3IBJCQLZSxb3SMOce4jeEj4Fh6lvt54j3xuu163DUDZsTfAnTaOc1Nh01g3cVZuNo6
mdyo7I5D3zyKqymTVtMWrcKlUgZI+m0BQDS1I44mbE0hhRQvp2lZTsupJWRNy09AVqOfM0powXZm
TrmdNpaUFMw62RS4bL1oFtUsRsTJDYiVrQSUzRkJUfeuDGQDYuX/AbGp0cVa7V7qcY59AsVC8R4A
DekSj7Ds/0FZKD5jfYKggz6BWh+jnFZDdA9VB3V268SN383kBjqO+gkn7lP6+eq42hWTo88F2qj2
xJp3pjJ87ux8WGjDuXgrlFMJMB+tVMrfqm+pEB7KnZykTpQS6Xj2EHhjJEmzwfSf3t20433bgf1M
IGJv7YTMWoaauQI140ZY5JI+sMLmRFsx9D3qw+A7oTlyLvBpsHVLcIo9Qb0WPEP9h+2qj23iPOPv
e6/t81fss8/22Xex787fwYntxF9x4pAXEgL5gkAIjEIIhY50KJTC1qKilcKUspKOUQ2llA1EtrZU
hVBEGSOJmMoEZWPVJKT1n077Y9KydkzKqCag3VDM3rtz+ZBq6blXdz4n0vN7nt/HCe+7TjrPNvmW
sp2+tcY1ztUsbbZaHWELjfR6LqyzuKbQfuyk93X3Z+l9bbnD9Emaon28TXkcA4qCAEy+A7gtB3AD
qUAOAAmkAQYTQA+uComrXoLQPQ2h3lsaWL23SMhUKEa5aGRBWuuidGr/nGHSWjUQUmpvnejCyfLs
gYNn34fC6OiZU+uXHflqU+ehr6i+N8t/mTz3+hEYn/ygY3BLef3NoWH4NrFTDwLlLvQH0oUQaID9
uHsAHrKesJ61Xq7SF93doMPW4V62YMDwXdsLtpf4yfi08XLN9IIbvK0t2AfW2FAaZIMYIFgVrm+w
2YCH59Iet82VdoeWCFPwPWyLB9OhXhCGqSgEQmoKHcJBZT3iwAZCNpEXXDwvRMNmC/mVnYd8Ji7w
TO0M2g9oMtDJHK3MdY12xNQDu6UcjcXcChpiuo9+np6gr9B6egY1E0eS+LUQCk3x5LVLDTkeB5yt
vJrqqsmN4M/e5qHgy/AcnzFPoabza7S1qCzFnn96U8zcvDa1iVuaQ9gJ1Gj3mOWvULmyDMVvsYHE
9ZXI5+VrD7Gi89r8A4JYTN0BT4aWC/n8I4vPEugWIvXGQMOPl2w/s27d3vLP/93Qm+70cNleU7nG
PLgoPM+Jkj/73MLvZUeGVy3qrB/5cz06+Pm+rYd2/rVc9FSXyz2cR3REIrrGV9BIv0sI0LF5tqtp
1/gft/QNfH1KyWl1BO1PCNoySMEObDYIhuqWuq46XUxp0yBxU0YhS70ITzved54Nnoq+EztddyZ5
MWYZjx5PnhHQVrg/+pMkWubrEtZAVKxrTnVAVGeuS+Vj6CiAKUlmzIwlbTZBY9rkkCIJycEEZW+y
jonLU2gcsyAS9vsV+CEUGdnFMHJiCiWx1W0xm2xMOi4zDLhMOE+Gr4E4WRz2I+Y2QzH7+nMMjpIS
g1lGozrlwBJPnvEEWC/0Kmh7iW31knjoHUkzHJM2N0zDz0EF5XsE1Qr7Dd668zDOVeC1PYKXmVUA
VlTaUazg/Di+GrY7NdVOgIoV5DRQCwthgf2G3TTB5QrqgoIK+TnRJ+VpD+cSG8xl2bzZG60PjI3u
WtnxzNaZt17ctHQDJy5dXtxT/k9buqX3hRPo4P03l3s42WiNRIwme/t2OPe75YW3h47Cnm39S3qe
/xVeVd4w0728fRi2KV4+SpagSPCtAf/FiyiigTKplXAAbTRtNK+qOY0m7ae97/KmV/lx/kECHdQd
01EBUYRgifyveE0a9ELKJVEiBeVUFayagidx0BUxGCAdh+QlUZRklyTJkmiOyxKTNmFTnwmZZigM
iOJ/WHNDUkBJckUJZ1uyEq7NSThMKkhKlMiDan8WSBBIJ6WPpJvSbemBZCDa99rFhMQ1qGngTmX9
EonZ+VnVpT+SJA0e8li1Uo/L0Y8V9OrTiuYQhNkIemh1FCBi0Ye2xqCELlVl1EfDcN0b5w6vzMjR
oLeOk3UUbbQ47Hyu/+kFgQUG6di0ZHfJ7ka0srHMw8Tu9lhkcakuILIGo9GGNx9f3L+L20ttH0k6
rYyJdP/BHElSX5Dup8ElHG6AkAsKTKvRorN7LW57U0wft4TsxxBKwVa4Ag5BHZyCOmxOXgdpWh+u
oX1T8CLOuq97OYs/7LBQY+A6xE5Lax+E8Iat6ab0N+lLCb0iHSb9uyLppAljU3ScH/Nd96qynyWj
nyYlB7MT3iteyvvD+hnYDp8hC8DcVSb/DpH7O4OD84TvZueIrLSWZue066DKVgnFMYaiCgupE00a
aFBCKelUiM0Q2mpQGpekclnSXU65L1BftET0z/Yu7PTX/6jn7OiyjbKzjou0RAy7tvSsY6ovZA7t
kHjbsCPhJxL9pwN72tNyKf/TN/Czvwxak7D9rb0DC+PB0qfbck8f0KNYikzwWtLDrbr9IAAN00BP
DNxO4n6xvfiO/jZ134YGhDFwD6KwvwmstyG75JeoV8ggUQFgs0OdnqaBvzogQL7aH/DqfTpoJJrk
8+l06AiYoKCBtRBrJnp8hIR9HjHu8zBUpx2JiHqAIBqRwDnaPmabgRDQJHxYnR6cL2aveG56KI+a
XEUTaYv4RHJNKLbd7lGSqgdXO8iF8JAaEufvESpRJnpW4xqFZvSapSI9n1eTAxllTssExaI6xfpS
CTI3tFygcIxioDJ06Fu9U0hhG4pbfsJxfLKasfhqvP3yhlWNxdpG6b2j5ud+9pRuf/nL1vkPh6od
zpBr2HegEC0k8juotlhg9xGFLRQHdI3MawkexaPGJl8T5czVL61fXdrmecm9xzPp/hj8z20aSK5u
3mZC3e7V4Ck3yoOSm5LjNUXqjAkWo63xFfGh+F33Pc/dIu1qLpVYkzkaayw2eTh9xl1iozGhJZnJ
VLxwgi4BA0BIZEsuli15bRaBbSFuuMQy5jHTJqREPqF0liUeicVeX5bF7pzIrmCH2MPsSVbPknSI
rZmIgJMwGZHGnYLmhpXjAnldPV1u7azNqif2heLZtICFCQEJvhaTwLEc+afm3VdVDJ+IfATKiwIO
OVvVP0A2TznPe4oqnL1KEpxT3ySx8KFpViTkMWRJFqyoyTciQgBWAFWMgcZRmnQoY+N1ey1FdyXt
NZNKkwqQqiQ4SPZRA/5x3PMF6kn3bKBj+cKTJnshVSigax/EqiyOmv7Aiv5CJlZbxXSf/sfmJK5d
KznM7gVdYvdqnI+k4htjPre87fz3F3nQzvnJV0NOhzjCvdwcrQ0FG7u+Lt/6FNd3/wLmdghWR2CT
5weFRCqSf73829EQyy3+++8/61EmqZZM0hiZpCi4jxddgjCOmVwcW0nZcuuo76Df6D6T/89+tcZG
cV3hc+fu0/vwvndmdu2dfa93l33Yu971g/WY2OA1xjaPYAg44BADboEICElL1QoR1Bb/SFFaWlWE
lCYKpY3UNMYoG4SUSEWWeKi0/dlEEW0NSiXcNCpVqype99zZBdKmbapUyp/2js7cc+fO3Jm53z3f
+a6qxdvlLXO0GCA6fQMxmsxaXqslUgh5zkm0Psngs6VtPTZqw7zzemOUZ5qZUdtMPK8wnCeSf59f
4jmJl/kj/An+Bq/mxZhvWoJyhPUbHfmeyEhkW+TNiCpyiQZZEIPElkIqJ9XGURKUEG7BXISDj0pH
pBPSGaRSKSPJEpUqnPd8tPVdngW2siQWMMDnLQvD9fYazD5MMnTfXRAQ2jRBcGtiADth3B5GesAD
0WAHgqNQpZKIWPIJcgqZJonfZ/dYdeYv88ccfpNhvC0Yly3isy84rob5IaFTSNHVpcE1+08Nfzjt
P+/Lx5o9Yl9cau1va0sPvV1x/4L74uk2Pc56cOk99Wqc9QTZLBt4p+DhdE69h4uzfW/UaCqNievj
k+L2+E1RHXemPd2uAc82z9b4Ps8e31Ti5ehswmBbxlZ6pjPHatTby2rTpFQ+pTrfXOuUM25vToxf
IYSHwHR4LhGJoODXej0eQeANHFWpNWqr4EmIXp8hbegxUAOieEF9tNFKrBVakI3kljDNHxUT03BL
rHDPyg2eaW94JLQtxIUqND0Tv+Vlb0MaZfVMIs8quTHVnvPK/nzGK3tHvdR7EVFN0uJrNYjqCKFm
W1xcsKAtjiNAtbhDWu1RKLZ2rgM2z6eVLWs92mc9GGxunK4ZawcusXcvWDvEQKMSfptRuycwKRK7
guS9tKdgqdVwSMmEwakAmg+77C43oY/0/3j38gZVwZUKtXQ0No997teFcG91R1IbagwKbU3LiK/b
plGRU/T4ou36+am0y6oPhp2+xPK23LKNX3+p+rsiN7s4RF758y7JrQk99IPq2WcC3FmmLC5hfB1D
pFcSnbzDxESBFrRxWE5KDnCREAQJU+THhZfID4Ufxc8tf7XHMoAhaHHv8B/0XxGu+dX6oDG+LkhV
gihy8XiiJJe65Zg/wImiLyY7YjG5FMc0ac2vmF45B1Ym1n3OzoYG0ObnOqKpVMSgigsl//T3AjcC
XOCKiZvvv0hWgUxCM+LRGBOKTcJ8Se5anSvJTflSaZVkkk3fML1qUpnEgVZhVYU4GGjDmBFvjyMQ
GEtMjdxeQO5dYIgxtBbnlZPl7gLD7z6RWq5odZZuHdKs5bJCoeMElTxhkca2UQ+kXl3n2V0fTZXR
COVqdV23sL72AiKnQEd2ZQVby6bg4xG+KdHW6A05cRvI+0sb19lFk9NbiAZ7JgqRot+54vlHl3fE
/HxSkkKi2WhPvyiU1O7BAXczPZ7Lhb57LDNmaUj5I2ZBb/HmTlbPjfjcqUHbU8PJnihpqX4w3Nrk
CvuTktsS+bD4R3NvOxdiyG6vrqRfRWSLxC5vOZUlWb4zrxdEoUVYLpzlZrmL4mys0jpH51RXhaui
qezZ7JnyUFU2k06rmxLNYla0qjLp1LJEzOvR+bNqjRbJ1WDUuVX56eKcA7ShK4loc6O/Qt6SC1mr
bLDlGq0+K2eNGQ+5GQmecJ9xc6PuI+6fuKnkzuA16i53FstvFkhPYaSwrUALFRqUTapbWaZvskzf
ZFlsupFGT2TPZN/P0tHskSwnZTNZOUuzjEQ77pHoeC1Ex5kQwoYi6uehZ/EO41BF/dSsA2zsrGgg
1eXumh4lB4jL5bbfp9MHMagBZFQlCdakaA1VPKiCapSsDoimZPeBwtqsQWPuimZCydKe6vW3v/Nc
zpfujThMOrtOjZuBQnl7qmgurnC26+nxzslvVR0Dzw89MypZrAazvc3f0lqWR65Vt/7llc1pX1TW
q9M6dUNg8LESd/h0nybM8Psp7riCdD84SN9rNlNl6TeyLdCZM7IQpc3omTT+PK0s3ZGRxdq5a+QG
d43+iv6VapK0i5ZNm4ybTFPcTvoF7il62nja9DL3fWrSV1WqO7qM3tFvNt+xZxwmm9kHXIUIsh6l
qUZloz4jts43GBpwjxaUzfoKR8oux0mqvJZdMhoNskfK9RiI4ZtOFnwXEI/F8UT3Auazu91M/3ff
XkQKfAMo0i5qHqqIJ2OtVoZZeut1pGMqWx2lmh5hXHrbwp6SnWamk8wyPmBmLzUzAWxmzP3gbpJa
uAOWP9UrJU/eI17ZRlHTU7kpWKKyk50cNda1+53E34q6to3688Qf0JqJNniO+xLSYnh3Md0UHls8
xM1Wb26xewtNEbpfWMxYcn3VPzRxP1dr2rqgXnb/F/YOwupAexTtMgB3tWb0ZwDqAIBmBkB7E0DP
o/0ewLACwPiVmplSH7fGowDWb9fMdgbA4QJw7f574x//uIkDAB7sa2qumQ/bfrTAzZqFXgCIxv8z
a8EkksBvT2KdxrEyzwG04vfmdgK0bwUoQs068Z+6XgQo4Rz0WgBW4Lf2qQD65wFWPQYwgM8P2gCG
8Jk1vwQYuQSwFv9r/UaADe/93/5XDThUo6w4gDKPiGga+MRCP+I3Wqw2Ozhdbl4QPV5oZteCIYhE
Y+gkWSvb2gb59gJ0dN5/qK9/5aqB8uDqIRgeGV27bv2GhzeObdr8yJat45/88s+iqOAInkWw4K82
gAQZ6IAu6IV+KMMobIAxmILDS0t4j4T/2Ip9MjyEfcOwDjbCBHx+aWnpt//8qM/4vyo4tUsf/Ns7
dLCzPgYFD0DdV6Hvqfsa9NoZoiq222iHtXWfAzN8re5TvH6y7qvQv1b3NdBOSO9Aua93MLFhau/k
weHJp9c9sXdiX7L85MSeqR2frgunbgCnpw/rQUjgBE7BXpiEgzhhk/A0TtoT2J6AfTiZZXgSvT14
xw68Pgm74BC2JuDApxzjs3yqjsY7sA208DDOK4cryAUrEZ48rhYl2lRAToAadCr0WOteDTs5ZGhy
v/wj7D1YcJVJcFiHA8F1bQP3Rv192PzbYhc82BfPb/OVQZIDrHqx/I69IHr13Pv3/s3/58b+hJ0L
yAWlB7DJAORO0Z0KZW5kc3RyZWFtDWVuZG9iag0zNCAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0
ZSANL1NBIGZhbHNlIA0vU00gMC4wMiANL1RSMiAvRGVmYXVsdCANPj4gDWVuZG9iag0zNSAwIG9i
ag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI5MjAzIC9MZW5ndGgxIDM4OTA0ID4+
IA1zdHJlYW0NCkiJXFULdE1nFv72/59zL4kQzxuJyrlOXvKQyHiGkkpuElJEvBLTTu+NvCVyESpq
0GqwbrwnXmtQHctEG9OeMDSMqbBGZxQlXsVqiTUUndHJqHbpwj2zb8woc751ztr//+9/72/vf//7
gAAEYAkkssZPjE90rZtaDWxy8+y46eUu91vLrg4EasMAOjx9XqV26shvJa99BVjOFbqLygfPrYsH
rAagzikqqypsTB/9PfBSIDBna3GBK3+//admttfEewYV80THVstEdsj2EFZcXjn/N+sHX+RxBiAr
yyqmu5D+6R1g7R4ezy93zXerV2kR789ifW2mq7wgelm/MmAjDynLXTGnEj422NDiW3fPLnBbIh+U
A4GHgQ6T1NXM6lWE8ttL1iIEMG/we5PfO94x5mN1BnRvqdkiu/LuP/hekx+Es/n3EIZW6o9jaMIY
/B6vIAu1SMcZfIyOqKKTUKAjFbsRTqEQSIONVGzBFbyG2biFFkQhE9eoC9txwI0eGGre5W8mVpgH
WcsPKfgIh6iMJiKe5QwRSzHseY3ZBBuizNPmZR5twy0KMxuQwdI36IxILMY6dEEpPjcf+zKIPNTR
QroLO5yoUQYoHnMGhmE/LlImS2NRpV5uvx9lvGsn2ajJvG7exqcKoYAtvYMVzHgvmkQ/maLugIYI
vIxxcPHqW7hCXam/TDYjzVHmFp6tw30RIz6TVuYRg9F4A6vwPmfjEm7iB/KngbSN6hnN9J16mbll
Yi4WcF1t4+zVYQ8OUn/qL2zCxtmyoS8m89oa7GL/+3CWMimXmuio3KUmeEea3czu5m0+iWjkMMP3
cJR9PKAE1mEPso+sVHorlWrik7c5wnxsxVk0M49rnPcf8JCiGTfEIrHYnGruNm8xl3YIxRBMwDRU
YB7exO/4VI/hL/g3PRLtWfOMclxdoLaa6zm3ERjF3Mez9kS2XcOntBeNjEscZWfSOIohNI6yqYjW
0EZqpCt0RViEXcwS30pDnpRfKYNU1UxiSz3Qm/3qmIpiPoFFnO31HO9uHMcJ6k4RFMcRXeL9P4ph
IpWxU5wR12S1XKM8Vpd5W7z/8D4yPbBylaVzHubiQ87Cv6gHc+hLpTSH/s7M14o/yo4yUOpyoHxF
TpK5coWslX+TXyizlXrlqjpadan1Vpd3prfZzDTf9V0bWJhXJGIxAIO5fgq5mmYwPzdjNhbibXiw
mutlPXagnuM+ghO4iK/xTz4BkJ05l7D3cq66alrN2EJ76CgdpxN0g370QfRhRIlBYqRIEWmiSFQz
asVZcUnckb3kdLlYLmFslwfkFQWKophqIiNDrVHrLCetUdYMa167U4/vPYl+kvvkmhfeYO8vvRu9
R723zSlmFfMPRxz6MdPlzHIL1+AuxodciQfwGU7hyzau90mQyhUfRDpXQyyf2khKp9GMsTSBMZkx
laYxXJRHxYzFtITeoaX0Lq2iDW3YzLHtog/oAOMTOsS4SNfpG/qW7gsuYiG5msNFpIgXQznSFJEu
xotsRpGoYLjFbDGPT6hO7BMHxSXZVYbLOOmSs+QW+ZE8Ji/InxShxCrxynBlilKkLFXOKM3KZeWR
Gqo61GJ1u3rMEmIZYJlsKbVstnxsuWN5bLVYs6x51oXWC1azXTh3rL9y3Pvx/BNvOUNz1G7KfHGd
70WQdKvLaTJnzCImyTK5Wp5TC6lVanSVPLJEzjB3yjTxUFbQFHGE+shQNUkWYiVMqhc3xANxW+lO
k8RdilLW0SeiQqYIi8+Jel7prixVuU+LL5Ekfk1N4rhcKpeaf0aSup2uq9tFMzSlRXTFdb7Vy8Um
3vSFKBE1yFEGqI9Qwnn/QJ3P+R4hVlC0vKBsxy2pi++plTZy1zhNY5Qw8SsxlOq54z6h3rhHs+Cm
DUimP9HX1Aii3bKOXhUd+LQMEUCD+Td2WtrpgvRDro8jRYjulCVaxWR52HJWDiTiLnEOC0hSAtfO
/x4vZvINqBWR3NMc3E3OUyKCsIn7/QPvYV/HVi+rNVxn78tYZCMBr4uTSOK7cYuRg2VIxCGuwRVI
EJux0FxC+dz3x3L/FGikUsSTP3dLG3NbzP+LHqIP98I32OtD7v+fc9fPpO/wJml8s5oQpfhWVioO
7kxO7r81jHy8zqOtWG/Zr57HeLIBycnJI0e8PHxY0tAhgwcNHPCLxP4J8f3iYmOi+0ZFRoSH6X3s
Wmjvl3qFBPcMsvXo1rVL58BOHQM6+Pu1b2e1qIoUhFiHnubUjAinoUToGRlxvrHu4gnXcxNOQ+Op
tBd1DM3Zpqa9qJnMmoX/p5n8VDP5mSYFasMxPC5Wc+iacTpV1xpp2oQcllel6rmaca9NHtsmr22T
A1i223mD5ggqTtUMcmoOI21escfhTGVzDf5+KXpKgV9cLBr8/Fn0Z8mw6e4Gso2gNkHYHEkNAu0C
mJQRrKc6jJ56qo+BIcMdrnwja0KOIzXEbs+NizUoZbqeZ0AfZXSKaVNBSpsbw5JiWNvcaCW+aFCj
NcQ2eVY2BiLPGdMhX893vZZjSFeuz0fnGPabatgW3Az6ecjGu6TkLH9+NUR6HEElmm/o8SzXjB0T
cp5ftfu+ublswxDhaU5PGjteySnMnKixL1Gdm2NQNTvUfHH4YnoaXYHu8M04SzWjvT5KL/aUOvlg
gj0Gsqvse4ODkw+aLQh2aJ5JObrdGBmi57pSezV0gye7al/PZK3niytxsQ2BnZ+mtaFjp/8KHQKe
FwqerbVJbeo+KTP7WV7Jx0gfzeXwH8arNriJ4wzv3p3uTpbPEsY4BOGc5LPAH6I2dpnYjkAn/AG2
NLGJHSO5mUjYOCQtqU1p6bTJFDMZmESU4DSdtCUE3A93MmCPjzNl5ECL86PNrxb6i1+deBra6UyT
xiGFDmka9dmVZHC/prKf9/vdfd/d1WnP8g37UEncQE/NjIw0k/RwM8LwSVBkWXuxH89YzrZU2tMK
u4flW46Ax/ClbxPsv/HB+yste/IWOeC5TZjITsnyQYO/IFt1dVZtLTsgSht2FDVu4/qWTcFDGcEy
xjw+MCwf6cXa7km01mPx/X62vcczJhmCYo3viud0Hxny2sSsr0tYQop5FgqeNY8zz3jBs5yeMnCO
LxJ2015jqRuW/92e8tUdT7datPx/uEdy/mifEd01GPd1pFP5tY32r9By/uZlX16iOQcW3JICWKku
A0fvscE4M+DfEeg0Op5J7cRXDTVaq9violdI5CTBK/KhcH6fWB6ZKfFiNpYUkPn535tRVBxgbqG+
TsuT2pmjiSK///9MymSXWBZn99LyPVmtdSv1R1boK8orTosoWNogRPsH0+miFb5OPKzS6U7D15lO
pfdksuNDhs9jpOfFuBhPj3WkCtufyb513Gt1fjuBJp6mrZvYnYko/s86yG6VZIezDWop36z7P7+T
W+h6JggF4LYmtpOjEiEBYL98juyUW/DEP0B2wdcPfA72V6QXSADxX4beB/6K0EJE2LuBJSAI9AE+
YAiIAzHgeWAXYi3gZTZGAeIJ8oTyJNnjeId4HAOkEuiGbEjvkVrpIPFD3sl0zNckVpBayJXw1SgV
iH0n+wfmR1wljxtA3kEyDv826C6gVDlBvOBuYDXs6zDOm6xm8Kj4Nus1+yHkQ6ijC/LfwTtRazt4
DPYeyFsBDTkhoSU7DHkV5K1Ym1WQi4EO5N1lOYjXUONe+MugCywW82rgXhaLMWvEG9RLT+H3+Qa5
IPWTMvhLONA367nQE6uf1fRf0Mnqux+5+jhYrcK92v4Nwr9gRGzie3Uk3+tp4ddkTJzM3oJsyGWk
g0G5QR5Cf+8DLUpF9k+or0vaS1Q+xmlyTNiS/UR4jlSgD6wj2YiaEuxMYY+r8vOYDCohf1zuGX1i
H6PgbVjDv+C0foC8NgbkzgNvY44HWC98/7COsH0dOAj5OD9/iGHxGDfCxsytIfHw8wOwcwM0FpBf
2wJcBfC1O8dRDrwGXGY6ztO32J6yPePnEvucr6UYviq+9y+QKeEp8iJQBgRx6TyWR23ufNEPUZ84
T0xx31yL2Ri+jGsrhfbU3IMVjSfvac6iRjPDeEmeu1nsCPeOzDmLmXVkbl1FjiPqS5EScZg8Bwik
DLQK+DzQDkjisF1Vr78lPkqeVYlZoh8WDouHpcMOqaGdll4VG0kvqtJJqbiJhBBQrSdDNOUcc447
RY/T52xwms5ep2MUL0AnRVEX68Ww2CMmRUcmu2ArrU1g5g65tWnCNemyXAuu6y6HJS/I1+VFeUl2
+OQG2ZR75ZQ8Jo/LE/Kk7JyQJxQh5RpzjbtEj8vnanCZrl6XQ1foZOSoOMQeUqAeYAyYACSyJCZh
94lPAknSAJiQsfqgBJoHuA55EdwBzY04N+LcsLphdcNKQJmnF0gBY3mvvOwp5LD4JeYBNsJbAmsJ
lnYRdIlJQDc0DZoGTUPUdeFTVOgB9QG9gMhtiwBOKGjB15D3pwCZ+5d4TMFnslzhUzO1caGGWjV0
soZO1FAzFI40mpUgpaWlSSMZSFYnp6RRYzQwWj06JfUYPYGe6p4pKWyEA+Hq8JRUb9QH6qvrpyTd
0AN6tT4lnYzNxq7GrsWkZGw0djgmYufm7LqGRs4rA4xftB9c1+iObBVm0UwS9CzwLiASN6gO1ANh
YBRwCLPcOgPrDKwzpAdIAg5kzWAMN6ie9zH7We5jEvMLK/wiWp+2W5t6IjFhGjHTiJ6GtR40DLDo
nDTL7RboIrf35OMnuZ1F6UAhTyJucZDVAqoDYSAJjAEOck3cTd4FMDqoDowBs4AkDuJvt7hbmMHf
tDAtBk1t8xqdlJfjp7J0leqJeIRinASNvsnp9zl9idMwp1VmSbd2p1v7Rbd2rFvbCEGoxluaRr/L
qd90RbSLEa0notVENIz2APHjwb2GU5lR+mdOH+U0aJb5tbt+7WO/9pFfe8OvHfBrW/0sbz2+wJpQ
xqmLUbyQMtrN6QbTpWu/0rXduvawrkU0eoZidrKd04c49TJKb110t7uJ8zK9RdoxErVDNXpGIJzR
rB2KgH1mh3aA/cMOnQH7xA69ql+hd6kbr6o6vWNX3dQja+hfaZfE9I/z/CPaRc6DL4HvA/8pCdEA
+E/s0BEW/2Pkn4L+I1Kpsvgfkl6ed5Z2cfsb+bzTdnAIs75uB7+BWU+RIJ/1e3bwJqyv2sGXwL5j
B/eDnbQDrMAv2qFaPbKK7iNVAosdxsWFVRLLz7gTI+8H35FL7rCDLKudTZChbbaxGWwjq/IKNUgv
n063Dd5kBTH4EOuJwYv2kgDnJdTNi9dwR2FctY0jGEW+GLip/y10mTVOblO3fUZ/7wr6G4D6e9pl
n9d/O8+Wy9avBTM0cEn/jXFZ/2VVhg7Y+kIwo8JxNZgR6M/0C1hkC7ECvaTPBvfpMwb3ThnwYqvP
hjbprxuD+g8C0G39SPAKK4M8i44H4E4Et+mx0Hm9M5ChcJshTGYW6a3GV/QWmJsztGvuvL65KsNK
acAY5y/ptZhxg/FzXuvjwhai0K+ZQeWrypAyoOxSHlGalE2KT6lQ1itlaqnqUUvUYrVIVVVZlVRB
JWpZJrto1rEraZnsYUyWGJW47BEYZddPPPoFqgr46lirxagQ7dtOrdIoifZvtx6ui2aU7GNWc13U
Unu/EL9A6csJaJbwYoaS/jjOJzMd9bL31nlCaf3RE17Gnz96IpGgUWthmESHfNadPiNDi3D/dhjb
15LyQ+G14dJtq1o62/8DSeVp3b3P2vvkOhS1tsJ6LdoXt85VJKxGJmQrElFrB3vnnRcOCKMd7fPC
GGOJ+Dz9pvBP1os2qI3r+N476cQh0PfXWQSk0wcFGVkIBAELOIHkLxlKjJsgTzDiy/hjwodBSW3j
gOvGaWgS7HZiexpPYFqXpHVbJOM4GtzGKbWbNpmOM03THxnPxG3djqcJk7T12J3YyN13Ypx26j+d
6c3t7tPb1e7evt339g1HttB5vD8cuy+GBDIEYtB0DGXF5pFAxZCA5yWxzZIY5KkQCacEISu0iDdS
IcifRUmoP6vLCSZAVyslIEYKkVPS5SSFVAwSIqtM/e/K8hBWS8rUeUhSVkCFUi4XiKx2UZFUtQsE
Uq5qiX3mC7bDlXUnhlySHReOSXYw/kLmS1kZyIMVGZIDMp7/59PX+D8I4/muq709kT5HJO6I9AHE
k998cqclOdFts6V6r1KGLcm44909Oynt6ktedfSFk72OsC3V1fMAdg9ldznCKdQT2dqe6hH7wme7
xK6Ioyscm58db4r+h63n7ttqGn+AsnGqrInamo0+gB2l7FlqK0ptRamtWXFWshXd0oijre2pHNQY
g6urROeJMhcqIm61xxpNmqF6qTzW2i1PWxdkCM4tpSeWzHM0JvMBKKssVBaiLKhPylLBtHqFZXl6
rd26gF9bYWlgWutoRB5kiewK339HRkZGKSQSHsCjCYs0N0oLOGlviybXPbKtPRlMBiNJMR6O4WwZ
JVaepnZRczF4JUgGg+PBqeB0cC4oTyRiMK27KFwRSKcwKIwLU8K0MCewlPF4+3kxOC18KjAJyCg8
Ck8kLNlNAIWX/hxNjNAHgYERAI9kjlr1NLWHBNQDnS9GDGA9gAOgAqANQI5+Afh9gD8B/ANAhg4D
/jbA9wDm6QxTxpRFLLvC1GbMQzcfC+Of9wX8D6eBdu3I0rZtWRppydJgyG8BerahIjekhiYcowXA
7wB8CPBXgM8B5Iyf8UvKE9ncjY2gEQ+GD0DwY5SiEc8o9sC2CdunXOpykQI1pwi+QN6E9lJBLp5F
clmavHmOQbkKOngdIz6HlV8EPkEMLkEc3oO3I4tHcyu4HGzR3Aw2LwdRA4w1dwGV++xau9YFCPZr
dNfGvHVXlKM7yCZ7C2xF7/1Bfke+B5WjOrQRx0Q3il6LEk0UsyrOqrSZVFYbH2LXlw5aoU2tGGzc
b2VlfhylLafBVEmpuFqlqywRK4p90abibkW8IF4S9/fVDflH6z605eXle/RsvT9UUpCXT0pZNo03
i0J9gaG+voCRrfaW+dYocEVBKbvaU68PcVz5SUROwiGdZh459/A6B8Olybio1Ky/YjJplOUQpTT2
zaOIm/0ZtBj1+G3EoxLyyzcKGoqiZvOq/DQ+LOr5Ijd2H4oHcODC2tRg0VARgcO7TLSGg538ID/O
T/HT/Bx/kb/Cf8R/yufy/CbY7g7P27dug8Oh5WZH89LNDvru1Sy3RPrCf2nW3Fyi7y0IKI2rZkmz
1LB0U6I6cw0GeFbl9RzUXMJaXQ28Emh+Xe7DHR4PGu7AHXuHsd2owkRRiCv8VdVmFXYI7mIJByqr
qr04UFldVeE3GQ2swmSuClQWu4td9TDrdgis0WDSezFIwwD+LTPi04+1JQdiz6+PxA0u1+kntvyg
d+zt4e8v/uSzNcLT3QefOn4sPT6ZLDSVZL42diDW+FhM+M3Xd9R9dd9koiHB7HIpGjKLkzvbohut
LxyJ7R74SnL/vr8d2vlM3Zlt617o3z3T+cef/vao12mVK9cef3zD9n215fuW+XOzByKzXXu+66dn
/NbMJjImfxHpUa3oOK59VUuO5D2nJbknOS06ifWQybncayqhlcXshGHrdpqYHUvLQSl6ELlyH4KQ
YKO72E0CGlRNA2M0mAsJGTvRd/QU9t868EqLfdWmg5lB1+Ydx/Dk73AVvjdQGv4kc/zy7+cmX/0O
+OAFHx6VfKgRnSWy0pwNcgaMa8EJPTQNXC44kL27MuyEsf30fzuBO/QBk9mkM2qQIlCPdRB0L/Ge
7Js6lbly+8B0s52Pjsl7S6M7vpV56oPMOxk84Ip8jPdc/iA5OUs9GMicgQvDr5AZtYnFMRIzXzIx
nDnOv8czHEYKmUydo0PndWKeUlarNhYZJ4yMMY1LoYFTd6qJmrecAqegWjualzuWwKfruhrIH3MN
9QwP6wN0+Yth/RVsNkuy6THQP8wpFEqXzlBeG61q7J/KnFktTLXq8zkDV1tRvm6ksz9F16gNT5B2
uI4wqEG0EfnEQ71V43JMu7QkwyCiwa04jo/iGfweZqGoKl9HEzJaAJDlHTRGa5YASxmstxvtbUS+
fIeYT1DNx+5dx4NoESmRRyxAIqtkRE6sDXBiQ6CTw9PcHEe4Z/J276e6hvd6PPTbyn0uyfvsl2C0
Rgx5vaHQooS9a0Sql7l3ndTDijJoi8gh+btF/VWwkGmmWMwnjIEQcBvqX4nSuEg02BgfE2eGmBnm
GsMyF/CPybuyNB5MfUSt0uKFOm0IPiuXyrLc5+GwA5P6jLEVfyx/8fNH5T8EXWjTvRvMG/KdSIOc
aOFsV44NevyzcrmRkvz8VWmsFnXcKuQW3UR0x90z7mtumVtLp1WdaBCNoyk0Azs271rAhRDaldVc
atF0DN9qXlpJs6Z94mbsdDgFJ2EJZjBhFa4C60PWQivD6t1ql9Jt4c08Ye0ybTcqYld1Y4MKRqY8
GDmxrRtbcwDpNMZuxOcCkhogikolKC09pK/U0c3DbNIaCES42F2tMdONorpKS/cRKYXIpudHt8VP
jb38jfe7Fw89cSlSM1w1Wuj1OWtKasOBDZXklRv4y1tC05czc59kzr/055/fztxIvdS190e45sbL
Iz57XVvmFKzRZ3A8sRAxEzohGkRL3DJjuWaRIYtoIU+iI4ioQnq8C26iHJ5BApxNdJwDYwcs8D+R
Gu9CJphB+O8i3LHUhCNYzuXkEQYt4NsgvlHUqVRqURvwqcfVR9UzapmaNy8QJ76+ElxP8F9Ml31s
U+cVxu9577fta1/7JravExvfOLYTmzgB2zRhXvJCKRQCpRPrUj6ypGkFKXSFZIWNFBRDQSlfTdYB
o6MDtxRaoGiwjNQJqJ2msY4Jjf2xiaJtImNZ13TK1j9AHS0JO9cJtJHy+tW1ZOme8zy/85wl6thI
gcINGadpmDrm9thduB2PF6jS0ayFk86iAHiKjXQ9SWMBEghZ8TNYZGiZVROktdZtEcO+8Fzuwze+
7OmsDZBwmPhndJG/7o8FA9NMHU7HdzyN7xiA+XS76LXWebyl30x5KR66eTgCbnelmBEXiidFgQZX
ciuklZ4V3nXSC84XXK9bf2Z/zfmu9V37Zf6y53fe657r3uHgHe6Opxj3TU7nS4p1t+7xe0XZY/Va
/Sl9gb7L0xsUvTohHp9u0wWF1QkveD3oF1HjcKS1U1mmRbaGrAxynk1Sm8r7enUwhxjRh9gkFm5f
PxBbIA/7qMIIN5dqLdp6rVvjtDyIVKP4Uj4mSIPZINsazAVJUL8Ad9BnClBa1ELWk27SSz4gV8kN
8l8iEX3aELzylZ5HMpOKbl6CtlJNY42NN3dkGsY74iMmrwptwIFHVHumR+W3/saOhoOOzmbsB0qU
iQNrpKWpWSaG6qEAMlEQiWjMrIeH2NMtd4fhKQgeef6Zo5GwfvXw8b/VLDpxpx7anmua7wN+4ssw
zIVDJ7ed2Ngx+Ns/9a1Z8+b5ic9q1Rlm6luGHv4OdmsmLB5kLPeGf2Grk81QkrHVzZEfscy3NpZx
V2WorKytpKnW1NXUcOpzi8ikYI7cHepKnCofLB9KXE7cCN0I/yXxadlo2LZQqszD3v6KCpXJk5H+
P9ZATZ5NnWd51Q3uPBw976fx6pQ/Dw/3q0plxQVoZ4oYmfyDWh/HCpO+QoWxT/1nbWDLQx8+r8pW
kb6qXBWpwufnW8RufPc8+Se10BTkUr9KkRRSrf49qn2gEU1Pmjj55EH5C7Ufa+64ZR4jmO4QLPGx
zoax5jFXXfUkYWYlqgMRi4MTyoyQUW6EDU7gw/ZIxILoqOaq2iDgwJthjbaBRU4INW0wTfGbLFEz
kzCJx7bhX8FBnUxHPK6ZbSpIMABms4ypEeRBa5lsKSSUBMTBdJnZWbF99rkdx5rmDm3Nbnh14t+7
nq42dJ/zh55wbPVPQr5p8YOPBZcefXRb6+F2btGuA2uXrth/ZMbAi2e3vTMv6p8u8Q2C9chzSxtr
/RVzApbv7li6pvuESeggenEQu2thFOYarXAruPc+olAHSx0Qs0GxiDgFVuYF4GxWheFsCifYFPRM
KXWJUpEoShLLiYJNYqYpoFyA1zFRW+EoVXgQZEkQJJ6z2bgLsBDdIMFqapVlBwtH2Z+zhM3D59QL
DQXzOKAVaTTsYB0CFUHU7V9zSEem0KEM2gOvH6tm9m6oq1ZxfmJCHO/MOOucBYf0JOLcVEh0OBzI
q06MQR2dUBxyhpxGGpL4AezgwPHxX5ONzx+fKIdbr0z8FFZn2e1395I3xltMOrWh3jfzixkDBPrw
Wxy4lgeeDXTz3UK3fy+3zy+mSdp4gn0i2GSsK93Eby7tIbt9u0uPse/IudBwyMGEwKE6XVqx2yMV
4VxlzVI5gwYOVC5o+EpKWdHL8fj0aH8waGhDyAkvq1GsKdxkyE3DwBViCOqZElhwPivmTB3DbdRx
CGioNURCaJA7AyrJGWCYP0LlIFVzKlH1siE4AKOFio00I8TVZrM6BWmPPMjUBUEj002s9EiJOI/l
YqYyUQfyBLdFal3HrXc9E9jAb/DzzcsxKomGyJlKtcPXktKUSHH6RYHd/NhE+3KQD+9s2vGt72/u
Wp8I+aLVjUs2njuy53sXgeMXnxqIHnk5v24gG31o2czSuGqkznW/+OfZVSJxmCp8Emt+DlXoZSqY
MRrbKG+y/MC+Xb4eHg0LAgtb2S6uy73Tw2WkCoFnQ3qFLrDBFgkkZMRAEJeRiAMj1r5+L8ObEaPf
oeCyCNTsBXVZfUyMxgiNtcZyseEYF9Mn64tfMZqqBbUajWp9Wk4TNb3yq6BxF2PjyFTSKCABsYzV
w63FXEkma4ZgmF4all3+0kApEZxhJRKWQ2h9taSNMex4K7dE2qDUFWxjymx4MPejhUmDAgug2M6K
s6aAbUYLZ8pVPisJ5k5yv8RIdfbgjrePrSvv+9GeK2u2XNnz1PuvguN/68avuBbMTy5s2vXy1kgT
3x5Wlr754a6nh8+e2ntqVT/4B+DRiSfH5/Usa/373Oq3Dp3+Imjqe/G9EfY46tvKnBlkuHvD/VpJ
PZ+/N0zjeNEl4NmYPJehSquSU34Pl8lH8BEZVrCIYAVGoQpLeA6T4I+pjyVFLEs4VuHpgjR/E/2y
IC3cBBRwHl4byFnBqtv4IfIJw5J/URvDqRzlHudyHM9dJB8ztqlKm1vDSAHEt8zJF1fH4pO5sse+
9f6c68SiYUrGiGlg1BKjfyDXJjIb4MDEno6abyf9/OLIF+9zl0oSrVbEGbMF1bQb1aQzESYJXXRo
Oa4ryWnJWHR9sqssa83asr5syfZwNrI7edJ73Pd2uN/2S997kQvRS5ZL1muKW2QsICjEJ0fdiscX
VsL2RtgLLyk77ScZ+zeY2dDINMLCihZYGV2VXMushWfJmsjaaHvyRdgS3TR9S7KX6+WzYlba7tzu
6i3qdR/iDkr7nQddh90nImeiZ5J5bkAatX5qG7WPRkdnVoqKHJ3N1EHtTH6exNh8Ua5wqJ5CXhb4
KvNDU/xzZKSzjLo2/2vwriJRVSZN04SmW9O59HCaS4cu4hcsKjyGCrfUeKinz8N69NQQ/GcKD2aE
vlVAw9jIrckUbcoZphQ9M14dKHO6Oak4bPAhjMyivw2mF8XamIQL51oZh4MuYEbmuLuqjal2Vk3q
ekrY5pQzUdJhdi0BD9Yq0e2Z3E/+T3bVwDZx3fF7d7bvnMS+d44/7853PvsuNtixnZwNxPWSS0oZ
UELSQQJkRITSAivZljg0fHSMrGIkQUJBRWN8qAxEo8FqqXw01IGWjWqaCkyrWBmidBNMG1+DaGjL
0IDZ2zubtJVm+d7f/ttnWf/3e7+PoE4gSv0zu6LDvNKKFHBK88Dw4c7fHnvnk+53j9ctuH7ifHf7
JlCzUetfvXogWTNjUevO73a/WfVN/N1th9q3/fJkZsHBdUMLV/eOXNq0sq/jxNXuLS3f2dDfklgb
K9yZM9r1owObl8yte03PZChT7SKOI9S7sKYThCcHFM1rWTNjl+cQigYaRlYgoqA1B4paiV2OQw7c
8SFQEB/9HmAljE4WndmzXBsGXwtblV8PXpIet9AViTU26ZU4Xkpg0cZ8ZVPpVZPOeBDDjMeN6zAe
E0FW4ygrTVtgmWAWWyWTg66ELMNyHO/2miTktU4qSb2cii9NFGs4Wqwnp5XavqpSmxVKbVexfdJR
LNpPYWXCQpejH6+j59Nz4DyhRVpGL4Ft9qXCa/QauFbohwOGQesOehAO2oaFIfEAfQDuYw4I4/Q4
/IgdFy7RF+En3ovCF/Q1eJ++C+8Kj+l/w8fex0LETL/I4SI6yKKAY15B4M3WMs7s5F2ck8JJjnIw
ds6xUaChDwo872egnelhAANpqzWHX9AYXEC5UxC9oxjWAwYAjlh8TKugIE04nE6KMlN8DjzRzDS6
Bx+1akwOj59qEYCQwx9oVp9mbbU+tBLWn/vW7ShukofNd064WV33dButOwS0TiIlzKcHrSW5G+y0
Rt3hQWSjw24MTgD4q/9fB+GWX6fJNHoWdTE89QDIUEhkEbQo/qD8NxOo4FkWQoAOluPEsfw/l/uf
e7nQ1uZR68GfAuBaXeei/L2X6kLfu/0A/OZqS1CMkYpCu+O7Dcuf7h16yagohqgUWQEsuJz/o85f
fgwz3EYMLWBhbBa+TIt3YB3CMDYkDKv72LeDWTYbvMf+LXgnVjEL2xzcpO6v3aeOyr9Qr7HXgtdC
ZYZUDr9zil4zI6WDgvcn9Kr9xeFKqJoUQYtHSNRqgRBaOG9itjxbGWY/B1fl6+othTTIQLHUQsJh
4li74JSdIUc8WvuCPD+xBCz1dAT34AzEYKoNdMhdqZ7UQOpQimLjbG0rRkCSlYWQJ2Yw4YTgElrU
IXm//LlK+lJaqjW1Cl9FdBm7TF1kV7zf1Mf2cT3CerkvuDm0zbSd2y6MqAOpi7HrsfvyE9mzjKJF
ziz5ocg5pYAqY4QhgiXDokz4p82KqETUH0omzc5pIZfLiUdDOlB2IRegoz6VLJYmvQycamhM6G9P
PT+nWDU76i9YwYMyIc7jfJshLM6K1OgfwBeSNg1pE46h5aaBMOjNMguTwAzAZwBI8C6fjvghfbAu
9SG4jEnYSuBGxBBeOJlu1tNauLP3+aXjWA1RfY8rlollyPqndfBlJorYyRRNmH4xugkr5jpXybi6
6sLhIvU2xhKBkFsAJMt5ONxkqpIVXFGrQu4qFcTIGhUEhCqVSIAalQhy01QQN0ZVTPH6VUyoJZIq
0lMUN9JfcvFU6kAmGGQyGSzT+yVRY3p4LFGyKSAl1dqZM5IMot9AICmhWKL3FafOySUDQjLPvEgx
YhInd85ZOXDjVn5AbVNc3mCzis9/Z9Wegz/Iv6GsqHtr98KPz7zSur537Fz7xyP1Szn8faFp+Y9f
HW9TZgQyRPcPpYjilj/YsPowTZINbzZvOOp8+n3uyMaWtxYbjLpDmf/fPxtpxI0y9lRrMgsxEMNj
REzcQ+8TjtBHbKfpD2zllID+PTKGbzg2OncSO5xvE3vYLHGWMFcQVgPunUssI4wxCjIyh8yIcQzn
ADiD5YgXT/v2G0M8AXL4jTEmfBwCmCMax0YsP7PglhwR06bZzXgWAwDUwux7DBCZBgZnWA2By5z2
uQHtFt24e57yyqqSkGaaJ5BFfJTpRYraiygnj0Lk5O2GiQeTiEZ0kb1Q3FefgzNVkApbVV7lVEyc
uRqrcKCF8hirQZnLUq0L6LMtK6lnBjnDykAUoGnjDrtNH/5Ml8kQ8OnqaZP15Khv2UzDZVGsv314
8PqW/om92y5uElcXHp4tvDe+4zRo+Gj3yHQbZ2fLjesK6qenhwtXbuQK/9jVe9Q+dvTJmf9cAovP
znVWcnGkRgGkRnrmcSJgf6p9u5wr926HP4F/gMZ+2G8fhHsr9zkucBe8VyDlZmx2r0CQDjDIDgl4
iDKJHIZcmchZpIBL8oghq9WCe0JOJ0bx6RYbwGzQ5rPFbZrNaJsX0I8V25BEccYXAD0BPTIRAcmF
XN1B/8rSUNPN+XQzcieZ8CN9vl8dm7qpY8KzAu2Air1KoPl2wDrQ4mXEdsBVetqnJqn7a4T6zl71
K3CHQVLyGWwOSJqkIBoghrgMYTugtstOXkdxCMTBN85nzxde/2Jr+11QW/jdw44+ZabUR3Rv9UWU
HYVznxVunbvyMg/mABfwgNleHa/TEV+/j6anYn/X2rTkGn4DfyB+zJ2Nn43fTFLtnh5TD7mV2moe
MA2QI9SI2SyLnFfyKyIXlgKUZLWKZo4iJRwXTRzJQw4HAWQHvCo2Go5i1bAar87hn2lzI5EwwsKo
l7vL817KnKUoU7aB3EriGAnJFpIg+6PZSFisjqEbutmsj9O4GxzBLWpN9iBrSCQx6Ffkg4mb42Cw
aGnS+TSCbufEZOdf8486OyfSsDjrB0grUSkURRMxFfoaoqg6OPEAg/8CpaLvA+KPTsBIOgpVJlAV
RGCVGLsAngO1ujCqRJFVkCxOTV7HMyIYkAXT1wcTJkWxWm3faitchaFZt/vWxusbQ68/vR+Ph30u
Vl4cNzjooEOtDb1qxPN3A9H1hdAqPhAqNHYEXb5Y/ZZCVvkf39UaG8V1Ru+9s4+Z9c7s7Hi9c9cT
PI/Vvry2d7xeL6xt8BhiSuKodovBcRIrWHEITUDYlIeN1cZV1VAcVCw1kBBVFmraSKmcyoGGOLQF
94UUJVGp2pLSItU/oOXRByEE2sKu+83YEFClaudx7+z+2PnOd853jixaTzFDX6tKxkofPddVEQAk
dEBCBSRqMXormZnBVdbS2ECec3G+6QzzSvp4+lT6LPPb9CXXJd8t1y0fBxnX8zxgM+Ye8+wHbFiv
j6smXt3vn8Fxi2cV7xJVkXXDA+DYT1JuxSM4M6lKVeJ6NF2T9LF+l5sAZH6el2tRNI6SYpIkbcRi
iUSchGU2kU5OoRRGKTNlpQZTrtSEx6N6cacXn/Rir+14fEgwqpZM1t3DgOtAgBawNEPF84AKAPKP
vrt4ABxw2KhAszuIFO/cAReQDphHOGhrBiBTR2AdkkHrm3HFPUp/FxQSxa/dXNfJx2I40f7gTd6n
1Zj1xeNmd5zyPhWQZj7mo5XtTz8LSFzp2Fpq7Hw4Vlr/jB6RaCxWr+1mNi+sS2ee7E3afFgD+v0D
0O8ceOxun2t1HYkkKpNEpGKEaHkrvyE/zA7Swchw9QSdiEzT6UhZbWZn2Z4yhubrKrvyg/l9rjdd
c3mXn3mhbDbPrGGh2vQTQ7KxiOYcRT/qKDo+Cn6pw0rXv1ojU2p4kjWMkDQ4nFYhwQS7pAmJBKRO
idga9Lw0L7kkaYb8yxJ9LV1xHIircRJ/qHFg/I6WF29knKoXW847Vt+utnhHyhe1J6elvSIbSyZS
ieoE4/HDiA7owWasqWLQm/bVIj4KF1GDnMglPLW4LCbUooWha9tReyQvaHzaIZA9lEHpAY2oZhvL
BakP5oBNjXoFiJOnIijgBd0HVtlhSnZ+4roEo7p75ESpuGfo4CdjHfva1LYvEj7y+SWhL8/tLe36
4ND6jUcOvP/wyNZl5eUKAzOg+/AXdnz45j9/Xpo9EI/hb25s1ePxXGxLqX9F0+2f3jz6vV98qYem
KqINgGADRJRh4JGKRq0+3Uo2RvT+4ECeVRWiG1RVJN2IqArWo5yqBPWoFAQCsDRicIPsGDvHMvMs
NtkudgPLPMnOsqdZhu3XBvUxfU5nTL1L36Azs/ppnfSfg8pDxaH4Q1B36Hqn1W35rjfT6dj/tuti
RZx2biDDxR8vdmmNaZL2+rXxCHRv2ozd15f2+vZLztruTnDX7j/Au60ilvXxqHBCIJsRfh7tIKPC
TnOkcXf+pO84z25BWHK118FL58k68jQZI3utCXLIOsr/SDjecHzV7/mPsrxUhhmBeIg7+yLak51E
U/iw8JssWwb+ARG3X+Wq+GoUwxmulevk9qFTubPoWi7AlUXKTNxIGqyVVlf76/g18n3rGDnmm175
ITqHTuPfkTPMFXQFX8Wf+q76r/E03BDO5bJmrhsfQi/xB7MHcpyH9yoemxW6kVGVpG60tC1XWtwu
l+IOOCxRVSWhR5tzTUozJFhD4EMwltsQslNXt5kLmWYOYT7X5m43UVvO1cRj4i/zcV6vMCicFIgQ
97q83nA4MkVbmpuTycTypqZUKj6VoLLs8bgTxM22fNslmGbGNebGg27sniHLLL/Fd/FkjMfTPOZn
yL/fyQQMtWrywfaf4BbHMkfuWOZiCyjbNvDNTkYTgW6t4sKy2CJ+9lnYgM71ZcAkw4HhtIOcnePs
GAf3xRAH9Posvy1uILyBAUBD21Y9anGZhtq2zMraVa6+3r70qicetXx5GuZbfVqokJ2ZnzsmFixR
KOCZ+YtHhAKCJ0ec3ewR0d7NvgW3xRCYTvfaHm2oj1vMfo4zTvwflbXbVsAVwfxStNT+rfNMIF6P
lwzg66M/7CmONjWUN5ZqnPatK564p61X1mVqVBragVMrlOqsiq/VrNn0SPhtcrUUGO2FKZqgNJ7D
vy513KfIBrXXMCIHSv3lm7H4eLJKjoLCh1tXh94FFqRgUr4DLNDQC5YCiQ5rSMOW0UOeIbvIuHZI
e0N7V/NjYwZ/y2oQBvLryBNVBNjO6EZ4qRJcbvhURdSjmqohE1kQWv/6QFAkD0QJwwINNpMZ8kur
LCwbHOeb1Pv7FscaAHr9uu0ybEN3vs82dGkbpDQooczo9zu1irhdspDsWIoV2HVQ337rLw3rYxWO
Vdu4uUcT/dmvP/Wdr27Cu7ylidgybTvznG3TYrjaGrk9tVatCNXtWGC85xq8q4l/Zl0MUCwgVhYi
fDKQClS7TK+0HC/P9NKteBPdkhmhL+NXM+/TP9KL+ArleQr+3GOuNpk8zZufo0zYTNC4yXio25Rl
Jo1SsGtGTXKBNkYazdZsZ3YT2o120pHIdnMc7aXfMA+hl8030Ovm4ex09gP5PTqbPSefpaezf5cv
08uRuewN9B/5phlbgx+SV2cew73y+syz8nDkFP2VeYaeMS/QC6YAnOZ0Q1OVSt2oc/hOVIXVo6Lj
RXSH6/YARDiEaAThCKU20VeYmZBJZTNDIUPBf5crIxGZcCyLkGkmkqz5OOh8JFNnaJp+WJ/WbVGe
0z36pJXFWQwYvncMEm+9I9N3ffmNPnvREixkSgDkIlNbnSvwM1jYw9al3TY/WeCnvaALtAGc+0Dm
h4CPfTb9lIwY8rfihYtYoDRYoKJUQCwtyDPzp9+WC7IZKjhZdeHsxZBZdYdl93HMGZUcvmc23PM1
ZlYXryuxLrOUNMHlh4SOtXgM/w2fx2OZHnD9sa5McdbsiYaLn7p23N75FbU6Fstp25idjyWXJGK3
/uRytrfH734xfutFmCLzF+Yvg8d5BCXwuNUxLmFpP8bE6mzcT7C0hOAEqS1fVj5c/gr5M5kn3nLD
kAArn24AVopuMDae0ZCNZ1SSgpgQQzJCkmQA375rBRJT2MdxmCiVrMQxNg6WIK0NBjXRFC2RESdT
dowSIUalsJbCh1NzKZIq/y/fZR/bRnnH8ef3nJ2z49g+n/Ni++w723d2zr747MR2WjtpcqgbbUkh
MEXQRslSVFTKWsgLKdB2FS10pAXEeF27TqIwXpaqnQLN2qalWwKsaIxNdC/SCp0EkyY0xLJ2UrU3
Wme/OydIDGl/+Hl+dk6W8/y+z/f3+dZbz8ViuTjMxSEeVG//YRVsRq2LtxSpsPjEHLTd1abNz09U
+0WQKEtWr1iu08R70zVVJx/kU9BNSnwvuYEfIv38MPkWv4P/ARyBN+AE/x78B/hLFEyYWU8QO0ex
t6cJXZicFvluir9zGk2WR1c9ieowwiWzPL64CdZ2MlhCeDDLC4aXL/GNfIlyDfgKlvz42XFXCb/m
fHX714n6EjV8S1ZcjXqL8iCDDKqj8CVQkP9XLlYEEWCEWWG2Hi6YolCuPiQke1EhpiI6VnREOuxr
r7KMZ6nnn++3fe3qT79QwNTXW/xOvDgW5z6AnFtHBPK60XqAn2SP1B7hbPfDdnYC9rG2lQ63SpgG
tcYZ6JSYLEMJwzFRJscYjJ1ZEzGbGOouRiNGhEZ8nZwz6qRep+SkzjXhOzYuQen8jdwotg0Li0kt
CG0DwZtwJUNJf9JT58sQAQIZqGexarRjxdW6MxCkuPCOhgxpsjVYCPrFaWl78Cqi4/s4EjPXZe1N
eFo+ziRL3sdhapkHBzxc2VH5rPKXysN/nP3nyXv2P3H39Oy/99+DIDlc+X3lvcpmeAI6YeWvXl8z
MVk5W/nJ9D5Iw3UwcHSfeTbouTbNIsgWuOk00fFffaZczOrbAuPCePjb6oj+XJjdHjilnFEvChfD
Hyo1wWZOV5OlRKm5Q83p/c13NY/ou3XXOwRC4VS4J/yH4EXBPqnCL5UPmj5UPmi+oH6m1IQNOaI6
PKYZxkES2JiMVtkQk0kk2pKOqN1yr0xlmW1Iq42NDdTBOngS4kK5kBEaCdlDa/TFFhAdDP01nR7W
5/TzOqO3QNzreT6jz8D90zEzlC1Cy9IdunElajzJZD4VrG1+fTWizSOpZAcxNpT46mTDVoWVVFM4
kFCTqaZkHpQwLs3BdB4SApL2Ykv27CFr+rYbnIj2IHfY4mK0AxsjEbASA9H2WLgxhmEBb5n2VQe0
FN8mQkN9jRxPNouQN4kEfTHOwsvh5I2Fa2/g3KwXcG7C30/+9smLv2gdu674jcjmA6v39uVvpjsr
23ZLODeXS+PMVrPqOb7j1fOeVbW1L+5ed6DHj/2UkZo3Yz9VTHWzxsxEHPjvJM/J5zLMGuVHGRqQ
mvRNCuMEZyKZWEXWwTAdVnbCTnqvdG/0vvgDiUdhInowcxSOJk4lz2YWlIaa6F54XNnbfEh5BV6m
rypTmdnMhdylzELGzZNGCFFexT61lvVybpNyV7Y27aDhMDRIgjcWJwlVIBhGPDG5URLCMdmgLQlF
iVOoxyCiHKNRyqZTr7AcezO7gWWeZF9gKUuEY+HCDDxleNvUSCRMvR4PYrqDj5mMt65obkast0hi
UzHai+OQxk5w7WBgGj3fzrQXHPHGhueLt5+2GHZxGnKDY+iummaqIVtVQ3ZRDYtDcX6eQzkMjmVN
kg2GuPklagW+FAosYqo2wdl3/bw1FzDlkmkVZSmRkbN5aBVx0eMteSIruWhbHghGSEsxGCDHUBJj
1iQ9TRIIq3UmrF4+Xl9STZitt+wTy8snuFKO86JhQtUncYqmACyd/D8dsSbaQlujpaQkCsm+ufK9
SjEfdYtcOLm2aCnKIjH424Vff/eloxDY8Ojw1RX+sPOtc4cfLm+kOyhA5b4v66r7yLZdM8nKzkfW
1dFnYfKhBw/7kc92L/zJZkcfXU5vM4L8cy3gBS91McRrU0nKrvVCL3X6yjNwvXG+fXl7iBFsQ4Gh
4FBoSKixu+0ekp4r28Zd4+5xz33eEXFEGsmO5PY7HnFNuCc8e70T2qRtMs/x7ry74C5G8pFCpIg4
RDO2qBiVUqlMvgu6aLctF8yJOSkXW1FYUVztXp3uc93qvo27NXWrFpFAokJeKgrtfYG+YF9ofdtA
fqAwUBxo71/mYVyulN8lpGRXtNyRypXH+DH/fuUgezD7/dxkdk59M/2ONle+XK6/ybFcIMNUmIL3
gcKDAHCGzDA9hrt4qDUsRIYlQRTPRMxPCsFD9WlN66zz1NfVebS6tMeWdFpbjQzXkGbVVkZW6530
GBhivAAgJSE5A7LBZX2zPvqRD6K+Kd9HPsY3QydOScdEjcObaT4gHdZhVr+kL6DJGauKhv4+vmGI
HtVzaH02/SxcT0pwPQSqIh8c1EZx8Ixdmb9mxrWxUlarTiHL60zcW8xjnmoQ++sV1PM8Er5ZDQI3
irXlgu1KjvWrSVeLM09SXtMI/biwOXxbm6nLE1ddi9bMoS16Pal0gkdrdGRrTMFrlgVaS3V6ofRR
+INmotvo2uS+k9uomYkO0JfJKLHIss4V8JZsOW8pn/NapLAefLJO5XhNg5nQRGr5pMmN8RpW9uVF
WlV5c1LRoVhoz7eZg7B9GXM0wQ8eG9i8T+v69GeP9Vw621GQ3g4FI2wiEVp3Yuuup5aVmysvP7P2
4x9v3b68KRSrxdmoTbzwzQdv6cr37Np097O3HPrIae8Ws/Cbp5/asLe/bVOL+Pb4431P/64YlLJI
kaQLp+Rr1pR81yj3Qz/tj/SLW2AL3RLZIjqyse5Yb+yg/YAwaX9VYClExEYzdcWdpgvKbEAmEuW8
jtgMnTP8TtCI0eTp5r34dTeTKWIjM1Q95XDGmxolTTTtzWP+mYicOCS+INrEM1QljXRuOnoH5jPu
H1cGTR8T0Q1dRfPx4y5vAc9O+zPXibHNOnFiuIr4Wvr8E2vsXevEMca9y71rEj5OKL+cxLP9yphC
D/EAK/ttL3qTLr90Z98sQlf22psmgb00pBZuYJOcfW3lrT6lvOzzK0u0Zavz+LcOQJd5Wq6Fj+2v
42npEDhNckiW6WwhZxJmVLF2o68xXFBr/kt31cY2cZ/x+9/b/95iX8452/E58Z2ds89JjO+ITXIh
4NNoWkIChDUTCcgl0sgI0JUkYgjEAu4GTaGTlq3dS9mL2IeKF20dkDZLS6XxbR/GpK2fqn1AILG2
UoUUaQyVQZw9Z9OBNO2s+z/34pfH9zy/5/f79bJD7LEgbabMzNrU2kx/qj/zTgZnM26GHLYPi8eD
5zJ/zHyZZvsCQCGkkUwktGYj2Z7QkJEKJbSokQL7BDxCmlYD3571VbXC85wnuZwHao2zOZKL1X5P
LxVlG03Z5+0r9m2bthN6UlFOhtChEAo15+8/kd/lmvzeBtIBlAOg2j/zQVTjiLozGtxx7Go3BzhJ
G5bQmARLR7JBM2O2BfQcITempWwOiYIhmznCEk1fzKEaKuDD7T4goPGJaR8fT5VvUwD5Mz4Nc/1Z
QdzkN/tGVJv2Kepv6HbXcIe6497NW5/aev/WLnJLYaStuWXoh5OnP94K053JmOamxPTK32/e+c25
7439i1Rmt5lmsW1m5er2mzNbDr//CWme1Dv96iight/1exn9zmsUgmyCVGQDhTnRvRRGNZKN1kh2
oatYqMXOfC16P9NThX8qjxLLBvVh5IPo9dgV4yFmLjX/NvYRs8h+gMFnXWAv4cvqhTDzCzwfnFfO
hecNZr+6N3KYPiZUDGZXeGdk2Jhg92NmNx7jdgsvBcZUxjOGiRFqJ/Miy+hGge5RnycGAozJZrHF
WaoVZkBjGbYxDqaXIRikEUFV1oIBrkELJCKtWmJpdc5rDGNW5zAG8m8CBcmwrN8OxXAEziKJIGgI
gsQs/yiCIp/ZYS88H14O0+HPbdVTh9Ur6rLK6Oq4OqVWVFpdIr9Y1I2fGgfPAvFDWzTfL98tE9En
PqxvjqmPUYjR2kEHDFRfHvzvCkCbLj/dasQOunDGH368EFXcoKe4tG+tZJfjQi4GG7UYcgUr5F/9
5GrQ/coJgBpAKouB7lPIR20GGiUA/B/hUX0iZorMu5vNYraaMat0Rm4e2Ei2v9SzBo0hL9/bz0jM
kNlgOBOPTtA/2tWUSDGmya9pW3vg8T+oxsO5lqIIKILe0Fbv4FnoDZe86DXzbAOWOIHHgmCzLlYC
0ZArwa75TcHxBYgVP8YheqtwsI4v5rfwY/Qof4Fn02wH1ylakhWyYlmt3co461g3VrBfYJ/Dg+Jm
bYQdxaPcmDAqjcZG7RFnP7sXvyxOxia1g11H6CPsEXxEOCoel47Hjmqz8aP6d/Kn6R9wZ+Ov51+3
zzg/xm+Lb4bejL4d+7n2lvWT/Fv2Re4yf1m8HLuoXYpfbrmQX8AL3B+Epdh79p/sh9xD8XHLQ33L
ZH7CnnTO8HSP9nLrocQrOXoCT3CTPDXIDyU2W4N5ekzbmd9hU8N4mNslUjQmBNAN8XC+PZ5NONgV
eT4e53heiIMSaG3lCBb6MRRr0jw1ZOWzmqVIjZqSaU1rGdfp0dyl1akFTRT0pdVDXpPNYV0SxaQG
79di8XgrLwh+m6paHC7E8y0cl7TzTbadd1iM/Ttx24FTJ6RkLAvMCkGKgsBxmF//a/YdBx77Na/o
+IjtrQUvnbMLtlNx5h1qu7PHGXemaie3nWWHcz7nPuO/Lmrvx8QPSZ2IoX97oicNS3+VKOlC7/ol
8sBCveMflO/dbZbvRuWV+zXR3LHy6X91ci3UITAXmK1D4OkBN/sMKP4/Kp5dsRzo4+CF5T6flZ5s
MCV9xwXN7yOlybLCDaVWf9FtWBJRRSzVLVkNFsk6Lvgn0EjVZqgvIVAoj3xowOvpxa8Akyri2eLX
Wps6qq9Z1T9X/9JW/XZOaupfjx5Eiz2dSLxj6WqsIdTcHMqScltPIYdoRHa2hNMbAErpQurUo+vU
Nx//iv7WiUjaNE07mTqxgsm5md1r06EGhWPhUrbr5EqC/OK7dsTiAqY/ey9WD5DjoKAx8aoX9XhE
YJ6imTRFyphNE0jhI5EY5RfUK1L1ulI+uFLdRZnSqSmqQtEVap4iz1OImmPYKwgNk+MkSTZzoBqd
BePjXVDAbfena9wF1ZuB8m3rn3jOryD4IF8DgBR0Xf9ZI6PRUGEnx6ub0VL1FkpWD2C0/eEvIc/B
6n6SquV5ymvz+PM8Oc4jyJTFaUTIDJ0mKaUEUhXSRYi8wjL1ZP3gtUKyjM5MMRWGrjDzDHmeQcyc
DUKHJCDPj5BDGMQIIohaquWt9TT7fOb1My0/k2o90+lyCNIswj4IeW6GPG8xB7+sbmf3wjcOrN6j
zlC/J9YSG8hveIfE+NkuUnlxHVL0hFspXeQXBUrpUGaJ2a7XiDfEN4psixLulUuVEs3Hh5ghtl/v
Tw71eqUzLZwQwDqRHECDwoA4UBzs3tQ7sGGnuE88zZ8STonBkfD3w2SitKdEjnNdRKFvTTZXuA7o
lwhp9cYi70qW6Er+A4j1FmUAFumja1yi9Fo4ItFSXxSGupcV3e3RPdFDUSofPRkloycSMpLNVmz3
eX1kXyc9lavkyFwx22kvUc97jbS45kYO5cZNoqtBkgqFrutoH9EGVvKG1xRwCTNhVsx5k/bMZZOs
mMi8Tm6CsqlQj4SrLqF9XquWdx3sBVwdD+MKpmSMljEaxghv2rjplbr0mZ6Z6dgKHqBD9v2DX4w6
0OUHZZBA91fuluV706V7M3C3o9Gt91UenIVbbyYQRC8U18dTTKi7Z10PyfKcwJGskdSTJFsUXZ1o
bAnFCSUUTDTEUTK1nnHjRA9X0EHEi0pcjqNAEpZeti/uu4C6h3iim9rbQTi9imbQNAin6RkwDqPX
SgoqA/I7CJ9I33Pgr61ZWr19Ta6FxYDbrcOfBVa9JvnhtieKblQX3QjswFXLXkwEihXdbsuPAkQB
Ig+Rr7mQZ7cxomzCeAGFVix0b0TdMDpq+izyH6qrPbap6w6fc+/1PdfPXL+u7djxvY5jx/EjToid
2ElIDDYkDdBkDYSA68YCBNtUROyWqLBOGEKKAm2TdYIWVBrYKG1BGllI2qTa1nQVBVr+yB7qaLeK
TEr3KI2UarSaxAI75zrqNEvn/nyuZfn6fL/v+32fqXhPziAWgfg1SOxzg5ncr9SziExnnE6othcq
6lf3/chZ9fFXW7tbPV4q7PWEx8cOPtrkMKgsJbzG3Ny/u7YRvhzsTPXENh7dq7cd+WGyNvVMT8Xw
7vLyYGP1qkioZ7RKXBsYenBzsMmEtM2xU6mfwkyzLZiNt/cBQD28/3CBnlG8CATcGUuJA7wXXmDf
ZqfQlyJWl6Q2Uy9599MDzHP0MeYifZlDbQg2cqZK7Rqj05SyWjSAsQsAu0DXNgrZPUq1s1YkzM1i
Dl9R0Iq7GgHTtUKj4bVd2n7tqJYp4Mu4lgZaXitpa/DbWe2cFmlx+7/THNVmPb/dIDdWALeKrEW4
lZYz+WImzbfqLfFvFv8Dv5E7x2eTaDXySrRTgqUqqwPYrGqNg8M7kXFJ0Ka2O0AZa5cAwQYGVsz4
4cO4H3ALZHBrYBCw7UPFk4+QuIgqPXU2SCCpX0EMNg2deeH3Pztxuev1nhLJ6vDroDFUtzeePnt2
VzTqo76d+fp3904WGhvpqVfbS3l3/7Jv+S+r6m68N/5ruwkr4np8wh1YZ1zwyCTHQIObMP0pfygC
3OR8LdqtCsph3Mx0Yxu7GfXaex1oj2JAUQAF16T9mjQnzYMvFMoG2AZ7rFscfe6sNesYsOYdxw0v
Gkf1o9aL8AJ1xX0Vvg+vo+u2f3ILji+le9DKUh2GrYYT4gmp4F5yI70Ef/VwHkh4ibjjQRkgGlGD
kcu6Ci4KuHhslbuwVe53jbrOucZds9g0z7uWXFrX7rI7JbDkuuBRojIsQxOmOCmJmCFeVkurXbdE
DezUjGgoTZgHNSABsqAfjIJxMAvmgZLcoMClp0oHS6muUjhWCkunoSZhWGIhYHlWYmvYBKtgk+XJ
GeonQIY+n9u0mMnnlnOZhZwMfCDQuriYk8VmwYBFIxaLwRgWdwIhyMujfhLwVmIvl7AJVvB8HJKx
whMSz/6SL3IT4pmfgyQzUdEIkIHHuBNHXCQm4RymId3huT346j8gnDz2i9pgk1Ovdrtbdq3+3vnh
HY82RODjUx9A9s5tqBvZ5A17zQOis2PH+Qv3k9UHMJtA6uECo8BsEkEIVs+AMLa7bW2RMEF8baA6
kg0/yzyrOM4UwlfCs2GUCBfCFAgLfnNgi2ILtzlwCqF2BKVwg6pN1aN6hXnDfy6MZsNLAUqSgOR6
F4Onxqq0rlnqlJ6QdquelA5KY2BMuoRm0Id+tZczVmrWGJzGlLmsUljjcJalRPw1NRM0A+zakRiE
waBIq0WgdmkkovAGc1YoCFcEWsS5hhLuVnWxxKL7qiOkvtMWZZPVyUNFQmKZX85nsMCTFx61mI2L
hI+8TEjA/4+Xpd4Aw1V6vFyVBAIMvviQR4J+RVBmIixyMBMjMOZIqs3ncMDxyGk2GjFgXYx+R8UV
dbQo3FF9NfUdTtT1ZKHj1Py/PzjQiSlZGtBCfajEJdhD6gdL1WzzznDvuvT4k+k961ffv3YNtm16
66zMzPufn29z6N25m/B2qj/e+f0bH/2JoLYRM7SbHgcmUEYlEzZDnzVjy4Ks6RNaYZMcWP0dcSHh
iIsERlWyI8KJhLiifFK+iHw77a+O2Fmbstf4hNBn2W5NlyJIK1mk5DQK8yPsMPU8e0xznB8q+zl1
2Tpl/CP1acln/D3qX7TRgGcuxyOey6Is14/H7LDyfXSjZAlpGIi0RylaSWBnMezJeuV6qk3ZKW6m
Nit3UHlq2DhsO228oLygmuamlOOq69TfqXnNPZWJm0PYIM4hSkKj6BwaRwz6MWMCNYKZPKvREDf0
mQ+Zx8x3cGY12//AQJwZ5zCvSaCcKCbIRDvOl7Vq9eN2aPfoEbrFCT57vESA+4RDwohAC/dMpgIH
a7hRjqrhRrg7HM1zCQ7/BW6cm+dY7pLOzIBhfLrTdDBhqNEldF06Guh4naSjl3RQR55EiQ9Tl3Qm
VyQfe4lNyzmi97kMLovYMvCE/3kiAYG8Ph4mM3yfGc9w2WgQQZANKYjFQC4Dk72TLIAUldsm2wzy
kgf9DED4x9TuuCYRimvx4og6+OKoWEirT9iLO3vxs5WdqrhTFXdKeZfQKeNm3ha3Sfq4Fi+5o/9v
+G8zshbco/UNlhWxMRCx8bjkiFHOfgZ37Tq2fSgkmj965fW7X7995sPlY/BNBW/bWd89SDXdevrp
nc+Yhv8K4ad3Ifr4UmNvRSxxGM+RTgDog4rnQQCWJVpOSKfNp710ik5p2m1D9JBGcYaB4dAh1yg7
isa4MeVr/Gv68ZCSZ3lE9fn7ApSD0006uZfK4aQTTdNcQnQ7x5zvOSmnvsJjgYEubCVr/FUGPcsh
FY9Bn4aPXR3B9nGa+nYC+gPTkE9ofVXQUKLnXyopgRUEwKvZbESujY3F2tparBW1ck0IDldkVAcJ
7H26ft2sbk7H6mzBd2mWRkWxzxSR2rSI4ZSNYzMuf8ss5LHC4NTYvJxvbl3GxjEcCMjaYvBUmgSv
x+z1CD4HqDRVOOCKohAZAXhBvckiNEGzK1q3qgVG9e5oXTTSAondkhW/KPg6WAbrzPCiw9PSvfx5
lW+tbWKidyr3g97GiNNS1yGK3uqE4yt64/LFQnmwosKX2kFtb28e/s3+VCjmjLr2Go21ez5Z2w5o
sPrBevrPeL43gUfANuqLxBGD0PWy93Q9DUJ8mhrwD3RTwM9Ws4+dkJjWhs70vob93v70CDOiGLQc
tY5Ej7cMrhvZ8FznSctJ6+nOaWZGMWmZtN6M3Nwwm55Lz6eX0vZSyVzHR031YlrxBtdR32oHAl3/
X6rLP7ZttIzjfu38aBw3tpO0tvPLTuP8dOOkbdLFbba4P7fL1i7bunVb6dbbBojjx9JKB6choAOd
BhJaA6c7dNvpWunE6QR/3NY7jQoxrkzTiT/gVpAQQvxxIKZx06ioxJgQbBnP63SbLqn92K9fS83z
PO/n/X6j1SAhjXh5jvW0M27a5fL5/K42EPLeOC6Bn6ngaLrB8i7H341/EKfia+hN03NUW4wi73L0
3egHUSq6PdWKMDOKp3gbVVQ1YbRqwlC15kf+NdR2ra3oeH0EjaxRPSYjVemchGrSokRK18nfEw7C
RU0QZXhEO5zSAXSgu5ud+CWVB0EQgbNBTFB5U+Ty6Gx+Kb+cp/JFQ6cWp9BUXE6hFP4/w0KgsJRC
+1P11HpqI2VLvajM5GfMmRVIgn3GaiY3U5jxLL02jsZ7lE7EdtY7bwGI1sjrpu/1Cqr05KkaRdYo
RFAcRVL4F0nhAo7X4E3qC8dnfo5eAhlGX/0eGMgHGpaYljHZXLjNafMPADcLIDNuQ09ucpvb5Hl0
B3Oowm0ucPfhgJeARYCh929FP46Ss8cW7m/C5oXv4x/H8T3uYd4rWP4GDoTjE6tzbu/0wJhaDIUF
EdkT8d6evp5CD+UYSuxP6PFM4kh8KoRCg5EQsbc4oRDDqKIQO+2VEFHLToSIg9qUgkbF8RA6nJwO
oSPT4YEgTA8OEvt6qgraWy32m+SIAqTYZSuH0GTuQIg4lD6gEGPCSMiSwC1n9OxkLZynnwysofOW
Y5rFMJ230GnSOgc9UOS82CJtXfVaWuoY0lHLwQDZ8LICz6KhbUFl2RdsbYQIamnrJLZA/fC13kJd
sIdbgCwWkgmEpz+9g/vi1PHfrnxn7obmoRx2itW+Vrr549Hd3XI0H6p/tHP27Atv/O9XL+9180Xn
yYJmoI7qmdFCbd+psb7mf3L5gTPX3/9pX+HSX9Fk+pVj371p2h0uIUDbHXvqi9f8CcPPK04bZXe1
1w/On/7hdG+/KMaHXaflHjl2grzw1XNvTg8vnFs+PvzwfN/ReF7d9a09hc5OG2wqRDvQ91+g7PqJ
/5q5kpkp0qU5EAFsnE0slhol25XSemmjRGkOVCvNlep4yCwhpU1MR/g1ijX5rmw6kqx20ekIV41F
05HEGuUx9VgxqQ8VIsVRpCT7CSLcbXMmEwme52hJVF0NGl2hEUvX6WX6Fm2jcavHs0RU1eVsLTuX
rWdti9lGlrySRQCb7Hp2I2vLzu14GxQb92AWO6hH1m6KI/AUlx00W5k3WiYKV93qS38gZG9zxIOJ
kF0KIWdbwBnGWN22S2h+AZQ2rA4N8ZijLdcK1e2zGAuFLba8k8NpyTUY7d2ByftExaGJs98emqwH
fR46bzZ3dZi9NCWP5nteqHYY482BnTG/yMqBjpwHee0XH506N3bkM+ZPmr+YBrOlqskEN4lGXzuR
K+xvhk7osqr66NIRamdL0YG+KIOEc0Jl3EQX8WdTaqhoTq2rDXVF3VLtilpTSROfVMyD3t6CFUsD
rZjNt2IsbkVTlwIFqJiv2tWejnihTklpSIlERxmJ8TUcyGEQRBfj9Hnphgu5DIyW1ZEiDiZbKVJf
ZJh2qV0VTc0Q8Vigf6DQEFFNRHNiXWyIK+KWaBdXY6tvWfXBImUTFwW09WZrvwPiAC+47eqAtLFW
JuQem9VtxwKLqd/3NNFWnpNPEp3ODA5mMuXBb0o9Q82RET3ockYCoZQH+e0X8YNyJjPYjD5SjhiQ
2UD5MHr+1W5FYlXI4+PTzXG0ZF+CPKaJT669EUAOCWn4Zxg7iu3aKjS7qdW0hvaO553wiuZQ4GZR
ozgY2dCoQFsqqQwlI6lRyRdwZaSgkmacnWvIY3q57cQxzuBHHLvsQz7sPLozrRSau4uUrglCAHKn
ynJDQayC5pQVZUuhlNWM9rsozpY2ibVeeYJ7VJ7kxj47emfiPqQMyAyMrlTwVaVs8BZsgVDPnAgX
injYcDzEyiEU8QQxBtETrQDiENL66aRuXwHYsO34dG5TWrmsQQoXf70yc7QnGgjyz0dFvfNZhpes
xxmt3FQefu7e7eFYrLfdOR2f/gH5/R9pUSvLiOAJwsZAt+4gB83HrCEbpNfBIfh7xfUq3XA3mMvs
Jf6y95K8bLxH04ZkBE5yJ/mT8pe4s/xZ+TLpuhfZlMlF13nPh9SH7F3yLrvJ/9PbVuErYkUuKRVj
nF2gX2TbcmSGU+JKImeUUIlzdnCH0UFuSrHFuGk0zd7h/s3Zn+P3yDdcN+i/0XbB1cnJYVkeI4dZ
h5tnfe0BJsxGPLLjEHXYdsh+jJvip3wOiQ2HI/Ih0saxiOS9Ph8nyYGIpAPZkl006YrQGGzJWH8y
N1SM9I8SOcLt4zhVkf0KIhWZ5UABkH6ESAR+VjZZH7IlSZbmOJHeQRDCGvqHuU9kfuN20w7AoCSJ
tDvPLDLkFoM2mL8wZJ1ZZ0gmJwjLIhIDsoEMYCGh5nKEzulX9HV9Q7fXdLSoN3RSnysZa+il96Jv
f8VqoHkwrxN4X5/kFh7gy/uzgMinXCzjR5WyBC2Uw1u2YAD/yhc8uqh5vsHdvNC2fUHABHF7hXKb
iFtvnS/gZzedTlizCwvzoERnF9Cs9SHmiXnLhHCPPzH9sJnKKZAFcIRNqH+KNUiMEbfhxoE32FZw
tQID4So0tuVlWjCA3Rc0Lt5Pi4VEshjt8CAW+awdFxMBmraQRJgPggXiZ3jGTbz/bpVpiybQxYNf
Hrp371RXXpV2NUcSwVTz75I+0dTHYx1u1qMEOjI84uwXH9b/MOplGH+YVBRSH/xT849fj+Y8tKqi
Dp/Qhz7f3DhWEpGq8m4heoAaXt4d5GO4y3cCk1no8g7i8s8awrqwJVCC5Q/GCziaA8ZgAQmr7Wf6
awIyhZowJ9SFhrACE51MOuKsdqF0xJGM+ZPtQ77/M172sU2cdxy/5+7ss88vd3658/v5nPPb+c7B
L7Edk5RcSCAkjolbShIHAi6L2q2wkQQBhVJi0UJL1zXROpVVVMC0sk2d2qQT2sK0dVnLpiK2kk1b
J/bH/kJMUYk6TUgTojV7zk4gnTZpkf3k/FiKlOf7fL+/z5ezdzMIQmhJBARNxpU/Y6wHbKatZcYI
SkZQMY4bZ4wXjP8waow/YdcEbGPydbQ/jFSINvXKABP1yym6ekbPulp6ah0dzW6z3+mOWoBF8+q9
zsFWXz0xMeVsT33wNLysTUDyHwLdireFWCx/xmLVMrCUVTKQTGCmDAGAFznnPPr5paacyCXhg2Jo
6he5nr4mi8g5IANcEiSRS8xjpktCp8hthg/KBmF7pNj5OLe9WyfmikpejOoQItQzOES0y5qQbCQN
hBbXED2bkwmngyzD8KQtwUCCB+P8HI/y8yCjUDmxWQq2JnJgPDeXQ3PqHlsc6gz29/uLpSJaLc4U
UaRIF9Giysd2tqVYGS7PoyPQLlPOeTB2UrWMtBq69B2VIW42frVvVRMYUdtZu9rR4KtY946KvWoE
Iw/oYpUvmoJGyhQSwkFjwAvMVJM5tJYvIF5IAGZxNtfAi/8CGSvXWG1uWgo4Hgj3cJtYQx9fCu40
KI1Z419NDx5jnnq10DsRYE1k9pFau60t4CBxT2Qws7cfRZn1m2vJ/rxBE5AHspltcVeyUGvrSLnr
8R6hgF1Cb49R4djY7mcKhe3rj9UODfIshBEHLVhK4OXxZiWzxSDVCnVCgYZ4DO4lFZ+cqzEjWU8w
6GnbDnadkRtjAN4dI+TJf8G7kwY6ZX0G8qQuo96aRKaUqWTGMzMZTRwHSv25Cj/NZbRzmcUMOpcB
FbixkMF8OlbkqAZaiiIX7GvSiZy5T/CJnNBAy2Qk1pngkt1eREilCbeMEkFBoCgz6WCDxIwOzOkA
pRvXnddd1+E6FS09YtoXjPnFklgRx0W8Ks6IcyKGiLSIiqrd9PCaiJWWBl5K/z9eWp0uTIuHXJjD
CzRap8a9Kj7UfnQCviBeQquC7P9gS1XdtZsPvZoGhe99u7CPZ82G5MZam01Jk3hn8fAhg1mVz745
CblyRb3lDwqD7cdqR4b8rjpVUgPg8HMTJ2q+UdYH9ekZA49f3OKuq4Mim+7fxC5DdSjEB4aVTdYq
A37I/pT9Dbiqv+K7odda/06CLfpN7BBzEryiP03d8BB+JZXB/V1Qw/N+8FvmqhtV/KBXR4cQwhHS
Gay4eoISjP8BqCsOFtW1hFfwcXwGn8O1+G2jAr9UjOfhgOviugpOaSt9Z1IqLqscLxXmotsKc6VH
R94zcr3v+fHex0aGf4kY7y8gOHz77y+0traWu4Z/gbixFIIjdiy1RC951nyEBi2rsLRcVyQLfNaQ
OYyGvGEypA1bKDsP/1M3D1g9fHIS8MlmonngweDCGBw84tLApTF/HvxA5wI1Y6GEoGtYsRxED2qP
kkfNR63PsAedB7260TKcg2qL1HtpS94D34xaIg0rJTKlVkczaBTEDcDRpHZB60oVRJHF43sPXZ+6
fvSp5363LbN34/kTTxz/Wg82e+7F2Wc/r1785jvH7x7u7Dh37KPa3y58eOeVCtTt/t1aH/ZzqFsE
yQNcOU62qXrk6V56B33agp+SQZvc0VaQd8hPW56WD+iOWI7IL+guEku6u3pTom04XW7Z14IrbWCd
DouKVhvMbtepJhtM8IiARAIDEQ7pRq1SFMOb6SzIlrUESjSHzAaX05xK+skZEq2QVXKWxMhPebSO
uR6eLwXGA2g1AJAAHZgLLAQWA5pAZf0HhZUR1U7XTTS5rI6pOsxaHA8aAGam1ZCta8avyxAmXagl
bAwnQhkixYN1Jrik9VkeJA3NPGTbVXHqnQ2Cx6iEhdKMGqfqSRNa9aQjqymZZteUNE3DX6lc/ezV
NEWBO9wzPfDyzomXxt/uy0ZTjnyhxrtyERtDC5wzBFr05q9vG9vw6E5lOLEuiOUnPznyxL4X/rR8
doqh4rWlXWkuFAKsITmG7SknnOap2tv7hfXDW5+8/MeJrU6r6rLuWh+OQLV8KpUr77opNzdIYyBe
H5+8M1KKo0q8Gn8reiGOJ9yJQEesVRqgFbcSGIhtkYapkrvMlQIjsd3SfnqPe09gf+wYPeGe4iYC
U9JJ97ekN6nX3W9yrwe+Gzsn/Yj9gfvH3neky+z70u+lv0q3pXtSjI8fCB2ITtvO2M7YF+LENhto
0pkhfkRW8MPjpDg/JrhFIJatBiHkcxKE1uzxIH6/WVVXQPxgBqAVUAWzAAOfhpM0U2LQXzHXmc8Y
jOmSu6bqNp6YLC5DiWFMqnRZ55Hlji9Uoa35lYx0BqM2R9AR5pGoDS4hVuBBxC7yDVHVIQmtBFVt
lZCH3AL1UiVULQQdhKjxmc1hDUm1jJ2FVsL2OtN9tZSt1Wd37nip9+QfgP3DfCW8PvN8ZKxj/ML3
D7TtxGbvPTmc8oZCtCEPx9a+gX9eWwIhnvcGv1gH3oWp+f6vLy+k4cwyQdF+BvWKIm8p+yFoUCk0
RSmoQp3ACSUGdseAX7VKnWxOCRFYCMNcpBshDTGLnacB7qyqlY82AmMZwxACsstuLVBgO2z2x0AM
scD+5+dBlZ/hUYSnIcss8Iu8hq+IKsHDY3xAI5M3Jybrp0gvTy6PWhrUkUfoh5A3qc4URh0ojXq3
wgcrM+Q/qbj/wJHclpagMMRYmXjCZtq4oSZtbnKRGpPg9kdIwGCzH3/cJUeym+zirlpvfwQOjCBb
n/xfufCIt9Hsxu7fRP8MTyeJ6RVRL7tk1GptVgx5OWrIO+1l40j4LP2doIYkyCgpVtLj6WpaS6Xn
Aa+8CO/7NdM185XgldBfhE+CN+Rb+C3hVnBJNlg75FH5G/Hn5GkwjU5jVabqrnqq3tPx6WYTBSiU
xPRGrZeUP2q6Kui8GGu3elmfS/TIb+jfIM/yrwmvBQ3Wf/Nd9bFtnGX83jt/3J3t3Jcd34c/zjmf
765x7DSJkzmq1ittmrZbSBiwNUBIt1KJTiAlQaOTaMH9gzYRg4VRCdICripBi5Bomrap2yg02x9Q
iYlWglabhOj+iKZOqkeRQjWpS8LznpNpCISt957X7733ocfP7/n9fq0RO78vP9g52vmq82r+RNMF
42LnA+r9RNiht6aIRTKF0qgInqyGWueIxUINqa6wRU4pi1pKTauIV3WVVPFJZbEZn2wRxawRCfk4
ywv+FPojUShu2UoQfnNLUP0u+LYatduNNhdTphgi3xYREm9n7mf+kaEyNSrqhsY4dIAb46Y5iquh
blexVKWQphGdr1rogDVmVSxKt9ot0roBPrED6Zee2fz/B+oTK57mWB3ZuX9uPYNGhstFYJi5dQRT
6KH1ZTgPNIfVyDJf35Ck8TLwEwvyJxsJRSORENg6z8wNywT/cKUOXo2vr9Qbc2/qYTJhO2mdFwLB
tACyNeDQCSjLVIII2v4E2gQm1jBwc+ZJ8DH/WHhi+0aGQdBC+cGiUkVVskpVQ6cj07FpdVqbTsy0
/NSotoWBGUHyEkCesC1UNIrZH+TPZM/k/SPDmC8FW1fKjK2UkcuWSRgatoNsWcUiQmHLBVjKe4Mp
h/mUuL1Jxwcg1zmt7AWlnK2tP5iTykYjgF96MC+V87LUuJfYuBcHVtQV4RFiOa+L+JpHLsfBNq5M
8RF4TgTf4JErRuA5EdgDQxa8QbT+vw/kZhggKBgbvSjenEYNLHr0YgidmG6whc1i9u/GFIX1Hjmd
yR35yu7n9fToG39afOUL38jE4pFMJvHLl/peeHHt721tZ77TPdAp8GKYurh26ycv72t7ynYK/QfP
HZtJsSrqf+1Hnyv3fXW6t/zC+M/iXJOMtXZ0/Z/kNt+bhEbcu05E1h+4O8LlUTRKktuTM8KMcjN2
s7mmPFCC1SSaUtFgeDAyGh6N/EsGrRqTLZlqjsmKSiF8iGpnERVr99WQ5iYQ1U6SKBAu0Xku1Hw7
dt/r+oei2ttEqIYeunkdWl2hmJxNkkkCIZ/Pn40OSagiIULipVlpSbojvScFpAOJ305tqoFVT0bz
IysjoNig5EFYry7jRsfX4dQygmZHeLyxtR343aP5iVYkdMYMwev3PZ2YDQrACkbpaQR9Du27d6/T
zjwtWEZlV2H/lh/3fKst7vjeXPvL7tXfDT/t2C8d7Bw9SH4903x4T+4QZIsE7btKnSJM4m9uCVmY
jHULo3LW8nWFetK9+p70Ht2v0tIg1kWZwZRpGbSFdgRT9C49ZCbpGupzJZYwTWgEgWS+qYkNsaFQ
RseU2UTMIsShMVRFt5EPYdthioqaFcUhaVoiK3CYlSicH30jQ5Cf3Fvf+08CgAYAmYJEYdtRb1gP
DPZPnIeHX15LcEKCUxMEL2h8MkF4ruP4cahLQJ9Hoh09cb9R2kwZEEKwlNlIJPgOq0Qd5DLNaatp
7cO2bx/tGxjPJ3r2oB3D21u/+Uz5S9Sp1bvV/oRgjL9V+czwaxU0s6NDQ+bqmcpQ97Nk8LM9pAn5
FCCfdcinTva6jPh5dr/8ZYVSauvvzIVKLRiDL8ZKUSWqGkwLmxF0MSvriq72MmW2VyzLJaVX3Ufv
ZXaxfXKfslc9TP+cnmF+oZ7Wqi2/IS7Qv2LOKefUC9rv6avMPDsvX1NuqAvaUstd+TH7WH6itlUZ
hJ9yueNAlxdbtzZiymnE/v5GtKxGNIxGFAQvuq6S6OJajoLqmCDH/Ef14/7vC6+3ML10F9sll7U/
BJYy76jBSXZKPqlQPeIemZTkaEoiND1FiKyQEmvrJ9w8oyq6rCjtDBtlGFZT1SxDw4wOBvw+Hw0M
JInAEkRAVUJyDSVdcZRFPJtlq+w8+1fWzx5jNFw9vBsonqWv03+mKfoYo7yiLiCN0AkG3pcTuxj8
3krSi3MdJRyuhUsEs8SQTA3dnOdbUKWlkQ3YheM8J3VlMPgUHmzMxMoIbl3qqvy+AsUmr6h1HCfk
ekNseEWGEXiywR4n/QXZm7QCjdQRv/TpI4iQEbBum/3Qq7lWNAHd/SqrN0e209CQr0FksiAPauvv
QY9mIbisVKZ1aNIwPDVPeK1UysQabVRDWKFDUy1lYgHQNMhABYRVPbqYsJzY3XtxOtTShVq7okZi
bcFZu95sp4UO6pSZ0432tQAZeSrZxHAh0/QJqd0ff0j5u4s8Q+MuGVlf9l+BOs1TLZfEAv7rE9tL
zRYIMcG09MJo4TAzVvjA/MD+yPzIDuMNc1LJ23dLS3dlCgXna91JRUlrBl/wsblkLp8r574YPx8/
L5/P0SGzJ9tjDRLPooHgXro/u9sasAecyWCFrwg/NCftSadSOM2fwpvNBf66ed2+Wbhl3rLfNd+1
7xTShN8XDMR8ccYMWowdcErxnfxOYcj/XPB5+TlnKvQ6PylPKVPGpDmZqxTiJ5kT8ZM5KsIMoyP8
EcEHlZbLWabJoiDUGh8XUrxuZFI64eRTBMc2pbi0kkqloVQv07al19aPua5sZnU6SDPBrGNHHcfO
WTnTaqeZKE0zwAtKLMuaUZY1jWy2XVaisqw4OUMBUQtVzRJ2ZgE9hNJMoYeX04gT8C+eaAJWYDmO
50Ho6gSJFxGRhy1Q+vICehmaLo1+7XK2Cy+bzdoh/WPuEAvC7NKVJeKQY9QQ7cZcrTikoLMKWlRu
K/ehl7yRLQJotGs6ZyLeRCYu8FC4y1xAPJEjYoCbsMsWR3PIzVVyZA6o6QpzzCrSNwA8NBAZC6YD
VexHNmnDpVfhUvts0HOvQw6qOIhweEd3XGfWWXLuOEHnQNsnfFVfaR0ZV9T66jIop/ENxMCSCgtw
Wl5WgcTwwBDCAFIxk4H9gbBt49uY1xtiDTDVwFYTYIveBBn96ZXW/wW3/z4GeXobvc2D4TjC5mni
33RXa4wT1xWeOzNee94zfsx4bK+9Xnv8fq1fu2O8eAiP8FrYNBACiUsi2AIFNewWmqTqaletyCbN
j61UpY2qSJuqUiMUUQqbLlvRH0XZSvmTClUpQqgS/bF5VM22FBFUtdjbc+1FQJWMfe+599oz9rn3
fOf7DpYlzTRGYEx28w0sdubBujD6ek3tIePG5tZFzTSw8XRmFzxdQOIL41FEHTgC9oAnOmC8D8+1
OYpQXXQKaBpYZekPZW9craP3tgbdjqtX3HEThfcl239Mftz+wmjf6B2qA0rpYCCUaf0LnZupayJl
GJQmR9ye1m3032qfK0gahnDs3t/Jba1LFLmtJEDw+AmC+hRQO0SNWavOzSyaFWbFWWUmNlO+xl3T
bsRvlBgpF2MNLspPsKe5T4r2QC0nHajSuYatITeUoVgjYZYLtW3cbnm3siW4LbYzsaNs1Z7SnzJG
a6ftU9yUPKVMqVPaG/Y5eU55x3s5FhRtkiwpUiYkh5RQJskmtXyNlWt7mQPV0RodAyxoqhovlyss
x/MlL8vY7XqsXCmXKoZzVs0rSKnwgqDyvZP6aBAF88YLkakIGZmNoIhu5HJmKXs7mYyXRsHByQqq
2Gx2Q7fboxXDXakYvBqPF0q8u1TiYa+9DK+V4obODeWtVMzLUnzZXpECKBAKZfL5nEsmh4CIFAWz
S47Oomw2GOxledAov3lBRWrOWETifJ+OdJzJeLli6b/W/6rf0mm8gFlFv0xWiRJhR0cuVnJxQOA8
UUKly+QVwiRq5Mh8+EMAQ/puE6oGuZVupsdXQLt1o715nzVAq3Q6ud7EpWpHxOFghzJkRpzshjYe
IK/TnMx7P5eXm/C1/DLuoDXzTViRO1P5e5/DyO6Q62J9RpTrk0tL2Cw5luxgHLAKIT/RbGLGGSfG
Idp/S3AQxKzJLa7++xJjarhUgPFn82A9YC0moDQEyy83vHgVJthaLk1s2Cwn17B7oaviUQ0zKthk
QsJPu7UgmUafhHnr+kXJtGPkSGYRzIIAHwidFVxixPpwU2BNwfeB8ulwHRQhHaN0mc8vmDL4r0DT
oB6RZclUoGUsj+nqwlDtGifmHg8uYG5ZLo9ZdXjMRMFtJqEpDtVkOg9TzaSlQPOYRdzglzX869Dw
7ReUB2B+9Pr/sgY98gEG/v1yZhBDfY2HJeQKIs0TrhTxah7hZKDieXWw2kCYr/3ofDIc4dQNO7b2
x1B1IDqwd3J5z1azPZrVXdYrP96Uzbb/HPXHDvz+V9ufGIZUENC8Rbn/6NFDPk8vJAJv/8Q77cWX
B6ho1C1qWnNp6RnFGyejUZu798XVeycGMYfz7S3UHcgGRXTCepeR4ajE9BtJ0lXOqYerP7Cd6SEZ
xuZ06A4fk3b7YkzUGfXF0kOo6qz4H3ceZY6yx/Rv+A75j2ZecrzMvqy/6DvlfynzGvua/ibxJvNT
30/Sl4mr5Y97IkCo6XQmlWJRR7zpWPFlimuKL+bo032+Qop1wxcy6XRH66VTcEvKx9CsIwNWB5p0
RNZUXxxjT4R/G89HzF6prGk+HVOdf5ZFN9lbLPkce5L9J0uxkw1mN3OQoZhJKDJEqzd9TepDUt9c
H9k3ezCD8plGhszopfLZ8C+hYkjvAvE2stwcX27dgYKqOd7atXls0ydEY6S1nO4iE0CIOkh0PEQ7
YDFKv5JlHjALGscwS3+pOhMRlme4tHiovm0gFOswBo/e9WSz4ZsfKnZHfxqljISX0duvV88/sW7n
YCFsJtjg49EN7UtSWJe1EoRDvDe+uV1E/0kmnAwngH7zhsXGvW+deXVTJlVSpfX758j5UC7CyzzE
QRJY4QTEgQcdtIacDtpLz9Fzwpx4ll6k7XMaErTTwkB1lHhaGvVQfloTXdLX6a9JN+mrkp24K8sb
PEFcwkatos32HhvkaFGSohTtpiia4khaQryoCZREivSoDdkKAt8jH5SQVEAkK10m1xMiQZPrrQyF
cnPwb3KjAioIlnBSoARfXmtouzVK43NchSARqavaz7spdNed8ZE7y7vk5l04tTvNZRlekEdbE/VO
Z8KRdJInVHnQQIPPTC55kbwCwuqLNYNTHzGRBq3dyXvi6lWLgSxHFaCjcZAJMJAsPIuqprS4+pcF
1aQTbjy8vuA26ZNOPPzRgtOkvR48/GzBA0OpM7wgPZo0ICPsR1S4gsL9WIpHBsMeFIbKsTpIPcvd
u04+1/7o+brLTyd6KKL1M7Tr2A5N5pDe/jRKpfRIcXvbuPdRJNN3hCBIYiN1hHrSdpxQiSzxfSuB
CJH2aoY/lOh3KFzC6l/QFItbIDSKoPIAD8kIGdMGBeSVsiR/7W1IU+9LYkicFikRrzF07bwbufVc
fhGdmg/vOdBFw8hKC3YXujUgNEZAmcG7u61obWtN2MauvMEhWyqqHndPN4qNL19GW57eyTKCkHEm
h7cPbjxxhnxmzOI4nsuoyeGRoce++YrteDJ3eF1EEKXhTGHzqb2Hz8VitWfXB0RRXpce2Dqx99g5
YnX1/i4gipgnCPoXBPh8cmB6gCQQmaKSUAo1cZa7Qo2h27BXPmK31cvokEFsMuMmFgTLTQVgc2w1
SQtp0xBksBXzsu4P/A6liDDxJzRMdPZhpNVceZAK1hzHeHbhfA0IjkX67V3fBruO2nv+ccTwcbzI
OX1KYn0oVdt4fP86aiw/XIlVQpJkZ+rZYiA2vuc7z1v4NNtL1JPEB4RG5InXreG3/G/lzuYX8x/k
/5bv+a54WvuheEajvXogTiBaCjtSvHchZUU5YsFp8dxAI1AbzSIpG8pOZ6ls54jfjqP4+3RN8oQ8
0x7Kg/2S9MLAw4eLnbrbbDUnVgA1K8vwxl49fKbj4N969Ih7a8do+4r1b481WE5gVVVN1UcGHzs+
gw7tG2FZXlA1BY66uunEmfZSymwOw0E6HPV0YevEvv+1W3YvTcVhHP/sxTnxfS5t2mrgWtOp+UKh
y0xjzjl1qS3frVbNFHzJmQrSRXQl0oWZFyFeSfQK0m0FEUJ3/QVRIAnRdRR0EdmznVNhJPPCm6Dn
8P2d7+93vuc55/c8v7ehVXthcfhYflqq0VjjKvVOSrJRbSo+tI8U6EoET35DHxA8gASRJUTAcBcS
ZyHpKCSbIcUBqUuQbhB8hMxvCkw3t4dZ/OUILLmQ2wV578E6CAcKFdgMCvJTBF/B0QzOVigYBle1
guI7ULoAZS+h4iwcmYHKN1tRdUOBu2grjpdDzSLUXoeT0g/PW/BeBX8PNH2GFvEfWIE26Wf7KAQl
Lh0+kF+lexV65Xt91+B8NoQ8cEF8heWdwU8wIpoxI1x59h/xMC65G/+gIDK7M0ws/xuQ1UgTm3tm
dFGmkbGuMRDXdLEyiWQZ++kZmaYs857snL2W3DysisB+0HHIWVBIESWHS8vKK5C1s7LKLU9qqJXS
U+9t8DX6m5pbAqda29pPB890dHZ19/T29W/zxYf37sf/rd0zPTLzsWMTppfSIaemStw00EgrnfTS
zwwLLNostn02q+xOxFRO6bGbOlE10R5ThUR1+6dqc+Pvl+wFWevz63Prc2o+4psursLIgOpNJ/lF
5XrhZpUbhDmjmdcnSYuTapVr5Yx2SeU6aY+oXC98SeUG4Wt1vkZPvd8VHBoJTwTC0+1jI6HRnbZJ
lHwSJw/1+HERZEiWpTATBKScluiNST3EqLAwl5lkWGqRHb+127poxN5p0mQcdEkctGTIacwr4ZyS
3MdmkR7NvGxAxuiAITZslDsDWpME/5f9maYTYjInbCwaxRGvExO0T9VsSdW+//mLc+nVX7AYY+qV
Deta9P54+darzYvfvUZTYnTTi+Yv5vkH/t5H+AplbmRzdHJlYW0NZW5kb2JqDTM2IDAgb2JqDTw8
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTY5OTkgL0xlbmd0aDEgMjQzODAgPj4gDXN0
cmVhbQ0KSIlcVAt0TVca/v69z7k3IiGE5uVxriMReTRKEK/mknsj4hWqdUOMeyUhQdKMZiEYKvWo
i2kMVS2doVLTjq7JSb0ZrWLKtFFUGQuL0MxMNFFm1uhqlXvmvzfqMftf56x/7/2//2//IACheBUS
OWNfSOntWTdxBfCr3Xw6Jr/EU3b4w4QLwOQsgKrz55ZrP323MoXvrgCWxdPLZpT8O/zHcsCaB6hZ
M2ZXTPcOv9EO6NwMDGgsKvQU7CnI7g5MVVinXxEftH3R4gVCqnnfvaikfL7R1H8t708Csmz2y/ke
6Md3ABO/4X15iWd+meUUGjieDSyvlXpKCotcpfeAKSEcz8qyl18p57h55TX778vmFJZF5iXcAMLS
OKld6m/RVR0V+DrJDYgBzOv8sT2z0Zdt3ldnQffNNOtlOFvr3vI9XLFYhu5oxEZ8iin4Ukg46Vm4
oFAkoiBoAEZSGCKgUjDioWMkctAR2fgHhaIGz+E7ysRSisVYbEE3jMEzGIp12ErDzZtYinNUjJ2s
/QHZ0QOjKMu8hnHIMfexD2AQ3sI71AZd+SaYdPMqW3gFK3EQF2BiEjapW9lKDsaj1NyHPJylSTTZ
7IQRKMVibMI2HEYDvU5HFNV0oy+mYQ5ZKZziZaX5AdLUi632mMfNMwhj+W1stVkkKpnm97CjUSGz
iCsajj5MpXgPe3GFIqmvzEAbpLKvKViEGhnPMWZhFed2kBZSjWxjVnM2/ZGPJain+XRE2NSL6h1z
AdpzfqkcqRfV+AzH0MTWMmmCLPGlm2NACEIinOxpGVbgz1y5o0zHqS3ZaARb/oyu0nVZKv/Jlv+I
W/gBP1I8FdNikS4q1d4Plpp7EMcZ2tnGCEzEbHxEcWSnyay7RcwTi8USuVdeUeKV22aaeQwWpLBs
Jf7EeX2Fc/g79yuTRtMFsVjuUleYCzneFBRxFsvwPg7gLqnUikKoA2nUh/pzZgvpCF0XnYUuXHKa
rFHXmBXmWtgYK1NQyJoz8RqWYx9O4waacIuiWTOFNdMph9bSG3RcnJYTZZ7cqNiVjcpO5ahyX22n
HvWd9dVz1f12emE00xRMxwKu9X6mY7hEkmKoC1saQtlsaSpNp0VURW/SdtpBe+kEnaGbdJt+EpFi
jdggDom/itPijOwsE6RD/kHWKTblkvKz1fOgs+9T322ztZlo9jGrzC3mZfNWoAudGPHpyGB0zeJZ
sAxVeBPvcs134xTOM+6uBagBd7gHP5OF0RTFEXUjnXpQEmc3kVw0j7y0nqrpc7pODXRfQISIbkwJ
op/IFnmiUjSL+zJY6nKonC/fkl/Le0qF2ptpp7pHvWNpsMYG1d3f/OCqD75i30bfZrMvY9HCyAvn
N5eKYYy5bO5yAX7NNAdzMY9rtIArvoWRU4OPcQgnUce1P43LPKH88frpJnfiv3gAHwnup0pBTC2x
9+LOZDBa3FTIvW2hhVRJq2gT02b6PW3j+p6lr+kcXaNv6S7nBJEshorhnFGOmCymME0V+WKpWC12
M30lLojL4oa4J8NkO9lV9pBOOUO+Lr3SkLvlN/K8EqcMVbKUWcoJ5SxnnqWOUKeq+epqdZu6XT2q
fqE2qKZlveU9y35LozXY2s+aY51gXWX90HrIesVqBvVgPI3m6Hvi8VpPk5UUUUWm2M95fyLK5Zdi
A+18QgKqlyMowFSxXx4W7y6qkjfkR6ISUByB6yE8xerwF9Sp55SOaiNOiGh8z/Nwg/SIT8TbIpL6
yUHKcqWOp04Fx7ldXBNWUcMSTdyNqXiRovAf5SXc5vqfVr1c00xxlXaKz0U2I/kiqsUhvI2tKKT+
HF0B9uAe1tEBqdFext0SnEEz6h9Hq6Q8GCbSLZFirmUgd+gAjTNPiJ5mE7/667Qcl+U9xv5LNIZS
sAPfctfPUyp1VXxKDM7y5OuCzYzaf2EXv8EvlO78gu7igEzFJKWee57y4G8+h1ouX6MfxFBuZ0Rg
co/1T2OewZt4VvnnaBvUMBJ4igRedBNOUTeu4jnLJbyDN3BQdkSsfF+8Kkx5UtHwO9TLUez1Nzyf
OlEqWypBMWC329OfHzJ40MABaf37pvbp/VyvlGeTkxITesb3iIvtrnezaV27dO4UEx0VGfFMxw7h
7duFtW0TGtI6uFWQ1aIqUhCSnHqmWzPi3IYSp2dlJfv3uocPPE8cuA2NjzKfljE0d0BMe1rSzpLT
/0/S3iJpfyRJYdpgDE5O0py6Zpxy6Np+mjTOxfxah56rGbcC/OgAXxXgQ5m32VhBc0YWOTSD3JrT
yJxb5HW6HWyutnVwhp5RGJychNrg1sy2Zs6I0MtqKeJ5CjAiwjmwViAolIMyonWH04jSHf4IDBnr
9BQYOeNcTkeMzZabnGRQRr4+zYA+zGibGBBBRsCNYckwrAE3WrE/G6zWapOOeNfsD8M0d2JIgV7g
yXMZ0pPr99Eukf06jIgFDZGPt2y8fYZr5ZO3MdLrjCzW/Fuvd6VmbB3nevLW5v/n5rIN1hWxmW5v
Jrtew0Uc+YLG3sTyXJdBy9ml5s/En1VLfoW603/inqkZrfRhepF3pptbE+01ML7C9nF0tP2AWY9o
p+ad4NJtRnqMnutxdKrtAO/4il1Rdi3q6ZvkpNqwdi2FrW3T9iETEvokU/joLsAFxP3cyPGPKkv+
iPQRDAhDy9c4EpfOOaX5f4Vp8OansRivXGIto4A7Umy0ynB7wwb6z/36hhobpmveu2AE6Leanz7x
PDyxxIbdhZ/14+QR1Pj+F95ITDQSEvwQ+R/jVR/b1HXF773vxXYwDzsJhJUQrmMb47yQxHOStgmr
80xISgluEr5KgBKTUfPRaRiyTWqlLe60rlrajqxUKkk7SNetrWAq5gaBC2yLVG3sQyj8NdIvwgTT
VtYt6aZtGh31fvfaSUGrpkF+53fOPeeee+651/Z79hacKWqMKLuhevnXMuyoL+n2gNA+0one7uhu
qkX7KyrkAT+dsUgvjHSqa3PO9pDeMkGs2qruNItLz9iMZ8FG6UnNeGanx324yaeIfC5ekHYEZv9c
7tKS1t1NaVr6P9yP5Pzt633tXVs2e1oH4vnetm+4w8r575315bV0SctmrYzlNVamKS8u5bbZYGls
npvWl+LPpi71zozdgVupRqinLe2Or87J7jkVFf/npEx2Ws5S9Om0fJnppqo77RV32HeUN3dAQ8F6
gLVv2DIwMOcOXxu+gQYG2nyetoH4wI5MNtXr87h9A2/iV3LZQLI1PnOimezZp8vSbc90YxO7aVO1
bLa94pNW8pCDZC9kdztKVPtv//eerZEulgqbwTFyQt9P0njxCAIdDkK+aztG1rFG8gyTfIzchfED
+kESRPxK2GHwFvgZxtcATwFhoAKoA1qBtXleDTTLNYDDyFEp8ygm5Ov2/WRbwQXiLthEqsBdQBn0
Sv0aqbE1kvVAlVauYkuh18AXsD9LKhFXDrsTcfWSYQf0PrIX/jXQQzIn9lEMngcUY7wC6/9W1gxu
0V8lh3SS/TP0AHJvw9wq7VnyILgD3IHxlRiPwW7DHJMdy16Avgp6FXqzVo6rvfeRZcCDmNOOOrtU
vj7SDF8J1i0C1wJF8C/QlpEf0bfIUfBWvZLMVftGjNr3pk/3BL5f1fQZkDXK+m6HrIk1Zj8C3geu
5Wt74L8g67odhHxRqyMrwCnAJ/Ozi9jzOkLhbyq4SVZI4Cbdwr6uA6XQP0CNXfpO4pIvqvpLWD9B
atgP8bZ0Ac8NhKwC+tSdUmeczcL2AwGcx4n8nt1yn7DlWaHW7BTyfoiYLmC9vCfqruwkbj13hrKP
CzD2MNAD/cu4f90qBvHIsyJ/hypnGZD35jYE5ZozkD2eQe58Vf75wLeA70kbPXgU81rlmSFO9mdN
vpYi3LtKdfYHyTD2vwb4HOCy4b7nYaj7dZyeeTM7plUJx7xwTiktU4o5On9hmEfdWhM+oS6cAz6n
2j3EA4SAFEZ0hIVH3cXhzuhOLYwACzIOjABpQCduyBDQCVxVIy7tbtIPZAGNJCGnAYbxz5Nm4CDw
M+AqUKBG4wDDeAgrxCEHAYaMtbDdkBYQB1LACDAGTAN2Mq5VY51qRIcgU0AamAR0sk9bjjqWw1es
ecgtHBIn/WzIaqT9pJ/243WzX+8v6Hf3FzmshqXLw9ZeKWqkCELEC5OFqUItVGgVdhZq7kJPIctk
x4S9qQ5kFdma6t6J3YjdjGnFg7ZBOxuPzqVFZBKYAjQyTt2w3LDc1re18chkZCqijccmY1MxbfzK
5JWpK9p49WT1VLVmxcqawj10H+3HO6fO8eLYTDuo3qPt0/q1g5rOtVqtWevQ9Lgz6Uw5tZDTcnY6
NbfT42SDzhFn2jnmvOQsSNvGbJdsV23TtoJOW9yWtKVsg7YRm43ba+3NdsumT0db2Lvo6AhkGmAk
BTmoNLfyjEFeUvagsuOQSWVbkJ1K80GGpAb4kOsdxKUgBwEZJ20fZEjagA9f729jLAk5CDD2trXY
G/Jbfub2e/yM+Om0n17yX/WztH/Mz8aiG9mEqnICVU6oKicwc0KtPYG80AAfqr2s4i4j7rKKu4w4
qX3WWBwyqTQLslNpPsiQ1AAfcbEXka8H8igwCWikFrIZ2KcsGcEBxl6EtNjw6LLl4VSGDYtAnSXJ
m6MlOVqsaPSuReGeqIsNI+0w0g6rRMNINIzUsLJjbEiskrFD4r4cNdVNRhvZkCpnCL9bQyi2A/Ko
0mohm5V2QsW4Zu005FWlJSFHZuf1KE3GcWBmvs6G8X8Imos9jtHHLScjpaX4Ui0uchRn2Fmxp5hn
2CkRdINGcyQkRUuYho4Z9C9KvqHkUSWfV/IhJV2W02f8y2f83Ge85jOic/CG6cfwtJIfKLnXmuc3
/ug3fuE3XvEbP/Ab5+g14oWjwlrkNX7vNd73Gme8xjGvcchrbPMaXV5jrVemChIPMVi5lHS7kout
hR7j3x7jdx7jNx7jlx7jZY/R7TGaPAinfyX1CHlJyReUbDhTb/B6o7zeOMvQG7pVuEjhOcboVmJo
c4QZ4RmtUBGrELGloMUiFgWVidg60CIROwAqEbFDPFrIXPSkTtHeefSkQ/JcYT4BtzNHDmFuBxUI
s5Fn6CfC9IE+Foly0E2RWAL6h0jUg/4u6Tz9G0nglZLTj0TiCNLTGyQo09I/kAA7Ds6IWDOiz+RW
p6dIhC7FMJ6eZRX0x8JEcfR1YQZBrwnTD3o1R68Ik4NeFoka0BGROAT6vkhcBw2L4JdkviE8IMk8
h/EwIblPxMrg3i9iMkNSxGpB+0SsAfSoiFwE7RGR63LqLnqS4nbTBH7TZKU7RMKEuye/kYdJULm3
kQaV+X4Rky1pk0miBm3Nb2QVbaHSvZKeVFksYYYQFhFmAHRfrnNfEIkq0L0iiB7Te0TwCDp3d36B
Snk+56kfZchEPmEeRxAXiUrQEpFoBZXJmSiqJL9qMYmoooqEKaPcwvTwn1InSaiMc0iADp/mt5D3
40iGbhL8ppVxUMH/GQSd5h/GevmfYhkdIzfwMT5+mk8i9EoEquXk75nX+bsJL/+1iQirjP/KrOFv
BR7jmeA5Phpbwk+isHSil59IqAxvBDBN8NeDGUYxeySxlh82q/gLgYys4TkEPyXXQKInzcf4NwNP
8K/iKnwl9h3eZ5bzZHA73xuUCy3ke8x1fDc2sgtzHkns4jvMQzzeoCrebl7k6xvUHtoTakcPRJRj
dWIdb0MFcDRLBypYgXsZxtSahnOyR6SatoiLfON5ht9hmgIOWDX2n9i/Ye+1b7CvxI/OMvtSe4V9
iX2+o9jhdsxz/If4ao1tK6nCc+b62jd+XjuOfe28/Iidx82reTVWEvs2sbs0ltNuH4vdjZfU3UC6
jRqyeawqtFULirZtKFSIInUXlkWr3ZalpXZf67QVjVSEhNhHpAXxp5QsBJY/EUKkRbB5cOY6okXq
L/4w13POeM43c2bOnXPuGaOgFwRBK2gEKhCBUHt+Y1GRCQYwu1ZkTKthVKO2RcoouxxgVkJBoKSf
ZIu5OI3v6c1uleN53cbubKccz+p2PZ/MAXwrBfHs/EESz3iyj/b486DHuw7v74WsLU7ie3slBGfp
yTyQvck8bLARM6V44UnOEYD6mTOljG+fOZNKEcd0RIrYwtbQ9uhTyNAmjUXlx0WSnywSLrA8+734
nmT2vfJUtoU1NspT8WztHs9gco6O0pdi0Tl6mLFUcg5G6GhsN+uHkWgKYV0qjITpYYSRBGMIo4Mk
zGDYP/gEDHLYHc2FwwXQTsgxEHrNThW0vwDqexLEzUKfCurjZlXQmwWFdbgOVKgwhjB+lNSpCuv4
URUmMVguGMSZvhxkkFxLEAG5YIsqfvaxuKYgvlwQX2biPMBjeXuwsNoaElQ1BGkNYuT/Yxnu/R8G
wbWe6SPJ2LA/NuSPDWMdys5Oj0jZ4xmPJ3dkmgk8WS44lDk4wviB4ey0fziaPeKPenI9yaeIk0zc
44/mSDK2N5lLKsPRqz1KT8x/IJq6NnCic/y/dJ36j67OE0+Z7ASbrJPpGhh/iniciQeYrnGma5zp
GlAGVF3x3b0Q35XMCaQ31TdY4NeoQY/+MlTqTfU6xK+GVefp8krHSm9pCFwkBjmVNfp7syasTNSw
rWEbE6FTM5EZuy2bIulYl7f0FlzcFInYbfX3kkkpdiiKvwksk5NTWNDGExMFW0sFwST6VkxFIGQS
W5NqQSy2WZ1Qezflk2TqccGRcgFNJrDdl8wlEjHpULQU8/lrLAeXUxNEljeRWAjqxt2rWb9DzfoN
WkfrbxJ/SjxMcPNqvr+AdVHN9+cx11/Auoj5fjk3H14IL4a5+cRCYhGxDxYeLD7g5hsWGhYbOJy9
sAymLQW40MfPlDwxxbplFvQw+PH44OQ60nudwj2tLs8JSjHhNfc4otdp7gFxCVr+HuXuwDZSBAF4
jkiy+Kh7rXtAXOlOrHWTCLbFVSRbmr1WrzWABEMsWfVw86sKTz4nHs08i7EtMEaP0jDqcitGTO2J
mweX5vIZSR4Ql8Q/k6bE8pZm8LZ76dG1OfoMjH3MRu3f+AwuQBsxEN91skNr4PJQrBg8Rc1FtMhl
HDvFRq+mE8skwka3OErsWr8v2N7WAWT7gUwsduAAtKksFsuo8X7jUxrhD+MqOpRyDMgRytkpppoc
ADVwV9iirtB6zZ0Y7nJleUB8xKbujnS/xjfKr4o/39JcBH6gkfW+43CXP/yvaf402pH0byxxN/gR
4iAy9CuuolJtpTZQVOvUSaUlnpKAVFukE+AVoRw/GldtfDWya1qTzZnn9EqAKFXBNqLIjUhaO5B0
9bQpZBd5i1mqwWbxVfqojyHN3zaBSSkuaTO56h/+jW38kfxyYjndl1ScPqWqus3HJvGxSXxskjEf
jLNDlkKg2kgss4+RE88igp3sTCJe5TiE8Rs4asi5OQotymzad1TJQJ3HW+mlWotZNFNtlT/gp1qD
UW8sMgpGjbbEYXdQrUtyS6USp6XAgQY4bZ1cK1NthdWXIUEdkrJiZwZqeCRec3kG/MbqDJEc2JIB
W2qsY6Rus5wg4zAOdp2Z4uusxqe9bWsYWlscTgcvsv9+n84MVtFZgZ1bO7ZyN0K+ie88l3mzp94r
h1sXJqc/bO5b/0CjD7o6ZVfAbbd0Nra46rT03V9lR08/+2I6On7+7d/NnX/7Rydv34cXu2a3eCR/
bu2v64uZZ5o9nVPsrLyGjnEQ36qTfOMOMcNlaCcCvHPT9yXdmI4CppKsRwf/xJuIA97BBP8fpAR7
HJQqZotAeEFnxM5KoIB5viKazbssY5YrFk60gMUlmX+GuYdAf0Ek6oTfq161hD6VTncnxLU086uI
LfRweRUeypCW8XBb7RXQBSXe9taWMLRb2xoBbVAdoG84ticq1zqqvtjvtm3xtO6wwd/5kc9/8mqs
PhCo2X6c3n2hyeupWlJ9EHf0fdxRGfmLUnWS/pRe4rhq4zmO6g16AxC+1PaW47qDOsoorklvEMry
MHTT1uTMOqkzD76rYBPYcTGY2oQ8V3XdzIMRHXJFKSW8yFP+vu0TSxncLYMyd4UF4C4AuMpvQRLO
EtXL0+Pio/R4YmUtvUQikWUW+pRiQXGYIoLiNCNxWZCYQur5QyP0DW6eV0So5xRBKi8VVX61zBpR
sUvWUMhqCwHWtDVkC+Ff8ZdosjRJ1+IbsbW3sfNSzQ5QBZTYdVrwog23tnK7Vv8AYz/4+guv7wt0
3D/7lfeG+ofXL0FgdFudr8oBN6Dx7KHZ103z+aELO2ZOza3fsMkxZkfvxh+502hHmXysVOosTsuI
fFSeKZlxvFF8zvFj27uOW8WGhrJIGbULkIdzShEhIks1vQa8CgxhauqlH2BK8hFxEwG3Y7K2qXa1
lSCnH91UzLzbROx49bvuAeD1t+AcMYD7ZkXBzBgM3rd+QmrFWlrLAoPV4gSnu8FSARUsPFS46p+w
uYw2H8cosbKcFlfWrKEml3u5m0iRiHtZlsW1JXHJFmpKL9tCBXNBe5g+YS0WT3XMZMTrYz7Y0dqi
elwHYqDp5aRydP83M4EvfHr6zPv7np/62vqH6+uXdoZ6ZW+5eG9f/0vz9KLfG5rq3vPKd00XLl6a
iM+2hy4c+/X6b0M1kcZtZuGHU/tPfYaGacVzeRntqScmcl6RIiZoBeCIhuqK9LxgMhKNYDIZDHkY
VEQCdnwFBgI6wWACDbkNq/gJ01NRMQrAC0YTwbsAFW5zRTixDoYU6d9cV39sG1cdf+/d+Wyf7fvh
H2f7zmf77nwXN07s0CSO3bmJ166VBsuSQqUqpaarYKW0KkpSkaw/BunokrVIdAKJUkC0QurW8QeU
ha1ph7Qyypgoop3G/kCaoEil0qZ5m0QWCmscvu9cUIotvR/3nk9+n+/n+/l8X4kdYonIZljCqiKi
EKGk0FbQW5B1jcbwYs3NuCGwtKUakIcSKVydKxZY0HxRFNvYRHCv3BuzwOSMAUPuJccOHTnSarZi
u/AJvMJ85e6p660buOc6iQNDNoEjzHseQSYerRcFDvv5JJ9HeYaN8jEtlmIq3MPcRQ8T8GBV41Os
LkGrs1hlGaZ9ShNOaYL6Y2RKrgH4fxlGLGYX8Icvh7PMqwyBjeY8WK0K97U6L0YyERJ5JxgiC+SN
efymD71COGQiHX9cV+u+Ud9ZH+NTc9KbJ01sUgzMpNXGYBFc5BaQpAk2vAiJ2Ww0wdNp8tWjTB1S
jKlDvjE0Qxmaq27GtSbc5GSBtbCDvZeU7L0kdXvYSvsXo0H3J4WxZoP+qJ426UtN+lKTvtSkLzXr
sM2shwPtvYWxe4aL5HCchiMO/EQTDTzZmMAGY3jZOKUma/2XleALccXlZc4wvbhCDj++/F4vHrt8
+tut1g+eGxt8sNAxumt9V6bjswdaZ1uLWtnzSKs1Fzrzzd88+eHRwa5KYUP2oU4p+MTWC+/QWyFc
ET0XgJEGyuGe+ndNKRAe2i1NSdPWnDRr/TR0UfJ+LzQfIjhnEWRalsELAZ2PGwk9HvBjP/HpfkWO
6QrO8chUDliilLWQIRnEsIjRLUtRWZYsYhkkL4hRQRDJlIAF/pCMDVkSWcUyZIGwOG6JZi4PdMf4
llSXRCauKDzv94kKVi7jp5CFi3Uryyd7nHFnxjnr3HBuOpwtOVmn7ozCk2edC4735H6I8oTUWEyq
w8vNBuR+TYLvUE2lPrMMfP8fxg3Qz+qcUCz4AHroE3TQuFqg8lqtJpDUxNKVdttYPfFKtZq3BhUg
CEgDHN3wcrEoRATMqlwegGRW2hNq1f19YN8dDMNsbRnVVFHb21r/8Bc24b9H8Lubu83B5XFtJKtw
JLX39zfwU8c2FKqa5LPtwBd/yK775PyP12Q8tq1I6XDEv+Ef+K1WN+TalpW/ebZBTZfD+iWkrMzM
+/m+1EK75+71IejrYzAIqn6tHBlWZ5VvqSe14ynfPnlf+KB8MHxcfp47HzoX/138msZzCnI2Kg+m
ZpSn47PasdRF9pU0X3L2ZKa5qdCUNhu5LHoHBDmc09F2omMQ+SiUk9uNF+Sw4NmrM8LemB/vLMlY
Vscd7ITtr17Ca11BhmrNL/IZnvDDyeTi8LsNbb49akKd1lhqDN9yCy+A+/1FgLa52ETUyj7zuYO/
WOuDYiynpLhQ0InbPr/XTzjNCSm8jbgUNIGEYCO/6rFxu5jqLBSOHsWNCQQ54xZYsuWAsnM0OGGa
LAMxDqrlHAh+OAfC7j7ybOvo+uj73/jTp4Z2XP3RzNtTk/889+fWzy9ew2OvnTyzI5kteT37Wp0L
V78zderSy623T48f/9r0vp/hzQuv4R1XBnOlXuqPRYTY50D9urBRH/ayfr6LMQOfDng4D8c7xGEc
1uGdgBMcYTbzI4Hd/BQ/ywuH1jxbfIl9iX+dfZ2/zd7mlzxLPC9k9ahp6Vk9ZprOlq6uBZKv7+3Q
HdGHfVuCwWt+3Qci791CyDVO96azes60fF6vQ4IjITKCnVdtbKsXiriIcEgUMgIRBnURZSDDB9Np
PdkdjXXlcySP88FQKBcV9Cp9YKO8nSMxX3fxV5iABKzHXohdAQyi1pSaUm2xBv5QqjXdCXYvQhLY
K2RTreYGEea3pdvupgLE8H0kfdz4v75ASzqIzQSWe91aRLaKkDmrijyoastumVfA/QZdhaKX9HZs
nxwJWlbkhX0d8Y3V7uUHuh/IqUJAgTH7xBrhwP7aT9jW8lvlmf3L2359uLVrT1+HbccEM7GbOULH
rcPHj2kixGgNXFw+gBhl0Il6t1EfSA3xWZ2YpprVw6apZXVsWoGsLptWWCYE+1RRy2hEGwzw9J6a
2GwN3eRxD1/nx/krPLsTGsInswZd1DS976aBx40rBukx6sZOY8a4ABNu/RSkQGNiEu5WtIX7Y7vQ
rVF6Ah4Fe/XJgaxWvxGDWoRSVo4qSi/5YPWByW/pWAwAEPZ9h2yP7x6Dcfuk3j1w0jIeqU+mqZIH
0tifPpwmPZVN5dHK8+gN5LFTZTyNplPT+iyaS83pp/Xz+nv6v/XgeOVmhWTCmUgmKuUk2yOGxYgY
RTlk+8vcasiK63THNNuQZdbptmmVsnq/aS2sPFPfiPRUFiOUT2nRVEpD5TJC3Xo6qutphMt6islg
FZX7CSaOrafCsg+hgYomqVgd5K8H/hogAbVCkfWn0n3uH6pQPfPHlL5KOpMvFemaTNeKN4vkSvFG
kRSTA5UFvHXeAMwXcNfThcKjiw0XcqBoYbJASQroJylJExAD+qGtW/rEqz4ofjxgAtAn3EEh0TZm
ytrGJBUVNFHA+P7w9K4KH7aAzOBX7jOlvDqkzA08TvJdtVxSDCgPVbuWa+3x8p3E8kee0LZGq0fo
fjQfILBYIJ34j8zXIaJG4vG7T62ic/OTAvuHu5u+FF87ZNs401cKfJ7Z/uXeDhuIjfpAgc5BzFUI
1PVLKLty58VgNbuwcqe+I1AdcfCpxFJ8Kfsvk+30pRAOZnWvaeKszplWiAbT0ophVEyluEiYeDmf
ZGDjL48pM8oZhVFOlEDRtfbFrjuEglKQjAYfC5Lgk7Zzn15QwF2Qh11hB+ulVAe8QTcASUbyUMsE
TU9nrKiaiCfjhLOiRglnVGjMWK6Es/F0CSFXzjuPHqXuSicu1gDr2vI9TPuNrFupc4zcLoJAKf7D
dtkHN23ecVyPJFtS7FiyY8ey7Fi2ZNmRZcdJZCdxbBwB4SW8OtsohNUF2uNlsEKcW8PG1oUbYYPS
dXAbBJbe6HqFjZeVrmuDodvBtrLbbtya221X+gcd1+a2O1Zod0vZbeCw55F923q380l6JD+2z8/3
+X2/n5/qX/RodfVjC/3+/hJ0wsjcS4c3/SXs3DM+vg/fMndgZ1ZSFLlnJzGMRtPPj/9U4vHj1Sn8
yPGJZ9EKRiEBvQNXUMaS4ItG3xphRDjuIWiZl5cLSwJLpE2BJyTKBdHbylk4K9me2urf7d8tHZCv
+38rT6foE81/EP7J3/fdFywp2l7B//iaucbmAC0zHBhZtNSwHPwcdJakLLllWRqTD0EwwuKBsH+v
NCPNSgQnFaVpiZiG4OqNByQ5qrT5K+A9wytjmDWSbGuCIoV+Hw5LktVK0dCCgMVg7Fici+Pxd70V
Ajea7REFbou6ZnZ7sRE0Pt027xLwQZ1gB5BH3o2giKsiH0eeZN5BEIZ3ptdX8/UGszxSyiJkypYQ
KJUcsDZ4sy6gkKFYwi14FF+0VUm44ykQE+BJa06mgMpHU5jg5/K1aEbJjNSstbitcFva7FmNtmcD
fJOnADSo8pDZjqE8MKUuADMLoNT1FpaqQxUgzAAxNQ9BravL6pqP3ps5/PlFXwGLDb/aNbdmbvlQ
9tAzq498H98+N/5J9fsvfvnY4wVxLjPULBIKvh0/UX1Z379j8jsoy7c/vEWGIV1lATCyfPtadXeY
sDoAw1KatZ1nvVqS1TjVmZJCWiTRFe/StqoH1YPxM+lK/HK6KfsfQBowPNh6tkvswrvOdEDfWx9q
EUMiECtwdy0OrscETsCFMx5VY+koa2PZgC3AkqPsqDrJnrK9bnuTtWoqayNlS6aDkDMeZjXYAHaB
MfAtYAFrsSgHuaICOMPhEnKGrTGdY2kRtoHw0WtiR5uvtwKyP15ntjsrZ+6UoAXegwU5U6rBFiTf
MtI2m8W4D0qzd0p18EJjc4jItgzRtqlGUCbcmi+PG/Yg0ZiJVbJTb66XXzTWhpt9idd80k38wqa2
vD++ZbenxUidvfvpT83947ox8ki7KPS6FCVx/8jwfn3b+KUX1959fUEh9Q2/EGyEmJU/+9aTS5Jy
qi38mae2bfv62Y+FiLtVxbEb7+8ZbF8/OP+ze7+34cUZzj4/NA8ptQxWrB1WbAg7fwmTYAfGC2kJ
JUOOc6VDkgHL6KpEtsMBDm5S1AOoCx9q4SSJCbWwMLNuCsKDYItICa1YCOdYGhsGSLi4IdEsIzI4
U/BxPAjxRf4wT/AhTgQhsSiOiYdFUrwM4hiPv/yT8M51qKJgvOc5eMCymq1HfDVfI5+qVkeiKoyS
csnEUsQ2/4d9zGiRnRZ7JLSqP7phs3dhb7LaW8v8xw8W1nqjsIk7MrYr7Lp/+7/BQDb3Dh4Du5CH
Pfrw78S7xC+xDiyP5wyPleOyZIjLdhr5/vShzLepyQxRQAu0aXlmKgu+Sp1Ons9fTP4qeSP8dvJG
5s9JJkMtopY1LfMOZNZ5t9BHscnMKTAFpmi7ToG9hRPkd5PPd5BYoVh4onljYcR7zHMBnOq9Am4V
GujmYuELOWIpjXtcHjyHfuVNb/bDHOjUaYamtESrllC0hJrXz+lv6ASpz9NX6k/r39RP6j/Sf6b/
Tr+p39FtwzrQc246TG+mn6JJnM7RK+g99EH6JH2a/jX9Ds3YaD89TBNuF03wjVFRg9+obknlluKd
E1gplcJ5Q9XSLC/yG/hd/En+An+Fp/7Ef8A/gAryhoNL87hI4TY2ISZSib4EmehXF7KKqODKbQxL
MX3MGHOFIUPwgmMMB/dABbxhcEZhbwE3ChsLeOGHHuDxo3/XWmzte+gHfg3r5rrx7k6LISvpXZaP
LHi7xbAULRstpMU3r2cNpJGO/agOS2Vt5Z3ybFn7eQlulVlIFciG76Ga7HNltRR8H1rwLILs6uwM
V6vSERc6we7ILFfuNzSXd+TzWEkDI6YDd/b0BuQGjiBZpSUaVmzRbNQRdAYxe4gJQqDtJbqDGBdo
DIIGCZ56yFwQxSv0ZC5f4xtozLBpGimXMHiAsgYpR9MU2CZFYT0rqLTRrkQGAAO39hSWOXICM5U7
u72op4rGnNbaLL0THzh3oLi9AjJeo3V+XAhEB3J9a0au79w/6XU0uBsFf7BzR39xfcOXcrGwL9n5
zMTnVu8499xj27vVFhfvEbXWjkUr9KX7FpcXxCfmjhphTuGXLVx+FGSXDHZ1t8l+uM+1hzOkH1a+
F4uBQYN1LaYxL+fFAe9zRkRvBdw1/HJ0nKCCUZvNMcKynM2LYRzMU4MSXCpU79XlGXQxenLz0kV1
WsXbVUMtqsPqC+or6lWVUh0OjPWJPtwXd7oMDrRzBlfkrnLTMPt9ravKZoqWzTDjoPH4wn1cBRlQ
yLy+6hX74CoOITvIpjiIoZo5Va1NVetT1f+Zeq9OS9wMMmiNcHAQTUs1iQWFbLQokahfCAi4lYmG
FIWUYqDF7gtijQ6xAY5lazQGhMZgEAvTwdgnJI4jiReuM+SnLcPMcGgscoz+geU0fZGkv0bvZ/Ax
cqxhTBxTjlkmIlYYweXSEHBChVHoOgBSFjpSOgYdK4P4FqazGb4oAcCF0Wc3nt245/q+FaPZSYlq
0HQwbm1YkdMHOrpiCx6xrKhW95SnD5z41772rs3kqcGmgB9Xqi/NbRyTcwO952+9XexFPr7q4Qyx
AbqWjP3NePJjK4gwYIg5HbyGX5NvgNvgPZxqoEECj7vXiluYreIoM9owEpxoOt903l3BL7ungpfl
a8G3FCcGPE0Y4QhMY7fgHpkGtwBOAjckoHCTh/fxHzmB86981EaFl5I21gEcGkBCdPr6gNnEMc40
C8AL4BX4CeGC8iH0BDYgBvBAJ1Wfh65TrVp6mgKU2Z3YHWnKF+l5zsxZDXr7yn+TXf2xTZxn+L47
+2zHd77zne2zY+fOvjvbiZ3zJXCOAzbxOWlCVpKUqR3jR70yfokNJhK0llE2AW1FW/5oaDeplZjU
wB/b1P5BtrCSUk1kmqjWqRJmkxhr/wBpqBqV0lIN0KQuYe93dkDVouR7vzvbn3PP+z7P+7y41YL5
BRKN3zroNNvFKb4C/A0Cj9fgpisBi/FQAUgD7dIOfaB3ljCrmhTLOv0V0ymC+dRH2crg5QMf3Nxz
5Prr7w73l8d9tCQpPar11LdKG3o3fxX96WHU/uGl18+9sXXNYxO7qrHY6vG3X/qqnC/gnvAEcGUY
uCKDr33e1t5if8O+z16IuASh5CVkXiYlxfB5o2cV+bLGeUAcPcCf8+gsrcBm2wVv/iWG8frBtjxj
x6TDqUzIA0cRhJcHtwE9kI+S0ZwDYAAQ4tATiJyFNtpuNlmGwxyQDEc7BHhtNBsmOWnOmKSpwFxh
Y77YYfzRFZY1eBcfK/Qfjz4UTYwpcCh/v3m12OywYFOAL4v8vcX/onv1JmUekqZTzbGintbSJC1k
OrNdWZIOpFUxkyVyLCzpYCqLslw+2xo2gCU5hyXmJDspTqqTuVlzwaQnA0eF56Sj2mTXEeOEdNJ4
i30zcrr7V5F3uy92B45xrwZJnMX6FofdZpPdZovdZovd+PQtjrMF8khhdxGzKgs6OoCwjjrc0ooi
zngAtVJeov5Ke43+5WfXHxiZ2/vU3t/vHdpb9jE9gy8/vi8dTZuWIXVunnCPff3xj0KppCs1/otN
AzMv/OHNL5+3aqh9X6QjkVs68VpI+eWZ376TEU82q4CqA8fCRBIV7c20sCFUDx0I7Q3vjh4OedJt
vyY/JD8KXiWvUtfZ6+F/U/9h246GQS/FsLWJ2kMdUA9RR9UXqROBz9l/hX0574MI8vp8eVwGSS/l
rbuTEQKNROZR5/l4RvS455E8x/h9EZxdP2Q3YsdUK/IDAjMIJxtoj3HyBywc7WiwSLSbalV9Rv1S
danJrubosopvMc+JstCMmR7LqRoGyqnBIz6WajGwjvUOBtBbmIP5PC6WfL7isPDuEp5v7tZvIf6j
qeYQGpQ70s0hNCEoMtEeishIDsZxkmBpDaH546iex0meQqkmG5sNDydQgPx5rBWyhqn60gPf1uHv
V3b0q2Pzhxv7Ni2989rVL7R0WLNSZXTv4v4nh74bOX185vilz1H49tkzP1GE1VtOawDFIEFQgzBz
GChvP22biBYVneRowqPQvMeVyxMIdQV5lmEEEPw8zzG64rmsIl2hgbNxJV6NU+fAiqzKvBBGRuDF
bngLtOM205YCVc5UzBsmZUpSO4pi2HpicSsqd6k2RPVUl/nJDQMZ1wiiqwV6jmlwiLvWAIW8xrJC
F4Mxh4NwtM2uVVaSaTAkOAymhznGnGJmGJpgeGa7s20wdxgPE0uaPSZZMP+Suoh2IRqGzvzUBHD5
IJZF6HFTt6bA+ji7z/j7+bt/hOwN737sM4AaN8FKZXwJ+L2IZZQHuwPE9uDYWjHF8TCJKRUpgX8e
IME7F1cXs9YjEcWK2mxTdFgKrw6jG6HkpqV/VIuhV15Bfzt/5NDj66x1tIvhpY4seZIaXjr0vWia
0nUU7xkjX90xbJ5aeLrfGOxL+RJBLtzG9RTPHdqBu9UIQbj6QU+70Y33CfrBnd/51xQcZDYULfcI
SW4sNAqkx+2mI3SGdnEsoRLdCsurfDctnAtcCpBxRIi6EpgnP7WDalZXVE316QqraQldSc2Tn9g7
tU5d6dY0FIePEmDwPWoqFQiwbV7Fh3y5kGinalXRHl5vifa6omgPwd+atXDR0wtLthOWvAGLqsMi
K7DwQeuKiDgRJcUrIsmLSMS2VlgoIKUwWyDNwmSBLNgDRfwgc3CUE+E0J8KBToSTnNhdcKIdAG0o
EM0WmevMOrfgH7uTRWZ2IdvIUvjWXGmt5USztxnhn3Le6utIWdmYMdGUeUxcyDbkvV7hW8YUygVM
Mq6Zhz/YUEGFAJOhPKq4rTq3KVwWqO6ocAq+Q/BXU853hJhqALpO80qMsHAFhRywYxwscb4awBqd
ClVXzt+CSwvVD0J15QkY0LBEgxECpytBmTkzmgVqrdIeXHqP7mXAHP1p/Njw5p91da5bzqyKCUI+
3jnWzYnl5Uw5FswOgBf657eHdr08s/zzfUWPrntS7bvRmR+XU6XhZf+umOrVdToZ2Ue990PLmwa9
zkHr1tz7CT+RID61I/KxoFTlgoRAJJQgL/AJWtIVATdqldWVIN5oUV1JfIC+ABtFw9MGrT7rHI1o
m0BMghaCbT6MQQLuNucam+piGI5VWJLNRSUbjpcwGGuLOMwlNcuJouRE2zR6rFkJTUvIMdrSEVve
KJOKvF2ekWdllylX5WnYLMg3ZbpjYgHsMSTufh0TuJU2GGxa7K4uOjrtQJ1Hj/jaJ34DZ4xpprZ1
m21v3fpxYWjZMyCHCoPu/c4N2962XF6K7yy5dJ1UpZ2kCts0sDMPuOnATp6AhxUwatsFNCsgzk3Q
BK+4eZrnaT8Ip4MdKKjbwQ4ElcdjQ0SDT9LuNmJFCv0YGX8TGRzmDMvytxDC0dYAolk/mvYjws/7
Sf8RRZgRZgXKFKrCtLAg3BTcAn5/r2Xh+J5RsIIOQLjAv4GQA84KMHAf/R8cc49gGPv6uYcPT/15
B354ePoxgqCfhS4/Qk7YynoSCYJit8klLycSFWJEEYE4IzTqK8V0Bazz38+rhq50wsYOqTVdqWgq
pyuiptlZpOpKdp68fkGzy6ikK2XY2zltUFdGNM2jGn0pD3LJlVV7XPKetjaXhxihK+XObEhsG7Wh
XY9iZL4jqxYxOjM6O7ow6hqF9hPgOIUjuVx7DGQrhjXq7dil2JUYZcemYdK6nVJzBQNeMpyXjEvG
FYOyjWmDNG4TXEkpkaXcYA2f3N6hWttrN2vkTG22tlCjTFgaNaoWWz86Tz45l8Kikm/2G0dRHD9e
WVqJ9coEbjawJ3CvqeCarIyDk1zE7hws+hqcBPz7SFscy6CbvfEOP+umezKJTK+7IKP/EV7+sW2c
ZRy/92zfOb6z73w5/7bvbJ99F+fqOk7PTUwTfKVdkzbLD6YSlpWQlqpsbAWSbki0BZzRjvFjNKWs
hapCQ2Vi6iRUaNY2TEh0qtQy/lnERqfBH1QQxGCNBLSqAGkOz/vepS3rH+SPe3yX51777n2e7+f7
MGyGSyqID1YYEIoUrzjGASYvMnw9DX/U1u37bUnN+tuyMJr51LacQWVzfhZhFQOVIbazsHPw+iDN
8AXe4u3Ba5xv1DfqH2kb5S4N+nrpUWaU/w/jxcyb2eeYzUEoqWiGvOh5MdJgFlb+NQ9CRyLIH7D6
73diOOhch0jOBc45F9z/i+59EPH5z7g6dVdykeNeI45b/f+CiFlMLrH42gcK+PXhQyOPHMiNfXds
15Nl48OtTD0lyWbGfLgcjm1spY2yIFdSHblKDf6nEN30vHRw+6bt44+MTXzjROvpvRbopM9I7ULH
vrw512i0AnuSRdwFWvUhdKxpFyLqUCuwu8EQNd1Li0RNHWb3QF+YtBcz+93zXL2NQWVcS71DtbEy
8gGvi4znHfqa57dJT4SpAck919AfUrQkhKgcZaohMSeaZ4VfCn6USssFVXD4rQOztXwAeE74ncX8
jmhAdVPTctmsIIQCiU/7PF42BQPU/CJMRgsr5+3xeA3th9GDCRCiRyIyRroMtS/IKCu/IdMyxrsM
aJcx2mW7th4OQGQZ94aMIS9jvsuY7zLmuygjGUNdUMs/LdOV8jS0DRC97BKdRFik7JK97JK87BK+
7BKevBMByF5OC5SKQWQY+h2066iiX9IXdY/uol130a47SC9YemLNXaQToov3IB2uOCZ99QzaUXSZ
fsucAaT3LTt4v4/rWYfr2VWuC5jr2VWuC8TpYq4LmOvCB7kOhnEf9vAwRlKgrG41R+8v5Ptr9vLg
4Qd3fFEWoSSNWkyUzOT4NqPWMtzy3D8ysGeofrr1/F6C9WJiN/rhk325gy3uM73s/5QhvMxtMIVd
hDoMUjm03Y5fTSKDR9LH/SE9iCg2prNtfi5je8n7Bhn12rppCV7kTWr4gYZqJAw4oUHCfL3fwtEu
dJjWJW1RoynN1nZq+KPP1l7QaE2QVImW7EUOce40RSIsjeMFGKK4RB7WmH3FqPXOYOV0Nm94eXJE
XPVft2GrhpcpZ4P6lokcbkY5sUgXVSWr0IzcHmmnGUZPpZPpRNrDCEHJgKfMKCjaJilUnM0YKMyH
DKR4QgpqD8QUKu2LGZSrMXjU6uwExQQxrHagOtqKtor7ed800+Sb4nRilpnj58TZxK/oK2qgyU4H
p4VmfI6dDc4Kc3E/mqQmZyYQjGndUfATLBgKGuazWJ5hIqBLMLb1wIbi/dRR68BvPrvnwNtvLv31
jXVbYyFucG1ZMYKyXkx6Ln/l3W9e/dpp1HH5dWQODP/p109MDmxL5PunUO7lZiaCd9BobfNCIpj6
CnrKTkgVPx7TqDAe1MQw016BcQ5PZ9hMcO6E5jo0O6WVD8fYsARujCnqKsewIbGESnYqKVWd/cVh
fkO/VSVzGnThWHWxSndV7epYdbrqrUquLQlKNo+6eJsf4y/ByOXjE10jsHMiAI40Cw/LJHJkYpuP
Z0k8F1NxO0wQ/ImTeFdJatVJrbqp1XtSb0MFYFOy7Lg23JAhsa/vDg6z+pq4kiiaekY3imviJQPp
Chw6k2UDdaSLBkW5W2s6kNtQsBsDloYPzXhTaerNNd6n5GZiOvMlbdpoms/Iz2kn5O/FTyon86cK
P5bP5F8uXJB/UZA2RxAFezsJ600Uw7KC1t3bobkIfCRYkkPQwYZukP12hj8WnY11bXn/PeKa0Ner
67aOP3rm4R0/eXx4U3fP+KfWa1Zdt/dsnGq9OGjFi0U6F9vp+T32kgcHs5Wv/vnwkfcO5pMvHqhv
v/HPiQ3HsMcaoijP56ACSsiwA5zO1TmZF52WAkGG+Jf5lGqZrueDOHtOrZHTjOJcFkQSbUOOWqKJ
TnBHTZpLBMOWkKEUqqRmREUsMSgSjcWo/GlVIVY1dkXNEKuqFdQSrqaMFugWbKUPFC/d0xAexZCh
SoySCQiTVOBVNEV50dTFo+wie531QD2+anNUSYip4N47tbxTb3lCA8siMZUl0ZalqHUpj6bziMqL
eTr/u86Rj5HacrwqFNCtW5PLy+KS4+ZBDUwTFwdLigPXBoxOrq8Fi2Wuyq3j88mmMCyTQTE5piBi
GRBspLEWYYMw+dzG3k0b19ZG2EAwkyxFsojlK70ttt/0B/Quz0tvfWfqgcambZu9TDTf2PWFt3vr
YirhAVNQP0D7xqLppA/z/qMrS/RbsEfd9LP2J7iuiNjwisGSLGZKXkaOyleKV/R3xL+J/xbZkljs
7BXXdz7LHdeOF85wP9IWuFc0zsf7gv5ShB/ghnjG5myelrpV6hStIoS5g2xOaryAYY4esNupU1IF
LliVm2ZcTZxKqckkFlZIOZpEyQX0hK0lTkVvSpJPN1lJ0SXO7WNbilhoh0TlxBxNRlSOEyznLI9H
U3stiLUaQqGkYKGKNWpNWZ+3mtZZi7Ekwa/6ab8NNzif8slSB/5WuEPoQB0EkyDtHYl1WNOxpM+Y
w0swemGFOO/PAiX9OCkGN/htOdfw90U0OESLcAo/3QUnJsDtfSD97o25LDw+/NbrdhuskPsk3I1/
+TwsQCKsQSIsg+O5OyuZE0tkBTuB7I44vMF0GA5iCg6hGByCUSdxgmos4y9SFEVoKAsrf5znZSdC
Bo7nIJ0kkryfUz7wUxLk+hRI9CmQ5ZNXU8QbeOpE4vKtZUq8gQXPFip2INyo2G0CHOBZcBpOcrLw
NxfL8NOgjxfnnQiPCr6iWAaHAWdv2m3woVgG01FcWPnHPGglxKWLWGbTIKR3rfMENQOtgHULhAu1
azpUPsGRF7cCg5UKWkHzrMN8ArmC1jD0mgVSFsMXeujnhXz/oY2lD8lZpE+OHBnfNK1wuWhOzJd/
sKWrv++xk+WPHP/2gwOpsBSNe15rvXbksZ5CKlG6+q3xkRNjnVw3Gjt8eENn15aBx3sf2r33bFEQ
AE6UvnKTPuF9n0pQ37dDc9wcT5MDx1OJBXQBtscry57IIRoxWa6LszkP99/2yze2qSoK4Oe+vvfa
rX2vr3vttr5u7da+tV2LLR0bW8fGuq2UDdgYfwVixWWUAW78GVGYZMY/iWj0A+EDEqPG8EEREyMS
yPhgnAlRMEQWv5gYg0QIISQDJCVRQzvPfX24YaIETfiitznvnnPvfbftueee+7sjRRnRzBjGiZio
5MynLIqLsCxYOQ/HcCG51DFqt8sJdL5M40nCu1lUnpAnZYPsVGjmwNhD9yIIZjXWQ7jrlfBoQRPa
clfSbXgxo8iXbSHSObz57oJdxDbP4dPyfF1jWSFpNNh8mCcayfjFi1a/1N7sXnFq/T5b8XPPH+9g
c/ljA7nPV0QrB0onBlq9h8ivvvVnRmmubpu+wsYMH4CXHDwNKv6695H21UmVKbK4LCFLt4WNW96q
+LBivIK9abxhYrwJs1BfTR9WDmQPJ8nsj0YybSR4kHM+n1X1yD6fW/V4fT6O54qdmSJzsRm8XnQA
D3xIP53dPIV3HmmeR4DnKcDzlN15iu08xXaeUjxP2Z2n7H6BJ1aeVPEXeAZ4iWd4CvLFKr0TqMjw
qs7wqs7uqs7utP40VOjGmVUd4WmdcCI8TKjEo36iMlF1p8qodo+DOEJWmldO4MSiTvCiTvBiYTIt
7cgI8rdEEhUnxEnRIDp9OtLrSb2lhyL9PTKkJZuebdEjYkpjevxoxKjxfHoXPRsQCLQ9MRImOmrT
QztC9LNcX/X5jZppOB9szb/c+cqq5ftCgYVkTK51qZXBJsrdOfVpBO6xvu7+l46Q3RSwcy9uanbL
ynKS1W99tnzKMIWrHyUDJ62CR2AsdDN/LDsWssROlsASoUtZr2xwrYtsU7a5tkRec427zrrEoBy0
N0GTkoKUMMgPGgcth6NH4ajynVPAmBKigiUq8hajh3c4Sz0OiSMcYT2Yc2SPPeQIBNWwGI2mFKdd
UZwWQSjHhCQ8CcQOggiEVEcVpyhYwOgIREGlKt49FfV6+IDbql53O+yYGTheAfNTsUuxWzGDRoKC
PVgfKytTrI6og3GME0OijKutrQrUB5IBQ+BcdRi4SdyLzrkx7DtR/cUaCvHZdE82l76CW653USZ5
NTyiHdd0SXqkqbapKVtJWdxWEie0LonvN0XCYXFMOrNfjJRrChQ64+UgTRFpovBMzzaMJqnF1IJL
mk6HIc0RvwZjGnLLspbQNNNIGArkhdSGl66yAo6T2/lvk+0R8nMsWPfe8ILYQhKPNCfzdzKxRVtW
DS6ur2slxGSylruC8/3MyXe6RKQzb7l/Z/4gcb25oGYOU1PDtR7PLc3fbVm9sbN5WaLTbzZXhg6B
Xob+pRxBuY0L3oW850a5BcA1AfCvAhg3ABQpDyfFXxbEsm5GhLszIl69X6TvZ6SkoiB2FcDxDUDp
pYcX51kAFzqnIgvg/g2g6jCAN1kQ9RhAzU8z4sfxtb8AzHkBINIBMDdZkNg1gAYWBX3ReON+iV/7
X/7LAgxmXFrsYKAawZgnPDywGGYbkq1EtuO9p3xWmwp+jEYMRtTnAswDvPnNfie5KLW4qxuWLgNY
3rdi5SpYs/bxddj+xIO/+5EUFg7g0w0S/lURqqAB2qETUtANPdAHq2EzbIWd8AyMTk/juCp47L7+
ldAPWzAfjdD+6ct//dG9/3fF8MARJvw1RB/rBNB1FnWnrvOo1dEVZouwpQ6W6jqD/21M1w3Y/rqu
s6h/pus86jfbu7qTvT3h1VuHM7t7M3tW7hju3z6nY8fQpofvQEd1oZuS0IuuCqMrt8IwZGA32hnY
g67bgXY/bMfQ6UB9CDZhWwYG0dlD2D7yD95/FG9onv4BngUjrEX/MRg5pRgPwL2BEaLtMhbIAeDA
xKJGrXs1bGZK8PU/yp+Xtw0LJDDGRk04EZw3VjOn9VVGs+/td+WN1pY74DRpo49cbkjR+qO9X++d
/iqfMsnGajTpumsz/w6Dw0/gCmVuZHN0cmVhbQ1lbmRvYmoNMzcgMCBvYmoNPDwgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgL0xlbmd0aCAxMzc3NSAvTGVuZ3RoMSAxOTE0NCA+PiANc3RyZWFtDQpIiVxV
CVSU1xX+7n3/PwO44YKgYBwcGCKLC4pRUECZQXALxtiiiJlRFFwQVGoUTU80xFIlOWJFJXWp8VjJ
0cShsUotSdC41JaoqFHq0bhXs4BEE7Upzt/LxJOazj1vzv3fu+8u310eCEAHvA6FjBcn9Y91rf/l
a8CYZNmdMDPfVWgbuXoWkLoZoC0zlxRZHvc545Szy4C5eHZhbv7RgR/UAT6ZgD4id/6y2Vt7P6oG
epYBkRPyZrly9lesiRR96+TOkDzZ6DhUPy8GRR/C8vKLlm5sse2S71pAFc4vmOmKV7EhgF3006F8
19JCfSjuyH2LyFsWuPJnNdQ1KSDtZTk/WViwuMj4Tk6QNrjtvHDRrMJLHdc3Ap2jAV+n/rZ4NQ69
ZYWoDQgGjOuybsm66xljtOrzYPXMNa6prnK79en68ReOB2TBK5iMrxCLIpwWbiz2URJ88T35wCaI
BdLLYHRHDc4hAy2wGh/jCh4hzvgSnfkA0vEepVMm+iEBq+WOFUkYhnhMwE3RM4L8RNdC8vEYGIdV
2IITaESAnOeriXojnhfarteI5hzZvURZtMI4YjRKvJWGgV6IwT8phIq0VNG3CGLZ988YKj7mYysF
SazDMQ1zUIwqHKc+xn3J8Wrc5Cj9JQzAaJTjO420k8Y+47DxOaLFwwQkyu15qMQu1FAdh6oUowwj
Ze8VvIM/4mPyo8vqObXOyBV0BiIbC3AAdTiDc3KSQbVcxMv5osQ0BGkS0TQUoAS/Q4XcrcJeuHEQ
tagjjYbQC+SgDerAk5WeJJjRQ2JOQJbgeAzX8Zi6UwRF02AaLehlU61q0or0WD3RgLEJPugkmvNR
KIj9FmuxG4fxUO70pWJjkVH6NHeJmCIyCwWXlUK1kpUvqBsFiJdb6AL/WtO0EGM5LJKNVPF0PKYi
D/NF+nW8gZ04hQbcQBOZqTfZKInm0jU1Xe1Uu1W93qi3eBqNpcYHxnXjjngeJghNRqbYWiX4lmKd
xPlXHMFRwaVJauGxWA0SPdE0nVbQZnqX6uks/cBRnM+nha6qQapc3dT2aK2aRy/V75g+8TQYYyQK
ko7UECgWhouHv5Coc/GqIOkWnD7FcfwNX+JrfC8W/Ki9IBYnNEy8TafxtEksnaBmHsEZnCmWCngD
f6igeqpI5VIb1Q5tkJasLdMuaXe1/+jL9TJ9j9nlcXoqBeOuRn9jtNGEIMlxkqAzT6p/KVZILjdg
k1g/IHlsxCVB6BZuiwfNuCcZ+IFM4kVnoW6UQImS3zY/siiHCqiEyulD+gs10HW6TfdYZxP34SGc
wIk8kp28hN8R2spHuVl1VREqSi1WZeqQOqLOap20N/UAyX6snq679ApTpanKHGFOM8/w8fepfxL5
5AuP1WP35Ho2evYaYcZIY5rhMrYZO42D0ivHjL8bV4wWb00oqRx/iSlEujBKOiBRMj8WL2G60ALp
kuWS+TexRvpiPTYLyvskznqphNM4K/PnW9yXCIl8qB11kZqIEOrnreOh3miTJdK5VEhFtIxWSbyl
9Batp9/TH7y0h2qoluok85foMl2ja0zsz924F/flAUIpnMpzuJhLuIJ38n4+zEekMq7wdf6GW5S/
ilcOVaoq1fvqI3Vefa5uqq/UA80mtEBr0K7pXfWx+hJ9p35QP6I/NiWYskw1prtmk7mnOcycYX7P
fN5s+ETgIdkkjqt45qdKeB8/oBrWqVgrF9pG27Vw778sLsZE2ssu1UMlcIhKoGYq5aXsR83yvV3q
MoxdtE3qeiHslM4lqHy6wqUnHLxZtJ7kdM1OpZq9zRoP0M9pASqbVsJKCxCnnUSWvlErRzjP4Ct0
Rhus/MTWc+qwtk2/q6bJjVXGPa2DOsW+UlsPeZJ6l6/yGfjhgnQbEEu+0k/76FXWuJi28deC+Dc8
Qdm0LNWsPtVsOKhmSBW/iAijmcKwUeXiovoVlyubsrX5SBdRxAbv4u68nYql4UJk2h6kKMrDvzGQ
qigeVVQvL0E4M0KxmE6YFAfTKNKlksNUHC+iMi2FbvMq6sQewWUMH5PMTuBI3kWnZW5W82z1J5VJ
AXibsnkXGjw3yC01NFVVyIR6ZH5DBWOtlo0dZJdneAP2ez5Rx3FXnaLF6l/Uj/toFTKjrIJ9jWSr
RepsktpPVXqzKYiO4zV8hga1Qur2I9S3jm6tRgnvbv2HlsOHKFdFoZCGyBiJRZ5qT5MR7CkwjnM6
DeRvPcs8+1vvG6PU+60dW10qUuZJOXbIdBkHpunS6aulS7IxViZLDVYbx6QfFslsmyIvUiXFyWs0
QuZRsUyeCzLtzTKRb8icqqW5aOIiZLVZBZKTk5MSRwxPiB829IW4wYNiBw7o3y8mOiqy7/MRtvAw
a59QS+/neoUE9+wRFNg9oFvXLp39O3Xs0L6dn6+P2aRrignRDmuq0+K2Od2azZqWFtP2bXXJhuuZ
DafbIlupP5dxW5xeMcvPJZNFcvb/SSb/KJn8kyT5W4ZjeEy0xWG1uD+zWy01NHVipvBv2a1TLO4m
Lz/ey6/z8h2EDw2VCxZHUJ7d4ianxeFOXZK3xuG0i7rqdn4p1pRZfjHRqPZrJ2w74dyB1sJqCkwk
L8OBjvhqhk8Hccrd02p3uHtY7W0euFW4w5XjzpiY6bAHh4ZOiYl2U8pM6ww3rKPcnaK8IkjxmnGb
UtxmrxnLnLZosNZSHV23pqzGHzOcUe1zrDmuaZlu5ZrSZqNzlNi1uwOLbwX971OUd0nJ/M2zp/9l
vNqDorrO+DnnXvZe1CurIKLInr1Z8AWIYeWdhAWBxKy3IL7AdOL6wEeqwUfihPEPtEZTV4iZZppO
Y0dNTJMMNOPlqngpBrS2I7bZmplOO00N1WnsX401Nup02tTb37m7EGg7nS78vu9833e+x/nO2bv3
ZErR2oytfiFGo6/4zZPLmsZadUGbmxEDviynLhKtQ+oO0cSMAhQiyhdLiS+qJVArNJHn/GZyoDqw
JfpcBPsxM2qSxjbdmjkz1OfcJDNr/dEVTQHdrMwMNK+rmdWTRqKNbWdmhPwzxlvy83q8U+Ld7Jmc
khhM0sYOWkZt7sidLkbhxtF2UlFRYAlOgenf4EclTQEspFSQllIS3VCKafg0U3iZG7ENW83kxZGo
txx6r/A3k3K8AX/0PsG2B25/Pl6zLqHx5HjvEzEUh2P0fME+MjZzc83588W5UBZjI1HjE65clJ+3
x2Y3Aju8fjC0jzQ0wa25vAA913Wxq0fsEFkPwdy3rCku+8n6TIuECnKbTRYRlosjlmkrhWXfiGXU
PRLA8T1LxEVgmqnOHv1P8aan1m4pN2n6/zC3xO3h5YHwsjVN/tpoJNHb8IpxUtxeOmpLjMzUxU1S
JkuMWKbkWnESvzk6WQhNk0w5B/8e9yRvtBUVR9HVUH+d6Y08FafNE3T9/3SynS+El8u+dkuUaZbn
jpcrxsnjypsUlVCwPJuFV6yJRieMs9XhsRON1gX8ddFIdJ3t7Fsf8HsD0T7pgnQhuqM2MrKjtvOT
I5lmXUczFrGFlucT9/2PKPrDWrJaJQ9PPTympuLtRRn7600+9ZTRWe4vawJSFtkp76TLZEIagHpP
Fxn2lJFnGd4LWRfZzLqcGdA/kI+SBkbwa9BFNPA/sTJnDfQ7gYWACoh52cA3gL3AXWApsBo+jQAV
MUZByDnP+87fklY5HcBHSavIoaQrTi/GNsYk6Qp51VPmDEhZji0T5wvoB+TPnAEly+nHvAHYt0O+
LDhsg/Ju59fyZ+QU5Ivw/1LJIl9B/zJ0wm8I6/g5KyMnwbOQ/2PEXIqa7qGOuUCq1EmKweeB57Ou
hyLnG/JuMgM+81jZw17YJmHsQ2/SoJ8JuRBzPOBz0MMA6nRgnwNbHWKUoYYy2E9JnU4Itj+zq2Q1
vUxOsKtOFfLPSay70123WHNiTaL+RE3/AcQtBx4dC+TMHwvkT4/X9m/YTarHgZAeKUjOgm8HlqDW
WyxGNoL/TsbpSfo7eV5AJc4/WRf9LnrVp3Si3itkpbyR+DDvtvxDZx/TSQfbREzoZyMOB5LRj7ny
J25MB/JyYLJKyOnEmjvEOpVO0g6+AHPuIsfnmPNXAeQKALORoxC9q3H3j5DHkf8lQPT0Hs7tMYxn
YfwzxF2UiGuP4bY4N2OR6O0ILo7A7VsX+T7Qi7wN4BOBG+I8we8rsWdib1DDIlFLvCbnkrv3R8kQ
1r4XaAFaPYS0JYCeUsq66Z2zr3leU1gfGjVkPRoM2WzozKxgobcqkw2RCLADkEgK6GmAERP0pjta
C3rSHRWAVgL1bCj0noQvuRSKlVYUhgyQd/hZfpF/zG/xpAa+kb/AX+ayzNN4Nl/Ea3jSLX6Ps27e
z3/JpWux6zF2JHYsdjo2GJNjsZhx3WBHjGPGB8aHhmwY7XJ7Emtn7RJLkeg16YZ0R3Ik+ah0Qjot
DUpyvbRWapXaJfkEbgCDuG3IccM1SY4bjkoylwqkSqlekturaqRNeB61unStS+tdWunSApdyl6a4
1HHpHUEBHS0ZFp6gJ4AbgIRGDKMRw6TVlfBdgv4qGpQCyoFKYC0g4yY0zK7ibwgtS6PYC5JM8bpE
pk/HM2/qFDVUNYUdosdxW9Xo4y5NF5S14k6nsemC0hfOH9C+PKDtOaBVaawIlxeNZbhUEpSuc2lq
aHq29m629r1s7dvZWmu29ky2VpetPZItnJYQH6ZPFpRecukpl74UyvJpD3zaXZ/2R5827NN+5dNe
9Gk7fFqLT2v0af0sjZRg3snQxBLtHyVafomWVaLZbNrZlJoUktzPppEaBH7MMrK4zcotg4OVWMZ8
foEVEgMvwpwtsPjrvCqZ5RFOcyDngq8Cn+/qNTaXhkgbZE63u3ofCcrCL8sK3kK0TCtYBZZu6fnc
ppctwwc2aBmvgw1YRoxfoP3xTPS8xTcjIu1FxMOQLTxJhb6HFNM3wU2ruB9ep63ibhREP6DbyWao
fwy+C/xdS8+D+UeWXgT2jqVXgL1t6c8ixVukyE2xVyS+QNuI4UbeIwqomkZfjK+N7kbmbeA7Ehlb
wYX+W/E10a1WcL9IjXPl6jeQCpc/aRmPiMoXYyzmVZAg6wYvJ0FXLrOCi1BMsaUvQPYg0d1ohVZF
N0SOpPshzoi3aLqlPwk2xSqKgamW0QbmsXg3WJJVvAuMnMeU+/iq3uujIZWGUvmdYB7/C4Lf1pfy
m1jTDcOm1OKfYnLOOX6dx/jv3am9/JPiw/y3uk1XWfw3FS6LGS77yOgXtZJf0JB1nF/tE9tp8StB
Gwkm8p8GK/ilYCkfgGuOxfsr+lUx+Qzdjsnv2TR0fhs/pcf420U2fTOUwt/C0n6A1ncU3cKTxJaR
eb9eytuFey/fG1zK28TMXr7TmMOfRyEUTpuMp/kG/TCPBBv5mop+sQWkCRl28dUoR6Xn+EqssT6e
bWnxcR4uQmSLL6mwmSjyqYoYr9Xn88WIlxNK59VGI69CN0LBw7yseBtfoC/kefC22ngu2iGKmotD
Oqdo0E21kq0mCu6VCn0ltED5g/K+clxZpTyhLFIWKvOU2UqO4lfS1KmqV52sTlInqKrqUWWVqURN
s52boTzx3pTm8Qomfs4pkd2xlwnK4q9VjKqMPE1OfMgO4UF9iAwCkpkqhVl4ebVZkhu2FafRLM0N
m0rDM009lL7aTMPmxQ0kvN5vPlgesOkEvAMmBaqpOTVMwiuqMzDZZN/BoVjRZFNHeBzMFLepPjys
yg52Zgr+2MHO5maK8PhR31OZUTn1iSlldTX/hUQSNPfrT0buuE8GomSZb4SXN5n/Ir7aYqO4zvA5
M7sze505Y4+9N8/uzuzVntrry3rt9W6zY2qzEMewXAQ4ZTFNDYllUDEYcWlIUEIwCmmhihT3AQRS
pYSWJLIboAtpaj9A01aqWqnqJW2jEAmpomKhTQ0Nxfb2n1m3PFSV+taxfS7/9/nM6Dv/5ZzvSUPT
7fqgIg0NTMc2BLduuUqdoI73912lJvVuaMtVHKZO9K/X7TjcNwS0VoOGd4O5T2efqNKewbt1Gjjd
MwbtSwYN0sgk0CA/TBo0ahsK6DSwb9NpsM1VXspYDvUsL2eZQimDl7JMGTwTrr5WQz39fTM9PQbL
fxNrxks1/03jpQ6dNJPJAKUjo1NmajJAmMnUGHDbY1iuwoUqXDDg9GO4swoXq3ARYPX/8uxY8T9T
+0c3rMADhS0zFrRiCO4vRl9P9jxh+JLw5hdf8V3DPvojZIcrnC20YtoeWoFyObdKsjgxMO3cqDtc
Zbpbl/HfY8YxzQCVhT99lYzsfsF3DU40F4xVHGB2LkPNvc29OgRxo0McmPllyP1CRoZ3X1iGCJgF
eLe7f7QPfvVuHzwT4Jf9fRMT+5cfpDcTMN+3T0fco4BVW4Ojqgj19/Xr/zqxH6kQGJR+yTTDD5wI
WDQ4Q+H3MY8YxFJ7v4/MphLmL9HIxuqDyxh5LIx5FnAK0bgPzgRBrCLQ4kF2MbuGzGcHF7MoB2Oy
AE1bqyzIQgQaSAloIUjPLWhm9AgFTXOQEo5XPjVfN4/BSeX8ZT5ocyTZUuU3mmR1JBv5Jk8K/0E2
9Vg+DFK84JT8gaDJ7MNUCf/4MpJlc6evVJm7IjUnfTQRSth0xXlUtJK8PtQakG1Qc2GXR6GoPMZE
zrciDb7XGzo861bXkAfjg2X18C+xO3H4tjsBHz0+eJvMl1FucT6bU8tZAl8u1LjSQk26rRUVcVFV
MR1qwSHFxDJ1Yn1He6qrg4Mp6kzWhDvaXWDpMl8fibHnjr66dHd48LuvH7g+0vr84g/uL/36Lp79
eOMRzdPeYR5bWjf9zp2/3Zh7+/Jz+6+9gRvv3cRTj8I1KXCZEuzAHvNTqBW/fRXJlc+0UQfJ1Sp2
Phc0B5kEm7AUzAVmmB22WEg7dimHzFQiloinUTrcHcvF88La2Nr40+Hh2HB8V2xX/IAyqXyo3EZ/
Nv1JuR1+wNbHVxIx6YkF4pQVWcPWGB838WyA/RpLsyUqpDmIRWIRQ5jtDM0YBmyWGM3jE+KFWKyE
uy4pUsHv19Wtk7dDVcBsgskxp5hzzCfMPYZhSnQbSE4wERAShICsiIomOnKyrKhNJXr0vcbGuK/X
QXUjCS57Z1Ec+aF1wTFVQq30zktxnlCkRO/UojiBP8H3MM3D6QA6LMUpySK3xRW5kaj5Jq3Gnmt6
twG+SKvx5k/7zvso31y77JLbbN1HIGGTLLhisXxrHqtl9bo+m4NYrUmPFxP6xpIyKZf1BoZL2Umu
Bauq+Qi5zmazqpvMF7NFnPAeJp+7E7eqLfiAt6WMyP0irnZtrbhYVIvje8ExdL8wnIEOpTqT0VgU
5uAguj+EwSh3AVZrIF0yHYrGwIVoZqrlyls9kW+HrL1JZWzNS0J9cOgibjnY+I1HBx07t0Urdant
dlN6c9jkazp5xowXP9t+ePEvnXLXSt62lM5KLk781utLr0UGX6ZHVzdFG9nI0jsjjVqm6kP0D8GH
3OiDS5yfT+NS5Xca9EFvwUvt8WLkzTBZMc/mxdV1T9YXvEe9Vk4v33leSOIgNBRDSxRfSyQei0jC
HOuUOLGWZUyYjzMsG6gVRVHf1dpakcIUz1lqPXGRFGpxravWY+u+Sg+h6hYU1arw2dyyxhxorOox
5UakjAH6jxZ0VdXi3nFd1C6ZVRi2KqWLfSwj9tmpN5xPD4c/9zWER2yLw/Yd26L/cHWbY5FI4cWF
M1sDYdFLRSKDL9EjhcZIE2jyo8pfmSOgSQhv1dbzeBOm+ghu4hNKIpRGWSpj7nGmhJQ/E8gq2dBq
U17I+wcVwmOrKYfpAHLZQgVF+W1gu9Vpk6xuv0dyWyhWsriEeslFYay7bAPnFJ26LBxGnBPOHAGe
iDzoQwIQMUBwCEQkOkEQiFKiz2q+UAhZLRZEuV0WUFHgwnEnRwTC5zn0PvUQCbAI0awah9dywxzF
laifXzofwRFY7ZzmTQg5Ya3wonBKMAs3wlbOJbg4IWzrPmNon4WKBo6My6T4oDiOPbfc5BYpA2DE
QnVPcnokQCw83ptJS4vbCAQYYDj46Lb/ulXLAaIa+RGiAY0Xrfhffs5ymMUhKzYSpb53XU/gLtyC
Y13U7/GFWT43aMfv2taPRZYuRxdvLj105tdYl1Za0+6mggcHOletspufWjhInU41tWfNkYh5/fOP
zpqOLXw9EUn1RiI28uVN9EcZBe4euPKryqemi1A/kuiGtjLpyEUpe9Qe80XpL5iC9c3R5nhjYlVi
Vce26Fh0NHHceZz7ScLJ1MRQBCuBeDzakUSdOOv7afRnMbtX8lUkqaGhRM1qbt9DBNVjQUxKqEJJ
OfwLTEEygs0GMIAeti1E5ZjTQUtsZzMtd4q+ujrRGj5GvCnbsaYS1fhe5wd/1wtiGSrNIFQVQ+pc
WXCla9J35stFTIplqDbkTnEe1IShLiIqFot4OUcounYuP64T9SIThjkbqu3wU5BqQGMUi3YmU9Wq
k+oyXRyX7Q1NJ9et2b9u6tCGiY9f27T0SFVS8dihqHPjmZGvvjKwdL8jcndu8zc3KFJLAIpQclfv
tp0HBp48dXrfm1/ZXdrRUeenzCdmx17eMvAqtjw3uHnqjzGXJ6If2r8DVekkRI8Hd2jpGrulh8ox
PZaeutWW1XWbrc/an+UP2Ca4SftbmCOiIBHeykm8xWoNiHVine7xovhPwqs9ton7jt/vzo87v+58
Odvns8+PnO2cc37ldbYTJz7yToAlQHglGAKMBdLRLVDaLdu6DJXCmqHBEGWISnQqlD1aXmHMoA2i
Slv/2KayIvZHpU0gZV23LtKoov4znOz3sxOK9s9k3+93d777yfp8f9/Pw4G7i3hGa8dIxx0MZ2iS
E2QHxxA9+GU2D2bBPbAEdAGQAjvAFLgL9N8F58u8j13me9xa2psfdYMp9wk3XGZp9oYgNrqp23gM
4/DGmwLFuTjBVATCtXMV3oGog/mkMnEAsv9CEpI0gH5OowH6KwBJB0Arwg7ZujCvMCscVTYrX2gB
/z+0VECL3MLIpc9mzGweBp5PZqz28qw5oEibeSjSpMpkHfCgOZppW/aVW0FwWRfKzbBMZAD2hwR6
dR1jIXzy5OKH7rYdVGmHZWx7DUi88eHmGv2axVOic+9B8gmxMRqJIzZ7lSjpXz6F6jG79MjwDViP
JIhqIxRnCFKKGtRFDQlLlI2KSrQFa+YyfDqYi63Bum39XHewT9mGbeGG+RFlnH+JPcoe449FzvFv
s7/g32c/rhKBAReBWxRENxZNihjPukQeMj1irWo5ykURcLIcFX0+v53l2AqJsW6eBzDXwUg2pllM
lGxPyVGZtTNGxE/2pPxD+bx8Rf5A1iflEzIu3yZSmA+Pae4P7CBv1+yD9lG7zn4wRcmQuuDLpmtP
laPMXoi3SnB4lrXmK5z1DGPZ/j9RldkJBI0G+CFwnVSdwJsanyryisaU+6iiMDURSfcu+D01oHRV
3xhafPjXl2eHU/I7ruxeM37BsmtMeld55cWvnqlvb7xGx/w79WvChkDDodKPFv/y997hI/GeaXz9
YE2k1hgOD02WLp8eXj850LPjGj7WJLUFXbB+T5Yekbpy/dbBfoqKcV8yklTUUDrZR/eL/b4BpT8x
XLXVscW5xTUijgS3hQrhEWUk5iAei8YRybpHJA9Xs0XwlsaJzhHJs0d0Ha6OfF2pESP+x2K4CKo0
SoJ6ZFP8oljEH87Q5fnRTZpOMLTNhupqSya4ZDKRoONeG4OBIqi7YVWsHgZ5O5szEnY5SSMeiycx
CrqsOxqdjIP4ZY+fHcwzQ9Ck3cH/iFkxG/gmzAxWWFQbMQgu+6G/HoTp4UbqNngPzKA8sFBYmEM+
6/PC3PxCAdFgLoeOXA6GBDh8DNUjC+zZrO5oQoFFxOAllCp7A0BDA4kzOUxBVSyhXlppQ42Lmeym
fBINMRNNwTM4lLtN/7SuiDAJkH62zEB9eok2A5CqADBv09W10XjI7FE7jE3grEnX1GrCZXNfN9kI
XtvD2+OaCYxTdYF475O3WrpKe/y6Yw3BpnoiHO7ZWRrEk9+T+brGlSvfdH017wrD0lNuafd/dhGn
nuyHmUNemiMeEOexMJYGLm0EV0Eu1JJYHbop6ag0qMUUs2xRQrWRVqw1nI+0pfux1eBLkX3mfZZj
jmPqj8OnG8+qP/f9zO9QIyGHLsyGgm6LUUebLPevmoH5AqbTKWyYY9lwuEhcu4kZanuDxvoi0aWx
bjdt1uAzlzTazGbkMBP+DZjAdOA6FsDYpdlfVmWvsIAt4v2a00slY2zKC/7tBV4pw7rYjEnaW2FU
mI4KE2X+8y7NzvjovBflLjecNTqLYIdRCj6iCPNzFc/H54XJfxT4ZEX08nOwT8usCnhoyxUWBhaU
qwDygqioExhsdmI5VsEudCHJgwKXB7BO5TM2DcXO6UobUXdWGw34yqMq8eA9jrBTjjCdlXp+Usjm
AvwLz7V1b1v/zg8O7sl0MqENbtbvD3ackxzxRHvTduJkaWwdbbSwAesAe/illnjN+Lr3N6TO7DgO
9n9t26pN37q6LuT2tS0eea0p2dj/3K8R4zbD+k3B+snY65qw0QJpT8/7qgQnU1Vl1WPYJf2or8Nq
jBRBRrPrzdh9oJmtjeDTASdwNjMQqhmZy6NZY+D988wV5i5DMEKtFKPQTRv89S41S+GUOyqN82W0
gbIWOYeCgk4KC8o8Ir956LlgVoXIJSF0WQwey+4r7CoDlQCVLOp0cBXY0hU6ewqYSuh9O7d/59Xh
6fbrIHR84sCmpkSrGqa5wFD/rr3jfdrpx54X1N61030XQOutL/d3bM9FVdnrYM1M5/Div76961A7
BvdzHcTj+xAPL0Tkn1ou5x/xb5b/LOvMViNnDhAGP4gYJVKiGsgGqp8x4CROsSRL6SjSIlbj4gMs
BaniHqQKS7iI3/iVVmUkyUujeoSfw2Im71MIP+pTSzWozrJTEEUEEwXvOcdr8RiNEA1yeTRrNAKP
Bg9pQEsr6E2gUFbGT1mWbSeCGb7iRNrlRB4ALXkdvqtUtu9EBWK4a/lkXphnszAprmBcl4K+bALA
VVd0YmV/LmON3K6hpo2A3IKgBp3U5r7u4wXfwY9euTR1F/S9PbSptvnq/r4DW3YWOv18Kvc8eGlV
7erhzo2e6Rff3HcB9P5usLWva/tBH1drje8+0+4NdEzCfbdYXOzW0dDbZkCztmG2GZAe0S8GarAa
dXXAEEqHMoHmDGghWviMpwd0pbsyWzxD6aHM7swR4xR51HYWO+v5qedeswNvYptwDCYV1W4jRa+H
twmRBi0WK+J/00xqRsXSTBpPp4uAn1FHof8FPPS/Knxc8HAeBJkgeKIX6zskLAN/3Ku5xbSqigbM
DAKQWy5yHXpayMoegcHgqzeB57pAZqHMaDOCehGmozWaOy8MCPi0cEJ4U7gr6AR3VnAJWVP/hmf4
ZW0JxZTP52FSmVuxZaW5wkRZ80vQoM194c7AJPMJnxTKY4HNTjKfwav5Sj/Ar9HG5PS5svBD90eY
QKUb1EpnOFzL1JGuktJOFUaTZzpGXS6iscGI84fWv/GnoxsH29V4yqc3kD5Hk8A2/GE6uLoz8vzC
66ObmxW5MUhbWtq+0nZSImyL9Yu3Fj86vioWzSWkgF9v1FclOxK/JfyHwH8ZL/vYJu4zjt/PZ8f2
3dl3ds6+c+L381vu7DiJ33J+vQRsJ2EkjkMCDCLGS6EUdW06OiiU8NJudEVbo20FSlUtnTIiUk1E
6VbS0j86CW2VulaVgtRNqjY6oWoSoKka7VoKzn53DiEZ/+wPn3+/k/3P83yf7/fzhEofzPZl4rkO
ztaJ4cbep+89jaCLp2F/vXCO4shapApMsk5vSnlcHKRJUSQyLSr9ADaocm9IWqe01zao4YxbrVqz
1W3VFLl1BJ/TF6kggmq69ZlCbiCnyuW4dlTujweMJ9a0azl8XcZOFisVwdJIWyyN/aINPK66UbAB
m9ziYHdaIzdXI88DqXFp4EmzTaNxw8c1zaJGrWna8EQP6LkMsjAtKJCVnMF0ui34UvBiEA2Ou+fI
iCuickekiCqyf+jmP1kF2q5fH5UT/9Zov4Jw8iBehxSg7JkKqMFwuFUowI1H9rFRZcrEpUkTVyyT
QEAESG2ctb4ABYINcj4wVqa+FMFuKStQKlD/kq1PbiRj1XrhPNbjIQ9fBsDSTYn+AMoCzP2ie+cf
fuhaF+42EWRT7M9dm7d8/sW/fzD0+Js5i2Pf+I6Nez/80XC3d6rdmxwU+RanuCFZO7at+JPTR57c
8/O16I7vZxJbzm3V67y0kTQbGDzc7N9fPXK5kq7kHg157YGWNbs7goerG1/b0YjR7vbP97SL9tQX
O8LJu4/6Rzq69m7JJdf6zTBXLIu31So43wnwPemDpCfPV9073c+oX9A1aD1ghB8WKikUYXEPxfrY
oC3kEZFMtBArxNchve4yXwz3Rb6r3+vdxx3yHPS+gJ/yHIsdi7+Kn3W/6nklMhGbiF9ApsGMZ8Z7
IfJ66pJxNjYbv5YKaYHeo4sYom2p88hsStsaCYejvCAgMNUEkxFjm9mFWQYwU8Y4H4vtj+qNxqST
ozlZKU4nJyBIMhqmo/I1Gg3HFuLjiQSCBGIN2rCAMQVGYlSMrC6jqRl3JkOcMxqmjNPOd1CIOWBO
MkQ/C9uSTibMhJPYrrfRXmRpaYMesB5C4jLuI4VD1DWIEHA1k7H/9q2TGnn6V0M/9IE7bPQ6VNot
iI4C5AoZK8ST9d2AunIFqmls9CkoJz1YHvT7vK9YwH0rry8E8uTjgANKbGpTftVrtbsnc1uey8Z6
2aMmo54g3D49HRw5V8yX2GcJE+4rnDix+WvQQ9NNSS1Yr9l39/CfSo+U10vJwdpIZ6OexGwpo936
s8ektvAgmAnTuCl7uPZN7RP1Yz0um7ERDWVgnkYWr6t2Qh3gME+v/o7ATKJhfvErKUGZ8ijTyHBM
gS+7DriO8meJGWLSOslc5N9y3XEaGTNptWHopxN6oNeTdmZhQs5KVJLaySAfCOyH3kQIHjvtkbvl
8dgbPkUgsF2EykMCC8HxkBVmoXXCOmlVW+dVgmSxQQ7V2ltCHqoCIZCxtywT4Fid62Az6lx3+1Zh
VFhqyf80oj7WgkmhPAXZBQGsMNjGB+VnVKtrn/KDj/PDI7nsyPDhD01mzGSKFLxnZrrWm07RAQ9p
MYAhzb6RXG5E/tTi98RcI95I+rfTtW96O/0i+FuRs3pBKCUzmwfW9BSsqQP5UlqLSCZ74W0T0DMA
wfVWCqcIP+4l0pDH00yuOWcvuPqQHlCmey0HLEddbyDTlouud5C3VJdQFsXwBhJfwGTaYMxsHJNI
uoBJBF2QsAlsEpvF1Jhc8zJq55ub9zMoggiMmWbkmjOMuXnBPu5wIAgG/7P0ew02DWncGWIodBqr
QP52huQnY3Y+qHe/QH08Br1zqe5K1VeMweqawxeCPABwApZwGgh68KDM9yk69UDYp2q/d5gwM9WW
CW7bWih397PAaLXYRRwMavZ9e26XzWA2BkfNZ7vC5Q5/FT33HRtrpNFABlaWWfxS8xFMrQp4X/qt
OV88RKo2Rza2bs4Ol/5V1ZDVv1dViI/yBXwBf4pNplI9ZbbkK3WWiuWeTZbR/tGBA8TB7Enx5NqX
qi/rXqbPZM5lJ6pTugvEefpC5EL2ku1O9uuSp1gqIQRAyj5HExfEiJQ+DZCSb0HNgSvcVU7FTVma
mpJ8tO5EPB/Vp9NCJk/n5Wsmk0dKJaHcR/fJ13K5r39hYLwSuwx7Y0a6UERqMTdUGhBtuVTKZNJY
iCtwEjfBTXKznIabDuL8YCjK5zN9Zao6j/ZKeNO0mgfv8Vd5FT+P8pI+Pa3OgPcyICPfrKXp8gDf
f6Nvrmwb5JkMU2b4wVXeppjbbTkEIefIn3t3FZujVjRXUDgnW0Cy8Ckn6ErHWza8ld4Hd6mxJeYR
l8ZNPirmp8jgKUTBX8kQgY6Sc5rEPpoSy/OLN+cokZ1f/MscacoLCgADdNkdSSDbYvL/cEojSgJu
2Ta1qHJuBRxUF3fseGbjmNiVbo6cEDd1RWKJsvMJm0GH63whvdlb/E0p12cbY4xag6Fx4JeiPXfv
MmnQ+iuHdg0uvmunfDEMDKO/qlX/WHwk3x9t3/b6+927fU1lUdpdOzXE6oxaRydhsx4/uCYibAQ/
HqS1hgZsw18Pbf9I9dMErSW2n16ofaZ6bluIYgxQslCzVpi0qExaIC+dMedanlGrNrmH+EoSxd14
uC35ZFLtZ1NEmSi1bO3YGtujO617JXxeNxO+ZLyWNKhZmlW18DwSCQtCq5FpwkALaEF4doGZkvPR
4aW9stAcDi8P87FVoFvla2ur4I81NCAdC7HxeBzRCnw9ICeYSUbNTDfhjkTI62gVYD5ecQCHrCWz
EOM7brTOCbaEgxEYR+KhjJRldHt0ZUzWrUExB/hyVU6y962C/UpWiiwRWSmKRJSAXGJkZGlPIhb/
8SYUhQtqRCLhwQNFE3FSYthJig8pZbU6Gh6O0Qd6cD17JL/l+XS8jz1GkToM52CKBn7xaxiiRwxm
IpB88Xh18XIz5euA9gP7PvRucVfP+nxnpTbcacIonSNhtDP/kdr4IfAGDyM0/nzt29onqhP/pbrq
Y5s47/C97118/srd+Rz77uw7++KLY2Mn8XdiO058CoQAUUjWFkhDDVk3QqBVga0VUFiafqxUZesy
oYK2ag3rBhHsD2gg1Es7gVrUIXXaKrmapv1R+pFOTCjSPjI0iSXZ+/oSmsqSf9ab11L8e+752h12
VAGGRBI10vcRvixKqu/o9WlnuwyHA+OBs4EbgY8DNVw7QYvtZpsvz1N6MpOmcIVkuerUfahYTlLX
KUiNBlx53qanMulJ23UbtGn1WI9xO4ni/czYcFK2rdTP6gwbc1rjV5skjr3oU/U+he9TK/eplfvU
N++j1lmcr8IAkjjYQqq6yE4ooCXC1RzLo63CX/af7JlZ+svpV14/8JtPt2a0jZezjSFf0/hDSXJy
8wv9by299+5bz5z898yhjL+4lJhtKYgN90FsLJ0jCLhsWtpCfoQ2pCEONFx1oxyg4R8/yOZ6SbDR
ud253T0gHJZP1J120mRDmuMgyTWkHQ6YTjWQVDyUbuBICjqEiNt91yFGJOmWTEQ07a4CHY5WWalT
8BMvy4pWIcYAgPEy2X3VZII0Vyan9dbQ+lqbVBHdFVFg5ExYkbnmJgv+hgWvaNICVEvcoluGLQct
k5ZLlusWs2W0Fc6CdwmF3DSTQVkkg0x209ujDwqjsWmjYKzWRaybxcWvEBUwExbmv1EY/4u8cu27
gxdw6RAQG7hCofCDm3R1Yiiwf0adwRRtPOlc1T5DuH+4BboewdG28mg7fehCJ7kqgcdBb6F538td
u0Z+f/njYDqWlpu+ZVn8m1XfFlzwcmp2yhdX1Y6hh5NtIc3f3EHuzf5qeP1P9y19/ulNRrz6eEoN
1gaDcOvz5OZdIYdgXQwl6rX95yvDfRt5Tw9SMY0gyCzCsB7k9W4+bAWqP64NkjukUXKkbsQ9Ih0h
D7vK8APig/pat4ASveDxyqRECEKrKNVJeN+iKNXTBO23x+xFO2kvk1G9hcvX+Cus6lcnVFJVCbG+
hhatksjxk2aw23zdfNu8bKbMnxNgzEJMo3A/rdeJaiTu1/3Qf1c6J0oBUfhuB0ZmYW6hNMctzkXn
ADeHwMHuU2fWm4WiWXeq6I3BnxR/1XYeRbARxWLBCIzc/HypWHwgXsAh5BxIr04whpcZ+kQs37nS
KBSJMpqIQkSVxpIxGcGYtpVz9GPxvObMeXWWM4zOUDB+1d4QrAhE7GT012IFvjozu6utI5KO+YLh
MGex2tw9o/n0v87xzvq0BbSQk4t/BG/sznZkv90V2VJrspf+euYTeGaL6PUxShcBlu+j5HkPoZQC
Jv1Vk81Uaw2bolQMRqhGeyRRoNqDhUQv1Zt4jHos8QT1ROI4dTzxeuJcYibxn4TzRgZIjRrZyDU1
5ZvimS1NU4Q5FLTaKdWbAImaZrfKh8wRO6NJvFcmZE5WZVJuBhDyqZr2Zlpdz9tSiIEs9MMYJGEF
jGk5julnIFMGf9CbIlLFMyZXCC/nhd675hwb+VMEspFl/OaPxCN65Do6uR2hI1J6ljwPmghD/w59
rw/lFlTPuMXS/P/mSwuGbhUQdAVHrhRDZgSMKEIYo4Tww8AhazkESA2vuUofLHE4SIQQY0xo6ykf
TCWxZ4TQC7WDVFLAigfvNQXNL/a2FDzNb24YmNye35aVJdkRTKhax0isbVNs2zNBzy9e6xxq9oZE
5BgfHXm1tVHNxi+Ob+7/8TaBY0XQd3RvR3c8Nlh6rjupPznhttUjBkUQNs9TpwgF7P0tUbP8xbQz
V1Ne/kI/webWeVo9UIUqGWBUNsA1yA1KHMbJNk6HOrmBXc/1S/2eLmUHMSjulHZ6digjxB64hzwg
HfAMyyPK0/Bp8ph0zPOc/yX4EvlD9qR00jMBJ8gzNT/3XCQvSdfgNfJD4ib5oVIhKsqX8EuyFVA0
TbBWhvcSHklUCJcklYGos+IwOcACtqKfYs5i4FC58NHDNOoVoqtONFjsKjI6M4H+TjFTvDQLRgkS
jE4DhSiDLp0DvA3Ff19YdHHULXrKhfnA+4pofnaltS2Np876EmnXrM/iElxf944odw95VxQgCq9o
apFbQHKK6Fla0zw8IrdU8iyWkp5nuTtizIDcwD53AuvtzQcyCsgUra2pfA9SpIZ1FG4deFF7forj
bQ6+pUPrPj+wodfz5it145ePU6eW/vH9xfda5Vono+1wHznYncnvhMqW2NiPcKLrWp6j1CrLjugv
810CeAQ8aocB0MBoYiCas6UzPaCHGbIOqfut+9Vj1mPqz4g3rKeZC8RF63nmQmhWfif6Z+YT7u+2
OdYbzwCblRAVKydSopMTPKSdVgmPVfX5bZRdwTmPS0YSuxMHEjAxFq3luFbFXmc3Mp8dN75ouC5a
Xv6n7nPXFqMiOkcnKOzhqEeiqJeoJMdSKQLp7du6UEugvErfCgY9trCSDtuVaJjjpqr5DzXC8Gxa
EcKCEk5btTtVVKqwIO6tZj7sdMjoitxc1eWe5XACNNBZWxJWfa9ULYnz2OqiBlJGWajqamkl+82o
IvrPA4gLV5x1nVy5Sg2AciCKSZ0RfIwmg49XSwNWUgSrYODqbFuDsZEFi8BEr+0MRhSU32dos62l
76mjOxdviKyZqW1oD5yc6uyREi+0Dx3LZvqkQzIXTFYbwOJgjLfUmB86fBskLYtPPmI3O+zKoHi/
mGp9+MLvur7TtbWQ2g4mHg+w1RwIljcsbSRfQ09FlvhMzwREELFExbwlL+Y8uZY+cWNoyDwk7hP3
hI6K4/nLedbCuprX0SIIZivEXR7Qwal1ZTCl+/2sRNtcbCgcQNJKUjUmUyIea6HopO4CriYWByc3
wrjIDrCwyP6EnWDPspfZG6yJRWS9SvcHQKAM7+lScyRJZH9NT7HJS0kYTx5IHkyOJ88ma5Jl8NSV
nLZfjOIMM38PwThXMuLMfAkDJVSrnEGq4vx8sbBQze98DquswS1n0C2gl/P/A7a+QWELLjuBlRob
OxMw1NkhUQArTsFq1JnVQKUuuwWjiSq/NLcoR3aXVqKEp4l5oHfXxlW5bR7aWpaBnoa2xkpAY+XM
2DgEOVVkdAVFmV2j9DTda7/9e9n7ws1O3U1d3sgrxNJ54/V/b082FCoKB5ib+zgA84RVrUPYHMba
TD0lYIYAAmsqwoMMBxkfQyBTLgwyR8MgCw/LFdYtrFvY1mJC9l72Xg5RIDzJuZNrJ/dennQQ5BXh
y+OP438vcFHgouASoSLhcJEkCBRVH9kQHHdMwBIWBEQYmEEsRikgZmMgCJgJK1Fj0ACSOiCmIYgw
M7dgsILLujC4MXh4enn7MDD4BwQGBTOEhoVHAMVjCBtMF8DC0AEkZRgEgF7lAfY1nRlcGTwZ/BhC
GcIZEhmSGTIZChhKGSr//weqQsgGQ2VTGXIYikCy/x/jgtBwxw2AQfz/I14VHAxpUFOYGeQZGKBs
FiBbHspmA7LsQDHLwgkUsWOIhbKZGPgYZkPZzEDxlVA2C5D9HMpmY7BjVHX08HTx8tcOycxNLfZL
LQ/Kz03M03HKz0nxLEnMyUymTJrBkcEDGGwuDF4M/gzaDCHAQM0FBl0xMCBTGcoZghjygfxEhjxg
InICsnMYUoCqS4AiOUCVyUD5VIZ0YCTkAEWKKDRrIHVDY+4OQx0DO0MgMA6YgKlODJg/GJi/A9MX
OIeyMDBOYGBl4GABskA8GM2QxiQE1A4H6EnEHggYHIAptJIDaBDDGXYJpl1Q+4BcDf3o1nh+m68M
khxg1Yvl9ywB0av7m7X/Lf7nyiHMLgHkcsLSKgAyAEFmCmVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9i
ag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTUgMCBSIA0vUmVzb3VyY2VzIDIgMCBSIA0vQ29u
dGVudHMgMyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYx
MiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIyIDAgUiAvVFQ0IDIzIDAgUiAvVFQ2IDI4IDAgUiAv
VFQ4IDMwIDAgUiAvVFQxMCAxMCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAzNCAwIFIgPj4g
DS9Db2xvclNwYWNlIDw8IC9DczYgMjYgMCBSID4+IA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgL0xl
bmd0aCA3MzM5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJzFdLj9vIEb7Pr+hT
QAJDmt1k84Fc4rWNwDksFmsle7B94FCtEbMUNSCpGY9/fb6qalIcjb12ggUcSCDZ7+p6fPXVT5ur
F5uNUVptdlc6iROjEvzkq8A/y+PSJBg+XL14NeaqGWWCGpv+6sXf32l1O14latPQ4+EqeBNu/k1b
ZrJlwrNpbhLnOinR2Ly+CiI/az54NStNbepnvfqDvfKskFmQNEnp/PfB8RDqLM4CFX7c/GO1/Vlg
HVuj/TpaE7z++hGFyXIviHsqbhJnWeq3CXYXO8SmsNlZNJ2xbvBFSnyAlK4f3XVo4ypQb/HSQR9G
Os6DJpZOpcL8y095fW30/+D5PRMX4+SisNTEJrP2rLHEzhrzCnt3Vx/UKzJtGRzDNLbBCZoqSW/Q
djC54eDCAl91GBmMjjI8uPHCD6KUnTlTUV7EeQXzftVItswSnFnFBe1K5jm4AYekkIBcrFe/opVB
Emlt/OgQajzrxoUlLPuj7fGnPcVoUF9lSn02FWIJeotYcbkoTlb8guubYE8GqqAx7+XUcH9l46iC
OxN+pjIUVXkSJQgtPiyaT4P2dZYWX7fVu1M7OTo2NcmfctfFlX+Yuvn97ZlilTTWpc1XAZQuAWTW
RvnGZZv4d9d1pwMirAr+Rk5fBfduaD+HOWx57OPeTd4y/kS2THW2jF4sk8m5Lzv3qe63Q1tfq3+9
RIBovpUxKWT80T79P3nEN/CP7WFjW5XlKgXYJT2+D/6bLT16+cxi46yak86bV6+jzc8Roo6yT6SL
mE4EkpZFdk5uxqem0sOfgd0SXao8i5PKlot8xTmKvcPomI2eiChv+7AIpoGQrwi2p2ZqQxAEDZ+4
EFHHRZUDXoHCSVnR/ryrzmfHSH3IbgANGUC1HemArTSO8moYE07SOACCS6RMaU0KC2o1+tXHYbpM
9URccluJmiKfRPzlUssMZXLNvm+bulP9cXJPs7eNc2PK9epnoqvJy0mS3yHJnIWr/Zeq7+7kawgN
6UkadbPHYjV56Z1scLyRZufkrsrP3oURBSJN8rrwu48UmsW8adc2QD+vQeUi2aQWRG27WL0lpUnc
wk2y0j4L2/Js/lTu2IJIpbD/HTQMo1NmpcTaS0NNZH5DEmhqQkJokofcPLaXsdqvoEv0IwAAcnfc
1fKz4X3l2+/APVu+CctQr6bIUvUhGEEJZPhDSFe1gZIZY0i6gY/s4EV2FnHwk9Vxd+kwBquSdIWe
JjuroxJ1nPr6FGqNRM+3K3E7BCPcj84sg8+QMIXgFUy9JWlyUhGNDDxS8+yenyP37HjUAWk15jyN
oTLOi2TFbb8QnXQNH4I9x+RO5KHLpv6yWnSvWXMUqrHaQP+lWCb13aSu3JunPvFek2y8l2gfZN5n
eJhAv4kBMWbtQ4uqmkV/JOQ0UDiQC487N5x9nXrI17VYjeJ5d/Izt/Kqhdj5OU5afoqkIG3iglz5
HKikm2ZRGAmAAKcT+Sz2013dtP0t4s8B3CzB2u74zjVwpwtKit2zBWtXnIPhg1Y9BQ14XJmtKH+y
5EHtdTGwCBYmaUGMLLNY2E6Nj+Pk/Nh4SYxzXNHYVbEi50Piy+PP1Uj0lCGZ2YEJHjK4GlRYBO30
+CFUzVE6D6TmeUYvL8yI1bs7adQ8gS3lfQD4nBfFJTEDbvJhu+NwEB8SKEsFyuBmzeONdDj216Ge
prr5Xbrgnns/6EVLRZo0mNr+JF+1RFenhnZ0qvXj2JeRZdmcJ827k8hGrwwaXXAkLzbQe6tapu3s
amnQDK6GpyBo6SwlmIM7B9dqPN3eunGCL9V48KK9LHJK1txLs267Gi4oipvFuAyeM3EynkWLBpAF
e3lTjUM6xf71eJI+tmYWuPHFdPTTO64+YKiBk8ut9LJCvG01656003WPXoPo2+0csvq9b8H2J+Sq
RnRn4sRW64yalIu4Pl8cJYDLRc7cy5kyCEbk7W5Uf+HcmXIZx68OdkNCQwS6+DYmkXft4B4g23it
dm2H7fBRz5u30b18tQxbgz/AZ7dZ0HV6W4xsRdA7eATZpyDdQJkjlFHBnm5qYsQE9MaDSvpJymA3
PciKwV2zj/gW1Zpkbly0hSqP927d3xwPkjFcmNCGixsWqf4KM7x5BNRaOpsKyzuCaUvBhzIokCfl
RiSzkTSScZaExva4kuNyayA7Qx0xcbZ3WFGudgGmVeLjR147Mc3f+5WsehkY/NwRWebstiT2ZSG2
IO5MG5pHzsE3DrEXUsTLEwIq3pSZjCYRZUDdONyVxNrywu2AF645jtIPXfuJ8trLar9oX/N7kLUP
vuVUx3NdKPWLtK5hz4I4QirMSnMl4t1b62pN+ZJicW+fbyeGl72gp3sUNyEiSGq7gQuQ9iSCHFwB
wcs5Sgvbvswiq8r11NPF6EalBDSRNkcXygCIL0MbiIUHpsRbkjunm/Jsp/ziZh8KdmczCQBEhhJm
1HX7uJRtxuhnZZukbr66zWYIZ+8YoOM+9ImZiGzXSvP2kkVRRtDFWolrzwbuu4Ehf4XJ5wQG5mrN
mvHkZ8Yzk26iO4RgFFIMba4npaUEZGEG+3K+qbnLTyM15sGlpMBm8tyzpMaccytD/JPkilsnxZOC
4BlWU24gdiPgWQvYDlPbnNagXA/XSqqdc81AuL6VjwWK1Xs9M5zM2nXKMgvFyryZPjJkUt4ktCJ/
sMKXCCYa390f5d0db+XjUXTlhZG+WtZMJJdllsWkmqSjpnpv5OPj9YU6oxTwBvqzBgeRdqmbZujF
DoKOYKP3Le1MOaHlbEnHBvcnenY94IM+bujRduAinDas5w98Qea5PAsORa9nTqXhbtUTjzyzMm+4
a1IAIaLrCdPz4EYyVQexdqeuU6fecX8v/c2JMT2d57lBhrfShAkn6Rh652lqHps0tStquKTOxLPU
h2MoSZKw93cxA0dZGdz64k0NhHiWqwYbyPfg+7akG5qs6lH9zOF+4vZvrvVRD3qaJvZ5WmSPB/cV
f/ekExQjtakIHPz8NBZgaV3ml9kL2V+yUSSJ67ibUAlVwYOgGbAyuuHxmlPNyPBmg0u2CyJgTLli
u8E/6fQ3m6vCxqjPbIkjjSpwCYV9cyjlanf102Ztcp6R4CdfOof6sRC8ICfrH7xnahG7J75jmRER
UAzCdkcxAYqHCwHBtZLCrAX8zQuobRlX2VlC870CmqQCIj+X8BJjAncTTYD5/oggflQg2Oqp1Yo4
LXT6rFR44wU0Ccy6CFjG5fdLWFaoQp5IyM6biQo75LyB/C8Lokt9oVC0+Vqm4O0sTpnGCAQvDgLm
e6VJkaxN/kwaUy75QnsmQpUdZ0kHXwQ68PNDGHLNSTBpMJIuI9As+oiP0oh8I2vSK+ZrQepUlys/
RIg998Pyy2LDayy5iKXoOyzEebYSLuOtqZO5ojO2WFd+wWzvco5Em5bVH3CWQP0yHFF3HJ5VqlUO
rIYaS5h1Wb2AtfaoJLhzGh1wkHiO+yS1D2GTk0rIUxxmFF8mtEy3KknHVjhcJRwOKMbUaRB9CzJs
nTTBn/oVRXWf5E0LhKHuhOdeZnYqjzRudRbmP6xXS2/bSBL+KzwtyIWlEUk9qGMWBhYGMkawMWYO
yRxoqmUxpkmFDxveX79ffVVNUVISzGEvEtlsNqurq77H6PEWiddbubqoQTAKkk4WBJNIoJvwv4Sm
VCMVJS/7zaOllxSbsNvzCQI9J5tsvt6s11OVMH468fbSPO1eyGIdjuZ1b+Miu9eiH/qysUdzfAzp
+KNsBx3oZqOQyxbnnHvBcEtvI+teDw5MWudQG6OLFTrNaxOw+H0t3ZujZ6DWE1HeicjNr9K8mtAA
PpG3benaoCtxiKvwqYYeO08ONEm8mtbqmJvY50YQDeYhQ25pHkQkUtt8CBisyCpRVd9k3gH20NVP
jLrZ06pRx6Sismy6VG9/yPsbtOdT3u5A6d1oZkjJEzqcnYtz0Vk0tUoI+0j8HIuS930EVPHX0HTs
lCuRmaTb6Z7jSVt0713vXmaVgx5bhmVfvuRygXVpF8+TB9uXnZmTMczYwgxEbGRCt4ko/vY56FuR
MyitfVkwi5/lzFeh5IZ+NKWHhIHoSo4xecsQ1iWarcMXL13StVcC08NqdkOFIq2fAuxAorcD6p18
WL55o26yxQm4ktayeast+0DbLVriwoL8QPEfB2NlsH94bDrXUe/Mg480Yw+R9OPvKiW+huIB1A88
qfgvI8mo/M8S2ThKg+fYc2KiXb5Uy7UJJWzcFQFnyg4j8SqRrtPUYA4JI5C7LmLzYFc7ud3zyV7X
4SJcnSvIAvxMY8alYIgNd6b7M69yCqvVuicS1k0vtufgNAuGwkgHtxvoOvbp4OODZUOD3CjkLhVw
lwq4O81RLVPom2bNXjFlcQkm12a1c+1rSW1ZcDFIR1FPt1jfjObnSCL5GgXqUNWQ7ixV8mKnjrXV
u0eTqzSs5mWjhEZXHgSMNpZo5VGulhYR87Mz/nb0VsxPHJ6iG0NbhbcWGo8wVmzP4IFk8KjdlsB3
xWn2Czr9Yt6D4I/tGETpQAeZXkvlsJKihdqFDb7BMnvL37sbwK4O5jZPQAOQSVi3obLKWzodmRfc
3kLBaM9YeJc9c8VuX8O7T/Qfs31FemuU3nZKbzVvnviLbMxiT3TvHDo6gWCyIzGYj/QXW5WCSsBI
SE/C4r8f+JbYDMarM3F+aICMgkoeVxzV6yf9jjSBNsQmHKbkelpBuDCR67wbWqeftg/Yi4Hxt965
zl1sBZ+Q3Sx/tBkL8dko/Uaq1ZKzYxfF3CPwkfl/+OeojIqTXJJ8S/9LDRZDJzGuWb1LVu+Gbcge
oFeVjH1J/0IJLk1RphMgnFD4SYmZkkVp9QcUS4GT3QKKCseLo8J9P8Co7FulPQTwBvy/QS4gSCQ5
MkV58lFBHYCRZWdC5Yr2vsEUhdD14o6WHjjOuTD39FfOpK7lknWNY4FL0YHaXoFj0QvUFnXPFVnG
OJVNNtFtmgSGtzQ9CiYJjm0kAsm9ulo0UgDuh54bbLNNW4p+U30ESb3abn/G8bZkm1uko/ETYN9f
ibt0Hq9x+oufn5GEUsJytHYM1HCK48WhdK8lQ6wp5554nNyJJgKVvoaznKLPejwTg97m8RtPhGfx
1gzVLnBV+UJJJywLlVOgETc4bnzMTppS/xdRg8FVQQ31rHXfB6dRaT61ynZaQoHezeQuDv0mAfZb
gBbA1mvKNXFF5tzYQcCoiH65hK6pSxCBRv0PlaaCH0WWhGypZRicS/5Cb2uzBnzP/IUOzYG/sq2H
gz4M7gn7g84RtNqKtrX3Uaxcrqk43BCilNyPvNJaiLewnemZnst8NlPLZsN2ycJyp/8OCguksJVc
ak+Awmqb0+kDor0MBLmfgmqx9/F9CdSPd9bGvJMeldb0XYrpc1+1ZhFnPmicR7pYLX3up84z/X84
z0mzWioesOG6LIBMH45s2hUsHjZ43lZTLxqP4cVjmS78agdW/V64IiFOJ1KXseSTPIEEsx6kJGPk
rOJ1kMu3JYf4NkrJnGem1LFWIsGdX5Z3UnOxf6TrlPwtuLJe67ccR9CHMwsin0yxEPSmfmV5wWJJ
TXRHp+HoMnqsez1slXAxinglDHLH0b1EE7MmSaqoaVggLqHJqJ197tHpmm8RK8KZ5k5/KLmv8QCA
WHfWx2Xfw9PlNcUbweVVMQD+K+eFt46u63XgsSq7g9vdcBdbiRj+EhFTYeGQk83qlz6mD5qiGCB/
//UuSw9dqQB1P6BrhVjoaQ6R5FoaNpN2FaoLG7Uv7Nq2wcxeT0VdYwqMMiFlUVxy7smPJiel66KN
uIMkpHhTfNtwT8izInd2aWxPKTXaKrT4IwHRoe4db2VV/LldkPcEb8R99/mTiNZzYgQOL9dTYkhW
/gNLLw5wTLWAAdbrAyp0yN+jjvBDqK5XwSROuaQ2gF68Tn4pB6Dmu7J38+DDbqdEWQq7Geur96iq
d1W4EyVQGP8PJgMikfW8ZOGYtjDvgpGiGc7oGM4H8Tr/DlKV2ylu5gvohb9hIe/VYgno++qgj2ro
tgr+ssDf6LbMpOmcZ73p+jMjqIM1lwXTSJE/UPlNTZbasuPJ2F160IrhzNY65kZfemg0GvOHMm3H
S3N6j+B2pNbbRw1QZr3rLHN3RzN5u1Mw5jIDtZPTWG1y++M9TuLtCltWn+etTuaH8+kTC3lqPc90
9BXACyIqUu4NbM9AUTHNwJtB104h/E3GklBBsVWYfFaEzNszzD8D7kL/4Sw4xaM0XzxB9e5nMn12
gRnZGU095l1ZGFohAUqDOW/oAFOBKJCh6GD0Ph8EKmJjBbJUBZaCl2jsIsirqvFCZJskyUnVXZvA
wsyO2rKm/o3/O5erFaumLupirpoxy/1KWth8mP0NtU68/ERHQvIeSukIxiqSwyEpiVV70/MZWSlJ
iZ6XEv0aQxXKsZTkYyWCs3P1zqC0C/5h2lfE3qtrO1LnPHgQz6SiqYNQrvIWYotoK8ksRKErM6Vq
FRYXRwt5/BvPRDJnL9By/PHpXhb9GlLVxx5kacS8nl/GaTLRUF7yym6Obfkqol1qOMPxvsnraKT2
GUBblfWzbECKsmbVbEJP4tB7mzS+tjRjASRWiL9//AwqERBW3StnUsGpVaosUwVdaBTkEXzr8N1o
rag7PuvFRwbN0QZbpmum5fFlqVd/Mf65OYSHg81Vyvasv44X2ZTAxmhTi/ZPlIUcq5PygO6woEgf
gsMvL9QSg97V+lcSevUQp+OdJjPYt42N9DNnVzv9Cw76n0t+AJ+AFzE9NorqeLRPVGX/LvrcKwfu
5FI5nESMUU7JWs3CY+UkH9vQ7qFQYQcu+B2ks9iuf5kei9qR1kt/5zdX7gEv/vo8FTxTy9qL7emK
/hHaMlnFEzjZnEjU8ERkiXiNW9Li3T3/YPNWTDT/hlq4FFkstegaAQI2IR0pMdgq4/aOb7CFBs6q
9WnJBb5zaACCyN077wLvZ9MkXU6lynpMlk8+xcKa+ZF/yQ9t2KgiceHnSKFvw1e9k4LKwkJUTnB7
dy8qbzSw21UWX4mN6zw9cn+HvOUGdwz9TXclKoY7afRh8B+h4XvVPv9mQn2WW+2/XDOorzWaIREL
Ijjqwa4eodCfHLuw1j+yOHlE3mu1s496ows3k3UHXbdAdIaEJzH4E0U1D+6i1YnqjfiDe+qnv6u2
BPqWXnOZ2lJIlTfncLLSkXpsP5yrqmOvibvoKWHILLmCc/W7LALxs7NlOs9k3uW5KvSLi4jEUqhW
EAWzYdrO2wcst0lWp4RdW6qge+96Z56q+xrdeL0vRSam1uW9oJ1ky7Wj9+oCJxIB4UYzYEe0oLHM
RFZJBasTIyR4nL3ksLE3Ejs5kB/o+zta6x044pjiWuQG2wRjfeeqvXAkPw2i633zUjRRFSD41gBx
Nc/Qj9e6aKUZPLUboaubB59LtawIWnUPtIFlAenGFKFrQ5WmUAKJLx1WHI/7WnurZjZKGjnWOHd2
jdXW2uGEJta6p8FYEUCMyQYPbpTFkYagJHWm4VGnVXwRk0Wp/Y/xKllu2wii93zFHOEqgUWQxJZb
quKDz/HRlxE4JFGCABYASlY+w1+c168bICTYrhxszQxm43T3W56pcBRfkghx8tZcpSF+X1m+g6ty
rqbp7nWrHAEPFx+1qUDvb/aBIudin6bZxHxtde2HlIz3h02RHA6rxF7pRKnOiO+OB/i5TjtobctR
N3akekTa0WmIAKIaRHTx0qoBVAL8zTWACgC9CMObyk1VjRftBArGxfjPteUEJMurVt7uJno7OJ1q
GvWq4jNYF7yr/U+76Ohug861c8+6ix/e2Him3poWYoEuFWMxXQ6D7inodNvqvHnnboo7ZhoG/MXt
C2wsl9f/xfOl4vnUuFDXslPxg51R2GB7dtoQSZ1Hk60rAIFcqvvonnywPpyEEKCPe/17pPObPK74
o4GI9pO0LYrtEj6TBXxeb49NXcW4XN2eBUbveYe63SfJQvNCGArOooLzpMhWOJHMymlX2jMxmpLY
9KDyZxytIRUZiTrWLkI+PLjhqj3/zM9B6RSOYJoVjtpYCy+IiW2xLxZUN19nYrpKXlhOTvEvTlgA
B02cjKEvGCu4tJEdHdJF7UBMgSti1+ug+KL3xQqqSnfJErbvetJeRQAZ7wLEBP5H8DC+P4cRcPrl
hJ8lJnOvrvEgSjlJxKOpV1FTlpGsBdqm4+Ndvsl2Rf4RIZS8eI1DPlnJ9sfoRNjEYIBh9OQd5MBw
UQo6ShS80RZnYUnbje7aT6LtkOXJb4mpu/ozDJGIRQH/Jd/MJAKCON6q8YEFLKxkzHV2ptMSyb93
B31kCpb583MY+7py1dsVTEb6Me55IKhIxu4Qle1hpQzW3I6VL2BSp6/Smg/ShzmdoBzqF+3Ay9za
cab34Aej/Me36fJ5mR1+YRhxw0BgAm0J9YyoParn1t/UQl4+IQf6+l8wYdUxC6jJpzzQM1DYu+2S
j7bl/EAHO6ni45dQn602WFM7OEUJ/qOOSfS1RZ5MyUvSHTc0gXtqlRwfBqkblCpeSLW0mKhsZaLu
kdraRa6sKfGEYp1a6xwpbd1VJTXxj6HbkObdF51GNpCz15xcaGDvT7CANiTte0ADSmblUtvNibud
ShMJs6dmaEHIUvB9S0cqg62C9J46lWSDYpU5F7WovmlCew4civswkOivnG8b6LwhOP3Waf8Eko5e
fa8roarw44Wd+fHdCb9bJ0H5BpnESrOz65HCzFWNFwUkZCPRhRLU6Imzy/dr2Jijl1j0ho4pmFK3
oiL88aVDKoZB7Uh3Da2h2sULgBXRk9wR2dbjSY+z3csK8MYdodM5WDhCQCfTFORKIByI1IXvoH/U
b9RJFpQkcKQzv2pbx7t2I+d//u5tA6oG7DPQW6RKrIW8YS61JBFMI8J5KiVeYL//fZSrdM+bzj8i
Q0sFDG6qJ9845ahjCAQHL9a1ANiTLAIQLzzLSbgyapruVcgZzT+5LN8kRbrm37SYwpYbnMWwGiis
WGKRTD0nl0cL6uWqf3v9MI1CssepIkUq8238ZMu9u+nANM2W/7A+kkO/H+2D7WOfp1mClbZz98Sf
tV3l4ao+45gyLXY0Wr5BKf2yBB0zPlDqD4M/h2Ep6tY5HsfYVpNXyhVWavTPNcofGPwtCvywOTPJ
Xmt4E6Y0XNxut/sVzGPqS93fBtYJqBu3I+zLFeWvM2CXqsqXlxSNlWxz4Cpyr9wf7ghvmfHPTW6a
KbUmktQp783eSThkr9CQEc2A180AtzjoQG9wUnNeq6vG0A468KIDYWOELVHa85KQScbdI8gQ8E2r
ioTOduWirmdenfSya+lEMnUikKw93cTTrIATcQBqJl3gX9It0azm/y+ysohCw94bVzL4pQrggvW2
0xosIl0q0S8jPcxkjegmYTU9xV2DNvpYV3QxRnpTVfbDVkI3n37ffjc51or2Dlo1kHKlSco90HeA
NBv8wKt9kP6jtuumHt8e3ONi5vgKo+ZUKJ36zjYZ42Cto4TgqJZXTNVWDZvGAk+QJunKo/KylugP
GkLdYOFBBxmvuqlLqsCLlWJkbJBcyJYNyAW1pRPdvFvoFbNk0jjZXXubcnobgowkRDNs7M3tByyh
4C5irbC+XpDRp+DHm+koVbNaWyKp/GMD3F9pBZbSnf73c8FOYcQOgIxKtsWmfXhGnqMV+6oK+pGP
JJSGkOMLWVqifp8f4wmlAMVlZmrPZMpHo5CUmz2swm8jJSnjH/WhJFHqMKgg08cc5hDqI/a+cZTV
Olohot5m+LqZNmoY2OBOnab5569//DcAKCG8CgplbmRzdHJlYW0NZW5kb2JqDTQgMCBvYmoNPDwg
DS9UeXBlIC9QYWdlIA0vUGFyZW50IDE1IDAgUiANL1Jlc291cmNlcyA1IDAgUiANL0NvbnRlbnRz
IDYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzky
IF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag01IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1Rl
eHQgXSANL0ZvbnQgPDwgL1RUMiAyMiAwIFIgL1RUNCAyMyAwIFIgL1RUNiAyOCAwIFIgL1RUOCAz
MCAwIFIgL1RUMTAgMTAgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMzQgMCBSID4+IA0vQ29s
b3JTcGFjZSA8PCAvQ3M2IDI2IDAgUiA+PiANPj4gDWVuZG9iag02IDAgb2JqDTw8IC9MZW5ndGgg
NjM2OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicxXy27cyhHd6yt6SQIixfcD
2cSxncBZOEY0yF34ZkGRPRrmjsgJyZGsfEa+OKce5FAzln0TXMCBZQ672Y/qqlOnTv9hc3Wz2UQm
NJvtVRj4QWQC/JO3HH9J5hdRgM8PVzdvx8zUowwwY91d3fzpNjT341VgNjU9nq6c9+7mH7RkIksG
PJrGBn4WBgUam3dXjqej5o1Xo+I4jXXU22+slSW5jIKlQUz7f3b6BzdM/MQx7t83f14tfzI49NMo
1Hk0x3n3+hZ5lGRqiH1pbuAnSazLONuzFfwoT5OTaWHCvsEbOfEJVtputNdu6peO+YCf0OlcL/Qz
p/al0xg3+/pTfl77+n/w/DUDl+Bk4rA48qMkTU8eC9LZY+qw20P1YN5SaAund2M/dY7wVEF+g7ed
yQ4P1s3xVrlehK+jfB7seIYDL2YwJ8bLcj8rEd5Xg5QWSYA9Sz+nVSk8D3bAJjEsIIh15q9oJbBE
Whv9OrghnlVt3QKR/dHx+M2eEjS4r4yK8BQq5BL85rHjMnGczPiE40fOjgJUwmOKcmrY33FwTM6d
AT9j+eSVWeAFSC3ezJt3g/fDJM5fj9XtsZ0sbRtHwW9y1gXKP8zd/Pv9kRKV2A+LNFslULwkULQO
yncOW/u/2P3++IAMK53fE+hL59EO7b/cDLHsO7+zk0ZGd+TIlKfIhEtkEtn3zd5+qbpmaKtr87c3
SJCQTxVFMWz80Zj+nxDxHf7jeKR+WhbFqgSkS3n87Pw3Syp7aWVJ/aSci877t++8zUcPWUfVxwtz
n3YEkxZ5cipuMX+MEK0gLEyW4DcvXkfJYFE/QzBeTzyag1hNVdd2HK/NYegfW+R07jScaQdrB2/q
vQOI16H/A6YoHqkEl1qchRqKeacolp0qrnRH14tBBdPOcrPTZltXk21MzZ076ay6zu5hx91xMrXM
7rp+Oi/0IaBbropvUK48b7/UexB67Bwbe+ba2A+SvFxFLFqQrBabuu8mzM6cCk6K8Nt21dT2Hfgf
B//Zsf69T5555I6Whw7HkQpT6Yw/u/RtO+BjSTJF0ghqJC7KNcF5M69pZJRUx2ONJMzEG8ihFy3x
jW9uzwZhw9HWx4EDprGl8sVfl9iadjQVjTh2rYSv9IswWTtxCV+Qizn/PNKxUodCQb+H6q7dt9Oz
6bdbO8i3hta8e5YlaXK2RsRS4meCIhAQzZiPx59sayZb77p+z87rXSrq98++eC0qtYYD7RTsV8tC
LHoqlHR6z1Z9kVouMSycw94ldFnzl4MU7EEqUTVxf8vPvqtkGK1zW9uuWg/VMZL5SPyoWMfzs/PH
fuAaZ2SWaj0j271mTj+b87oh42uG8IqqLzmwB9Eod/vVUjV8GjreL/aZv90ArtherRlHljKerFv3
DY+xPAXQoz1VBNX2MC0WHWWaIdDTmK3MP+55cU6ODx3P+9V2mTs5oq7YmAOM8zR7Vs4uV8mzpG6o
aMUBCFuAK1hM6AxoM6N01oOdyBpsCTh3c/fwqHMqTY93Hz5eK0pTJboo8IusiFe0sVDqjOsDjhGz
SIydO3Jv7tBxcz5uTsd1jBw25myCqCULCt6/kN3dQlCTM2ooLKHDgCFpGulKsqr4hw7M7r5lY2lS
1/Cio3liBpI5Ez93mlZ6mLOaPifTQVAscVeg2IHDuOBFodFYBUI1qApW2O7XCH2aQzoxPPo5L0YB
VDWXkqLgK+kc3lOaR6VYBreSTft23Mkb4lXrK6hRXixhEV4yU6+DJpeOLh+N9eDQgJQ+jWr3iMHw
qB8H/6LKoD+PV0ZFC+ZixdxP7YTFU9JNqFjzuzUHeRnY8722Zj9KiwCOnYHMXjoaHUUeSp1rg9A7
XY8z6oTODeQytBq1X7gyTuP4QkKXJ9muSg3QZ2SYO4qLBoJQWXE3kpQaLT9H3HEKZycDGx8ggz83
Ox54HOksshbHFOEnOCi7hLreA9CENFqvxz7oZewoH3TX82oNtQP1uc67C+GJashmWV6aym6BysyS
1kqL7by3neUNB4Zo6siT8hF24wLZcruRQYbZGGZ/kMU/Gf0u3bLXyJm32ckUHM0hqnlpgWxJjUjs
oKwEHpgq59JpyW+kkWjKgS06SEOMbFebNhLu2THnOZxqDjN50k6AVoJTjVqjOR1inGhHKo7MI67x
mGSQRG6ohJXw1glT/DD6EsMPvGLH+q/iqc2j/KI8SJu/jdrikTKAXRDr0iQ6nfFaFp3NYZoF08U4
wyncxQm+Ks8Ii6nQH6/MHMh90uaylbKHIUaQU+aOI2JZW5Abmmfu6KgWx6zgSMfVUHby5oNSHyte
ZZCeiuEZrda4kzXMpBqQnroc5FbX3HAPBIEkp57rK9HSAiZn6ycGE1hDaGKoWMqVHPsISm6AvGTU
vRk5AhH7mIsXtxoBcUtytdqbeXY1QhtKLaTSfPtphJdypiyhD1wcIE/X7HtZXBvWoqmITvhkuLfa
00vPA29HJFe3FRErStFAdnId3VotqNt+QL7Vli4ZkXOY2F39ILrCqsPUnu/r5X5LxxrtUp9ShIUx
Ia+gB9ooJogiWvSmqtmeSihPFsXAk8xU/aLztf6H6/pPNiDH9hWWbDvTTiMOS67gJI6hwPndbAfc
JDy4gQKRM/BjpznuNRQyyqMAxg77jjJwVZbsDJ/womCzNxLNdtvVR51/R/uT11E2XA8Kj/doFkTo
KcklEHX3PGYvkjZMUUHKdbG79HbF145GHOijErDrmD9CriABXZdm603f7Z/lSoJws8yCmiUq1Ypf
xkm4un2ctlNuv4fJ3jRU223L6Ug+LtivvCGVFfj+hZtDwWME2JOn9SYRgwmw2UV1vFBxm50IppET
jkwt0boXOZ6LIpu4jxjNYctE3sGuHQk4Si0VOfks3iyJv57iqYTHgoQG2K8ojjLMonMKDGZel4rG
TDcyW3ui2gslRpbyKBao6Ux/M3UJRcnEnW3O6myxugiKzlliEWvoWWml8yWUOVDarEMSZ3qytpMe
VUFaDx/1ffi3hEqaFDB5a3TSA9yKS2tzlPaeefR8wYUezvn0FdISEgJSOZmVuuy59B+URCempHlU
xxRGNJA7wp0MWzBssM4Syg11ldI45UPJylaua7MWzeQg9GJNoy8yBkAjaN9LZyc/On+yOpZosz3I
e8tS0OrICTedJ126rfXFtCPnh7ss2LsUqUGt25vt8cV+te7X9trhS6JzwTkHapSdS7N4BVTcoQDz
TBLmrhovEOclgdDNeU3Ml5QsXmqZhLQMpc7M19wnpE3EYvTzkVI15FKY64UE10r5piFE3qRJ+s1q
1x9eQKOaLPSy4OOJuhA5AOQlYMgsZT5A9ysfOX4tgsZW5MJJ30q6iThWoI9ggrzlXVOKMBPP+aNp
SHdYFKN+SZ199QzekZsQTOi3+j4eNJ0flgtEkOTlmiI/89qycuxsOWFBITg9tgPgcPMhg6jokTLm
y0HFU/jRCpBSwjEtsL/gutAPirJYxyFZ9F6yXEfnikX1ikh0Z6tL/oqK/Dv8NfUrXtJMEi8GdPOY
eemFx9txTXR1pdzEPoi+Qt4xDhQXp5xYpwSQmLKuPrvi+EEal6s0WvCv1V2kbobEVEXPtA/VcsPK
+Z1LmSrS/CO/c3ZA6avm7lWNj6Oob9zYiGciupNRe9QSCV4LLyRq+B/Sq2TJceOI/kodQUc3RYBY
j7ZsRUyE7ctMhA8zOoBAkYQbDVBYukV9hr7YmfmysBA98kEXErVnZWW+fC+aHkT9WJKgoIRoLL0/
rc9EEmWoZ5AqmYhC5slELlajVjJC+ilGRyqHSqoDLurS0t0xH4ulpAnWhZBMtFwKq+pODjceGdGo
ZZHuSvQQVmQLK+T1ZdYNf7bBhN9xUm/eYQZMesGyHtbk+MNCPR+W7XcHz/zd3nBLtXbrFgrihX9w
0G3pnw5WrA8CA8m4BsikX0YMdFZdgQs3WETl4APn8zt/+ct3mA9gNhLByKhiIU3BVt55C8oAy1lo
+FeAXelNvgs80CCwJKX+hulQg9244qZSb1Mwpyew69yNg1TNrEjZPIsUVXjenzIIqLwwSGKAz7xh
pm2ws9I3njRidYmDxX2HjSSJtGBUUu/kvVPdLNbOQt4u9p4MyZze3lir0cvlmMPaLiMyzQ/2WWoO
ej6cJrNuEKXSIQpG2qVKVOmVeYVswBovY9OogJmRK3HokjBnB/veprQfSW8Ey9LuTygQKQw08hAR
PUTGVbh7McJNfU8lVf8Ac8kDWwiO05Yo9B47Z/flv0s43ZM++GMz3gXCJA3JVS9EiY8U9SRlIuQP
Ui+SB/W95geyNmKZ2Zmb9ORYyZHmfWg365rguFR+AueU7GQqk5gkO4QbIjqnV6As5tMgdOyVWbnv
CYk7ei3+OqYIlK15gzZdQEhvSypOe1i78lNd0c4HZZJUuMy/x//YimMU7FrmP1v9osyyxbVZnVfL
Vtq44O8uVYVtzDfhEM2M97GonaWm5SNq2wAR+iwidpCulkARg1aSqSP0IhBtCsk9++DtaJ8Fqb8k
1+HkyGyq42Aw+keXIRiROv1u65o/4cdwE9fJ/pgkC2nFW043+dTwXchHny3HD2fPI2MN9uHBD7aP
vbFxY6LP+R2TuhzR0wOSiZ4bq8ZendXEdsxJVw5XfefQsUuqmtVwhzSSO87jna2r/IRWVfMs3eVM
peHoPex07wcidjFE6sGbvVbOZFF7RKPwgwruEjhwvvcqOEInOHiJH3By0bXAoqbTJES3AEqesm5x
45zVXvDBEcmsfnpNsTOHLS8ry+ar9SgdaEleJZAItt8O5MVQETbXd1PpGW96I3qwvjrNr6dMj4Ax
iJKlcPAnuXLUOso8OMHLk2EMNb1zhha2c21/RRNHJO61znqPRJIaX+y3WK7o0njavMZJF7Tu5lVS
ihEN7kmEuXssApXiq/kfcjxNg1vLNSH0etCLk7IpMyjfEeKyIi1LmqJcBI3fOBBAR0yrrKj7Pn3q
RZyuD8pBBLrlokKIzgjDclA0o5zrTUnRkko6fqTUaO/SOkVaU0BSdhyi8LsEPNzvuJ4cDBtjfhSO
3TKBbopays8oCkLpNZ1KF5IOEPTPotIw5/VVqHje3R/AhWoUIR+bIkJGTZltYYxhW/5GqV+WHQsi
UkOsMCOuCXJB0yPCuUGqzheEIfl0qq1rCTgilhnj/MNKfE1Fy9ei9U+6eOJ94SQLvH+Z4X6TACao
JJQs5G3m7ZnTCfkhaZlrD2cv2NNGKsX7OA3iZSrFc3W157Ol5Hyz9V0pgfop3B+O0VItbXisKdqx
AZu0zJVBybhGKL9bM00VP8T+gyDYkLtDNEE7dr8ycrCiZY905Xve2R/66tIsu+tn8go6oFwT4f7S
caHgpXeo7RvaFiv25rP47MAUT2rwWXfoXK+2zwAiEgh+GM5+2EaKKe7EWWN6D8q5IS9epALxMRoM
fDQNckSUGhL+XOjxJMF0fWW5V9qIsYWIZieI+s17r6YqRb0VMdz2PLBj1LWUXX7yAUWaXHvE1mQv
7xEB1Cez0SfglrkhnBYBCFlkiT77tuNwa7RzMPrxJqO2K7S92snoTrmeWaK5eFeMitMDMnYZsa7c
18/ynqGw9Gd+rdp8atBxbvEv+cKcPL+hRseC+pXtwfxRIWKOWbdEqlTGIAiGd3PdgWNvrPDYbMoV
ovXAeBj5CPETReFAmfl7SgWd3Mh4SUWDNVmmoMtHErr4ArrQXjdMa7GQzsQ/aTvM0baYZ9DFmH7E
4p0WXnbPZgsZNGfZ380R3E634uTwWIMPyQwcAj0rxCBr/GO6QIxsFh4uVUSFZqKgMlS3jG7DtPjK
TiCfS93GAGfkkeGdC/aGYaZZqgzzqzc2+UiUmOH/Kkt1gx2jZCX7/ybfOKSEpjU4GbNyWdFghCtz
SvFLxke6nuEFzB7zHsTLgTA+Xlw+iKbL+yq6zk7IpKT5NgDIlUCzVNMUVCnVwE7ZHawu86HSDh03
X0N8/OzoT7rggsYRv1SJX+qIXyrELwAM1n1rCh3HOTedXOV6DmcAleWvkZ5mCI8I9mJPt1do4sMv
7Rs+fx8eH+5ILg2WwiOYCstRi+GPZEckNbwV4tUQFZAkDZgxDrarckwQ7OaPTlCAv6aeV50j3uKP
RlES5/8RM/vCHhNG09YCYe3lLqzHELbIxwg61YEEge7chS2Zf7zJjBysadwp5j3yN6VMj2FEeXhI
XbVhk4hFcdRk+8CP4m3QbMrGT4iaADgbecS5n+aaAU6BBvlRv+zAIcAqpNUh0w/diO9iGDtbPm1Y
RbQ/pKtsD6eAjxStiTKSEPQKQTehAbG3AjBFpbETb1Gsye8duNZ2xGUFriy4bKqLW+ls5DfHruvl
G5/GlHGLCh5PEK2GkodasBkrFndM8MC7OeSYLwQeJ5c1hUxo6SRy11A1Y7UjNLhobBEGx9FxU4EP
2fRM4ZzbQrE7m7OMo10jT/uI1eEDPIXFa12P6KJ3yQdSWMNVpwzb2aLjuGebfD4Znx6DP8MFvxN3
5qSxhLBjb6LDRZtADdXc0s2870BhlcPsKckTV27nZeRhfFWyQXNBS6juKtCHoSa/uOifNvMdTgbE
CLnBjF4LOKkgPwu2fGmjNHsVi+27gejUNnm/tqoKK0LHxOtrhmdVjy6rVlpykHnrfazJdVL/brsH
EbtG8USTlERpC64UUtnNlokYz2VXKchFlNRdfnnLlus/YSUxSwk8EJGxIR8fvF9GLpIErvlNFuBX
uAJdIi9kULJZNCStaKdG6AZ0C2x/Qx8H6FF0kux4Qm+9C4XJHD0ZfiL3CKkJUYsft8XL6Z0XcCix
6M83j5Xqts2wA9VN6fF/BeNBF9EPZkFniK7HVKGIibNo4dZk3lzDgsGd3iPHP2/qC/0gN3WVtJh0
xHJ2CNJxBOlg7pVwLW/6V3kKTAfH8AXhkg85RhAsdeQ2UpkpOTZN8VkbwovzuSr25tMgL4+B8y6Q
15/izrjc18B7mkZK01kOajdS30GPE8FeMlwqtIYk5RYltDZGDfg5HxD0iNtnn/hBFgSbSrzRmcVd
iNdJy0Di4ZcUC2RRJc2mqEVujmUl/81FVjE88r9gOHV/2z2ZEzZUKUYMk+xYstwJ3HwFt7wsGTaq
5kLAyzUghiQ6sjS10qJc70fb02Mm3gd0lQRfnBB9PjwIXvkMneIjmSvEk+DQ5F1xJa4j5fchELJZ
HUnYz4EZgWqKzgSCu/P32Zp1xZogEnGRd2moBPtykbN01Cgm7TsEgwgqSSGXUB2yp36wjfKd8mZB
YFBawGLC4z4Kw+z/a6bPLC5ioaIiTSB1KF7ZDu0bUfp7UANzskRa6OXJQrCGG1RVaZQ8GPwpD8Gg
uebyD71VYuhd+6ypFzqLqqLsvme4oJVfBNpWrGbWYKeuWiyF2jKO9FzBXzCjUOrz3DipBsNYLeay
ul8qQln6tjy0XN5HG3oUZhv8wQhKeoPrNTpVz19KSpylE1bU680dxo9+2NLRDR7lihUM+gCN4kpk
S/Egd1Bi6badIkzeT1iDm7cnhy6vktl7JJ75a1lq6VVFNOGQIFNNZOCs/R1W5qiYZHWWxI/UdRl/
K7rZmNXz5m9gntWCc+KlThove/OT6KJRJnYadxZuNaXuBlo8MuZL1Da9UEtKfBcCFvthYvs/4qum
t2kgCt75FT46Um1lvbYTc6zpAUHTKi1cIg6mbCVLIQYnBfE7yA9m3sc6m6ipqBrEIWtvvN5k582b
N8+nQuozbioZl/jzwKtaQ2dRWbC79INZVz0wYy8IWTEpwkbDK4Zui+yHLgauuRhUUUvNnMwy1xG3
unPrgBPWPNZYxVF0oEpwFEUe1NidT/b1e+7ugYEFQYh3veOqSb9G1Gh0TiHhatry2iWPDbdZn2Xi
oo6nKzL0gLZncZFNv2ujxk8cy4mN0wNZw8OiwN/DNauqAeNxHrSNC0N7lPEnXHIKSnwxIg2t3ySX
CLGN392ez5ODwlAFDV+QQ/HVx9b93HfhKF8mC2lrBrS0ghDAgOM3NbDoXdG20vzqh+Oq0oOOSGHs
u9WF9ImOjnJ5es1L1v/lmOGk6hgQBBQxjoHlGAD0TOAeI9OuRzSiP1ptotlIPTcqX5y+po0+3NBY
nuXTyRlSEbfytMyjc8Qnj43MT3+Ek4zPgJfQsjhROTEBXdgnLI5uNWN6MGJgSarQZ9rZ6m4B9o8n
7ML6eJSgv/Hknwr5yd0xQ99yC3Cd3C85M7ruC5mruntYbSSnezH8LHrI32YNG7TeHkfhH5Fvt7//
jSFvjuCeQ/OzIrRaZgDJ+jwFsFSYqliZ7V8K5EUM3VBQMy2oi5yq30RFBsuBckJgM9BTzBXosawT
uC8fZLbctMl7ByuT3Lg7/a5vN7+2/5vczyO9AI1qOMltQPAiEOO9l/ZUxL8XUDkJtFwDxlgXXsor
QdkSynUtmNbdV7DTkD+ogaHr2wYE5q++EbJobdsGpWr79FlOkfABNV+M+UzAteLQAxbv2gxrBZ+O
fVoWp+Cz3OlFROPi9tUfAQYAB3AdzwplbmRzdHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwgDS9UeXBl
IC9QYWdlIA0vUGFyZW50IDE1IDAgUiANL1Jlc291cmNlcyA4IDAgUiANL0NvbnRlbnRzIDkgMCBS
IA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9S
b3RhdGUgMCANPj4gDWVuZG9iag04IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSAN
L0ZvbnQgPDwgL1RUMiAyMiAwIFIgL1RUNCAyMyAwIFIgL1RUNiAyOCAwIFIgPj4gDS9FeHRHU3Rh
dGUgPDwgL0dTMSAzNCAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjYgMCBSID4+IA0+PiAN
ZW5kb2JqDTkgMCBvYmoNPDwgL0xlbmd0aCA2MDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSInMVUuP0zAQvudX+OhIa9fvh7iwtBWCwwrRaC8rDlXwQqFJUdKyiF/POHabsqIU0EpF
rfzIjGfG3zfjeVEVk6oSiKPqvuCMMoEY/NLKwl8Z6gQDcVNMpr1BdZ8UUF+3xeTlgqMPfcFQVcfh
ocDzsvoUTapkkg3aUZdRw5mDTTUrMMlae8dHWlJqmbWmv7FllE1aECmT0f8d3jQlV1RhVL6rXh+Z
HwPmVAuez8UzeHbahRXK5EDCz+EyqpTMZvD9IwtUWK3G0LgasIFVBPEBogxtH65KTT1Gr2DiuC0J
pwbXNH1EqDS/HtN0SvofjH+ieCDHJMCkoEJpPSLG9B6xDNjiy7JB00itw5tSUo13gJSLuAHaeBu6
JpQWVsuSCJD2SdyF/lEeEDkks0LEWGo80HuSJO0UA5+e2mg10tOEDpxIiCCmWIvewk5BJGlXZWlX
chiXdSgdMHtpPp5sTKQBfF44PlIFtQS4kQE4k4BLJ97A9QX+GAnygFjO8rgJzwZykB0+smGUSUS8
YYRBaQ3OyN4boM+VtKe5WuxW2xDdSsGe5K6HVL4Y3MN8XjOxIil32hwVkDwUkDgm5cxla/o5rNe7
BirM4+cx6T3+GrrV99IAl5uWtmGbmckeB2b8yAw/MKOS3+t1+LZs33er5RW6vYYC4cOthJAQ46Vz
+p8y4sz7N/ChqfbOHbUAfWiPd/hvTObXK3cWTZXfN535dEaqGwJVF7sP4ZZGj/CSOqvG5qZya8ov
Lc+9XSDhgVyDLHPUqdjax7TBN5stPJxwcF4VPwQYAPsphfoKZW5kc3RyZWFtDWVuZG9iag0xMCAw
IG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiAN
L0xhc3RDaGFyIDMyIA0vV2lkdGhzIFsgMjc4IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5n
IA0vQmFzZUZvbnQgL0FISUdHTytBcmlhbCxCb2xkIA0vRm9udERlc2NyaXB0b3IgMTEgMCBSIA0+
PiANZW5kb2JqDTExIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgOTA1
IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9GbGFncyAzMiANL0ZvbnRCQm94IFsgLTQ2
IC0yMTAgMTAwMCA5MDQgXSANL0ZvbnROYW1lIC9BSElHR08rQXJpYWwsQm9sZCANL0l0YWxpY0Fu
Z2xlIDAgDS9TdGVtViAxMzMgDS9Gb250RmlsZTIgMTIgMCBSIA0+PiANZW5kb2JqDTEyIDAgb2Jq
DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNDgzNCAvTGVuZ3RoMSA4NDEyID4+IA1z
dHJlYW0NCkiJfFYLdBTVGf7+e+/MhhDIAoGQBzjLkEiziQjlEUOAQLIrNPIMaBbQs5uHJjy3ilSo
NTylHdCCILWl2kOUBnnYCYQSwVawxYMcFSlIkfpIPVDFQg+FUqnCTv/ZhEh6Tr2zM/M/7//9j7ln
QQC6YCkkJk8qGzg48uR9dwPGNJZOrJwXiaJMGwP02QZQYeWihcaKS4P+yroPAW3Wg9GH5tXLf6QA
ej7zdz80d/GDXXMW9wAylrLN3JrqSNXesXsP834vMT+shgXJ2fqfgM6uvn/NvIWPfTChJMg862V0
7oLKSOqQ1CHsf4Hj7Z8XeSyqPYMj7M8yGPMj86ojR54uBG5TrB8YXfDIQsbNq+9ZVx99uDr65R+L
lwDJjCmpVtuPzPjdgEyVjUzAOXvzjtU6Z12d+xZf8G59Wu+2tRs78WcaQAb20FdIxTVKo0EYD4Uv
OeJvcAPPIgXTsIm6oz96YTrGk2IbP9bSZmeRcx4j8QzqnX203NnO+p/iTVxjBB8rwnBMZPvpqMZ5
eQ4h5xdIwGp0xghMpV6I4BRfVxnDBmzE7+lx5xpHTcFy3q8QYzDGOeRcRw7WqnXa6U57sR4HSHcq
nVr0RT9Ywu+ccj5BNkJ4ETsZk58OqnHwYQ5W4TlKk28y9SxeQoySxP2yWHudI43HvZiPH8DCdhyl
7jRZO61dcn7ofAYdPTCAMdXiPA2lCWKrSnJGOWcwE6/iCOfrXgfVTNWgzYyNdp533kBP7KNEeo0O
aYO1p28sc7Y4ryCJ8QziikzkOBVYgUN4C//EZVHn1GEcyjjyYepDBmVzxU+JNPGEeEKewB2c7f2M
9lH8CjZ3ZD8O4Hdcm7+gBecohTLoe1RB6+mySBJV4pjcLJvkSUXqZa63iSyu0UJsxW/xNt7BMdJ4
/ztpMs2mBfQzep5ahC0uiC9VglqhvlY3tOxYS+xrZ6JzFb2RjnuwBHVc2xexB014F+/jMq7g3+Sl
fKqhLWRTC10QnUQ/MUlExSaxVeySE+V6eUgNVWPVHPWOOqM9qa3xRDyx67+ObYjtih139jnHeXa6
8v7ZCHJFl/FUbMXrOMG7f4CP8Kk7P7z/CJpBD3CUR+jHtJF20WE6Tl9wlohf/cQIUcJRF4iHuU7L
xQaxkaMf4+s9cUZ8JP4urkpN9pPD5PflFmnLZvme/Jvyqmx1hxqkJqkZyuHODNbu1sq0bdoO7Q3t
kl6oV+lR/XPPcs/KhLdv5Nz4OIZYTcyO7eHZTeBJWsKVeAH1PPdN3IOjXNF3GXEL/sVdSCcf3c64
76IgldIEuo9mUTUtp9X0DD1Hm6meXuEMOAfhYex+MUaUiYioFivFavGUaOJrv3hLnBKnxUVGnipN
6ZeD5Hg5Q86U8zmHhfIJuZIru15ul8fkCfmZ/Fxe5K6lqr7qUbVE/Vw1qCZ1XLtHm8dXvfa6dlA7
rl3XrutCT9cz9YH6bH2b/qlH9wzzTPb8xHPScyUhSpmUw8gN3LJEGn+DfcV2kaLq6CIL+pBCMmfu
5z6U8VdxBaNljPvS1dUztp4iTfVwPfUiZbP/QjqAoXQYdbqQfKqqFuymD0WL+oMYifcpTGmqQc7X
jgofdvBptE68Jg7QWDSJQnGv+KUEnaNtOMfz/hg20hx6BDvoIhXQj2g41eGk6CXLaCUKnXqhqBON
p0tgBFimqvAAvnXRXXxan4+9oLqox/l8asYm7uhOfEIv4yvSnAt8ukk+jSJ8yqzleV8F99S7n7+z
Ov4e0/gEmasfQxPpgGe4PkotwSX8B+eLiopGjxpZOKLgrvzhQ4d8d/CgOwfekZfrz/nOgNuzs/qb
/XzGbX37ZGakp/VO7dUzpUf3bt7krl2SOid2SvDompKCkBswg2HDzg7bKtscNy7P5c0ICyK3CMK2
waJgRxvbCMfNjI6WRWz54P9YFrVaFrVbktcoRGFerhEwDfudEtNophlTypl+qsQMGfbFOD0hTq+L
012Y9vnYwQj0rikxbAobATu4qMYKhEt4u8bOicVmcXViXi4aEzsz2ZkpO9WMNlLqKIoTIjVQ0CiQ
0IVB2elmScBOM0tcBLbMCkSq7MlTygMlGT5fKC/XpuJKs8KGOdZO9sdNUBwPY+vFticexqh1s8Ea
ozH3oLW22YuKsD+pyqyKzCq3ZSTkxujm57glduqSs72/YXnz7sXlq2/VZkgr0LvWcFnLWm3YB6eU
36r1uc9QiPdgX5EVDFtBDr2Wi1haZnA0sSpUbtMqDmm4mbhZteZXbQZcSXi2YXcyx5o11uwwtybd
sjF1sW93enrRq04L0gOGNa3c9NmjM8xQpCSzMQXW1MV70oqMtI6avNxGb7fWwjZ2TW4jkrrcSlS3
6+JU3NylSqe2V5ZcROZ4HgjbqDQYSbnJOeW7j+p8WJX5bMYrROxlV3FHau1OxWHLW+DKXX9by/Ka
hnUVPAHmxQsdJZE2iZ7lvQqXdOekfdRYf5O2/X47J8cdEU8x95QxjorzQ/NyFzWLYWbUa/CLy4fJ
XNtIqGAgl9/ncxu8prkIFczYS6eUt/IGKjJ2o2igP2SLsKs5eFPTc7qrWXpT0+4eNnmSm+D+5+tp
J2S3/5K9vXoEagps6vUt6upWfWmZWTplRrkRsMJttS2d1oFr1ee369oou0dxucwQbZTIkHEtD+Ws
dmOXKU+yVRb/9PhQV9mShzIuICNoe8PjWp+hRJ/v//o0exJucWp2Lrle8dc3bm0o7QJ/R35EB74D
uiRLMl6VLUqnzbCsxA66IB9AlhU0jaAVtiLNztIK0/Ca1quiQTRY0UD4ZkObnf1rMuzg2hAnUUMF
eXCL7RkVm4jiBDj1TkNCXNJh/Zf0so1t6jrj+DnHL9cJJHFSRFOi9NzEtR2cmjgpaRrB8LXr0BVr
whBI7YaqhipSoZrw5rhoQENAQ1vEQsPYulZ7weuHCAW6XN+ozCmZyBRNXTUh/DGTJi1SmaZtYVTa
1H5Z5/2fY/PSLV+qOfnf/7nnPL/znLfE9/7BWa0S/VXNsKLtdyxjz7ImaKfWylKOD9mL/M/sANpe
g561teKZ9yrbj/gc7rPwi6K//Dnih6B3oaegr0E+aBh6oapBKALmI2gGfbxM/Sj/mB3RbrKvIBeD
3oIOQj9wDLEfou1Hzn52iOqR63vow4PyO6j/qXOGXUD5bbSnKFY58UNsF9qfRPmiY6hc1iaZhjqG
8ueo34j836cxw33In7Vny3dQDqDv59H+Hfh++L7qeJtV+WNi1FxpjhNUxvqMof4CtBc6Bw1jfYgP
gZO4n0R5HcZVA18P1eMFox0x2/HdbcKDyP9sdd5MzRvzuD8njF+NaW3RmkYeFsZE8/oLdBMqPTS2
/9bkF5RlMdtTav9oznXQNnGTRbEu/6Z5Of5U/oyEM7SMeV2HHDhVMxhjGM8JPYjn9p+wo+JT5hWr
bBPWJQnuBWgEsUtqn7PlVcSloSPo56N7c6Z54v6r2KMkYv6FMh4Y2Lehw5jP29A3kaOb1g779xk8
iD7jJBp3ZU9YDvHfoDOu+q2sYcUhtB/BevwCugH9mnLekzojVam+ZphNzJT/Ab9A54Pu1XmiPcWe
OT5UZ2iwOpb66hk9hzl+HbHD0GNQh/MqO1BVh/01Ol/8r0XxnpXokgviqriCdwEprli+TbIopud8
T8iG66KXcTxyj1qtsilSK37Ok/yfCMqzZXLWJN61+n6L8ClrQZfzYkpMGY8aXiNoTNtC3lAwNG3T
vXpQ79On9UhZnGcOdkmcQ5fncNXFBMY/wQxoCrIzU4yyRUiwcVzzqpTGNaNKeOpk7vutn6hSWJxl
uyGBHsagU9A4dBq9TYnj0AnoJPSGqhmFctAxPAdmQGRAZEBkFJEBkQGRAZFRREZlz0FEpEGkQaRB
pBWRBpEGkQaRVgSNNw0irYgEiASIBIiEIhIgEiASIBKKSIBIgEgowgBhgDBAGIowQBggDBCGIgwQ
BghDESEQIRAhECFFhECEQIRAhBQRAhECEVKEDkIHoYPQFaGD0EHoIHRF6CB0ELoi3CDcINwg3Ipw
g3CDcINwK8Kt9icHEbECYgXECogVIiJ/hx+HTkAnIWJWwKyAWVFMCUwJTAlMSWUpgSiBKIEoKaIE
ogSiVJ37qFoNgXMzBp2CxiFiF8Eugl0Eu6jYRXW+chCxJggThAnCVIQJwgRhgjAVQSfSBGEqIg8i
DyIPIq+IPIg8iDyIvCLy6uTmICK+/Kn80nsjTvOki+OPcpxvVn6KrSofY8vK32AF5SfZtPIT7Izy
46xP+THmU47+lI8ySc4a8Me/G3oZOgpdgmahG5CmSregP0Jl0Wu02xu03dolbVa7oTlmtRVNNDh3
Oy85Z503nI5Z54pT6JEWUYevd+qPszfV9RSudyHBunANq1JYbEXerUyIXvxsFVuNxjv63QC/FeA3
Anw2wN8M8EiNeA6vrI9juDrrwxuW5EljnW+HXIZ8/h34l3T+2uqj0vI9LYt8oWKbjU74KlSApqEz
UB/UAwUhLyRVXQDxSaOt2uMC5IfoXofYxo34TmhqdBnzoo5Pz/2mjtVQGn8HsOuWPwQrWv7dsF9a
/kMyUsOvMT+nYb6PXbsCn7XkbTS/V7GrlrwOu2zJrbCXLP8W2LDlvykjdXw/vrYJ3Vf1QcyafK8l
hxC2x5KbYZ2W30fRASTyonUzT7LbcG+VeqKSyWPJbbB2S/ZTtIv5abPxyhtUw3NA5LY5DOjuPE/a
ubFO3pEX5Srwv2FduSV/rxftsFveIh8yauVC8GcIjkgrUkvxODqFqpvk78tp74T8Mfri3mvyHblF
ng8WXaiexLgnVApLnsG7wBXjETkuQ3I0eFtm5S55UO6VL3lRb8kDckGdyRRPiivXZAIdPo9ZeC35
nLeohrhTfksa0i/79QVaX/ZMpd++4AKtAOupZH8S6xvwXld97eeNRkD7RJvShrWotk3zaO3a41qr
tsHV5HK76l3rXbUul8vpsruEi7k2FMsrRic9sW5wusmcdrraVdkt6IoLPb0K7hJsFzMfscVFfDDK
4+biKyx+SDc/HfQUeS2etB2eKDeb4iy+L2o+0xkvauW9Zl9n3NQSw8kC5+dTqDXFd4uc7UsWeZmq
zrbQK22Bs7OTLfOM88fOTqZSrHnj6+HmcNOOxv6dsTUu6eq188Gn+aEicraab8UHk+ZMa8rsoUK5
NRU3T9Mr77xoEHUDsXlRT5ZKztszomFgL9XbM7EUwm6rMBzneoQxPxnCXFGmUxj+mUQpDJtUifMB
R1wbGeJq65hPxflq61ScnVNcYVkfiBV0XcV48XCnYpa97KEYHBmwsYLPp6I8Ok9SFE96dDWwzaoj
KRESlCqE1zGpOpJcJTO7HoR4qyG990N6VS4bfxAjKzEbOu7FbOhATOf/+RmJdvK57tzY0sCIZyDt
GRiB0ua5119tNscP6XphLEcNumnzpQ+98ir5wREz5xmJmWOemF7oXlqjeYmauz2xAlsa2JcsLBkj
Mavb6B7wHIyl5sLbk5Ev5Jq4nyu5fY3OtlNnScoVjqzRHKHmMOWKUK4I5QobYZVr4DCd/ESy4GLR
FN5alc+JdbU4xemWtlR0ozuzg470/La25rGWD+yMX2brOlPmek/UrIOoKRgJRqgJf2nUVI/qhmpT
89i2tpYP+OVqkxvVjZ4ow5GufhiFxc3ePXGzbfDFJB0W0zj4P7tWBbL0UQHNbOBwDL+4H1XCz4Ne
Vc/ZNT+ja31yuVyWLjl0kWUsbgYG4+bTezAeTUO6dCyFui336mw2VVeoqRkolhfRCApD4aOUslLu
5J1YTaOWOZkm8s68JubLeKyZ29Tac/RX+Co/BQnUHLO6unuo6dhcu7fHKCKkq7fiHQHl1qa2HmSZ
6wNK7q240RhEYco7FZzqy3vzwXyfE7XXplEpp+lr1er6D7vlrtJAEIXhfy/ZTSw0UREVlY2gCBvw
BjYu5FIYBTVEsEglwRvBQCCJj2Ctj6AptBBExMLCwgfwEex8BbUxbvxnnFjYrIVNwDPsmW9mzzK7
/xnOzrmBultry0GsF+CK1xLrnd2MjMqFTwW4bsGtaVI1iMpIF2LjOcdG5lbXfMu+05OpPoRM30CX
bfoahsJWyNeNe20SEe1aG8SgG33zPrz16Iu39uEhSY426WZn4rF4bIKOdRhNx3hopkJ4h2M+iNUW
/ltHNrlTxI+U1s+dQtKGeVkINCM4pLPNxJT0ptTHabW+fOtZ6fUbCcLYU9EGYoBikxxTbJHGhfJm
hDPjmFesoxubig3Obys2yUeKLfJFenklm8256WqpWE5kKuWd4AmksYwVZNlycDmqooQiykgggwr7
HWxgF/s4JBd5Nzj+LyKkIk8EG6v8Th1RDGCJcuWpvdylTMUJS1pY/qZkar567Om9fPzbfqYhSUMK
Dg9K4uT4aC/qVyobHDpzB+tbPd4rq6GMbjx7o6K/PJ4eazX8fBj2IoeRdt4/BRgAaaioxAplbmRz
dHJlYW0NZW5kb2JqDTEzIDAgb2JqDTw8IA0vUyAvRCANPj4gDWVuZG9iag0xNCAwIG9iag08PCAN
L051bXMgWyAwIDEzIDAgUiBdIA0+PiANZW5kb2JqDTE1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMg
DS9LaWRzIFsgMjAgMCBSIDEgMCBSIDQgMCBSIDcgMCBSIF0gDS9Db3VudCA0IA0+PiANZW5kb2Jq
DTE2IDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChEOjIwMDMxMDMwMTE0NDA0LTA1JzAwJykNL01v
ZERhdGUgKEQ6MjAwMzEwMzAxMTQ0MDQtMDUnMDAnKQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGls
bGVyIDUuMCBcKFdpbmRvd3NcKSkNL0F1dGhvciAoT1RCQykNL0NyZWF0b3IgKEFET0JFUFM0LkRS
ViBWZXJzaW9uIDQuNTApDS9UaXRsZSAoTWljcm9zb2Z0IFdvcmQgLSBYVE4wMDYucnRmKQ0+PiAN
ZW5kb2JqDTE3IDAgb2JqDTw8IC9UeXBlIC9NZXRhZGF0YSAvU3VidHlwZSAvWE1MIC9MZW5ndGgg
MTA1NyA+PiANc3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49JycgaWQ9J1c1TTBNcENlaGlIenJlU3pO
VGN6a2M5ZCcgYnl0ZXM9JzEwNTYnPz48cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMu
b3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUu
Y29tL2lYLzEuMC8nPjxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9ucy5h
ZG9iZS5jb20vcGRmLzEuMy8nIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4z
LycgcGRmOkNyZWF0aW9uRGF0ZT0nMjAwMy0xMC0zMFQxNjo0NDowNFonIHBkZjpNb2REYXRlPScy
MDAzLTEwLTMwVDE2OjQ0OjA0WicgcGRmOlByb2R1Y2VyPSdBY3JvYmF0IERpc3RpbGxlciA1LjAg
KFdpbmRvd3MpJyBwZGY6QXV0aG9yPSdPVEJDJyBwZGY6Q3JlYXRvcj0nQURPQkVQUzQuRFJWIFZl
cnNpb24gNC41MCcgcGRmOlRpdGxlPSdNaWNyb3NvZnQgV29yZCAtIFhUTjAwNi5ydGYnLz4KPHJk
ZjpEZXNjcmlwdGlvbiBhYm91dD0nJyB4bWxucz0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w
LycgeG1sbnM6eGFwPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6Q3JlYXRlRGF0
ZT0nMjAwMy0xMC0zMFQxNjo0NDowNFonIHhhcDpNb2RpZnlEYXRlPScyMDAzLTEwLTMwVDE2OjQ0
OjA0WicgeGFwOkF1dGhvcj0nT1RCQycgeGFwOk1ldGFkYXRhRGF0ZT0nMjAwMy0xMC0zMFQxNjo0
NDowNFonPjx4YXA6VGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5N
aWNyb3NvZnQgV29yZCAtIFhUTjAwNi5ydGY8L3JkZjpsaT48L3JkZjpBbHQ+PC94YXA6VGl0bGU+
PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6
Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyB4bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2Rj
L2VsZW1lbnRzLzEuMS8nIGRjOmNyZWF0b3I9J09UQkMnIGRjOnRpdGxlPSdNaWNyb3NvZnQgV29y
ZCAtIFhUTjAwNi5ydGYnLz4KPC9yZGY6UkRGPjw/eHBhY2tldCBlbmQ9J3InPz4KZW5kc3RyZWFt
DWVuZG9iag14cmVmDTAgMTggDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDA5MDYyNCAwMDAwMCBu
DQowMDAwMDkwNzc1IDAwMDAwIG4NCjAwMDAwOTA5NTggMDAwMDAgbg0KMDAwMDA5ODM3MSAwMDAw
MCBuDQowMDAwMDk4NTIyIDAwMDAwIG4NCjAwMDAwOTg3MDUgMDAwMDAgbg0KMDAwMDEwNTE0OCAw
MDAwMCBuDQowMDAwMTA1Mjk5IDAwMDAwIG4NCjAwMDAxMDU0NTcgMDAwMDAgbg0KMDAwMDEwNjEz
MCAwMDAwMCBuDQowMDAwMTA2MzE1IDAwMDAwIG4NCjAwMDAxMDY1MjUgMDAwMDAgbg0KMDAwMDEx
MTQ0OCAwMDAwMCBuDQowMDAwMTExNDc5IDAwMDAwIG4NCjAwMDAxMTE1MjMgMDAwMDAgbg0KMDAw
MDExMTYwNyAwMDAwMCBuDQowMDAwMTExODQxIDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgMTgN
L0lEWzxlNjI0OWJjMzFiOTZkYWYwZWVmNWRjNGJhYWQ1MzI5Zj48Nzc4YTRmNjE1YjhmN2IyODcx
MThhNjhhY2ZmMTI1YjE+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ==
--=====================_3148827==_--

From djb-dsn-1096228231.59299@cr.yp.to Sun Sep 26 15:50:16 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8QJoCPU015236
	for <saag@jis.mit.edu>; Sun, 26 Sep 2004 15:50:16 -0400 (EDT)
Received: from stoneport.math.uic.edu (stoneport.math.uic.edu
	[131.193.178.160])i8QJo9II002533
	for <saag@mit.edu>; Sun, 26 Sep 2004 15:50:11 -0400 (EDT)
Received: (qmail 59300 invoked by uid 1016); 26 Sep 2004 19:50:31 -0000
Message-ID: <20040926195031.59299.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@ietf.org, saag@mit.edu
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
References:
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000553
Spam-Alum-Time: 0.580644
X-Mailman-Approved-At: Wed, 27 Oct 2004 21:24:18 -0400
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
Date: Sun, 26 Sep 2004 19:50:17 -0000
X-Original-Date: 26 Sep 2004 19:50:31 -0000
X-List-Received-Date: Sun, 26 Sep 2004 19:50:17 -0000

A note to everyone using HMAC: Modern polynomial-evaluation MACs (such
as GCM MAC) offer strong security guarantees (they're provably as secure
as AES) and are faster than HMAC-SHA1. Some of them (not GCM MAC) are
even faster than HMAC-MD5.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
From wata.34mt@coresecurity.com Wed Oct 13 17:45:37 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9DLja6A025723
	for <saag@jis.mit.edu>; Wed, 13 Oct 2004 17:45:36 -0400 (EDT)
Received: from sin.core-sdi.com (mail.corest.com [200.61.53.195])
	i9DLjVJp000563
	for <saag@mit.edu>; Wed, 13 Oct 2004 17:45:33 -0400 (EDT)
Received: from webmail.corest.com (webmail.core-sdi.com [200.61.53.196])
	by sin.core-sdi.com (mail system) with ESMTP
	id 5CCAEE7C78; Wed, 13 Oct 2004 21:45:16 +0000 (UTC)
Message-ID: <416DA2C5.1020604@coresecurity.com>
Date: Wed, 13 Oct 2004 18:48:53 -0300
From: Ariel Waissbein <wata.34mt@coresecurity.com>
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeff Williams <jwkckid1@ix.netcom.com>
Subject: Re: [saag] The End of Encryption?
References: <4136B45E.1D742E03@ix.netcom.com>
In-Reply-To: <4136B45E.1D742E03@ix.netcom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.667050
X-Mailman-Approved-At: Wed, 27 Oct 2004 21:24:18 -0400
cc: saag <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 13 Oct 2004 21:45:38 -0000

Dear all,

NP-completeness has been a nice argument for constructing cryptosystems 
since Diffie-Hellman. But nothing more than that. It has been very 
difficult, for some cryptosystems to show that all instances of the 
problem are hard. For example, look at the case of RSA where we have 
small difference attacks (also called Fermat attacks, I believe), small 
exponent attacks, etcetera. Also, the knapsack example.

In case any advance in complexity should bring evidence that 
cryptosystems are insecure, and no practical attacks are presented, then 
the security of several cryptographic constructions should be revised. 
(Notice that algorithms used to prove that certain problems can be 
reduced to NP may not be efficient, and moreover, there may not exist an 
efficient reduction to a specific problem; e.g., therefore in these 
cases no efficient algorithm could be deduced directly from a proof that 
3SAT is in P.) If one polynomial algorithm for an NP-hard problem where 
presented, we'd need to analyze which cryptosystems and cryptographic 
arguments are threatened. But guessing seems futile.

As some of you noted, asymptotics and uniformity leave some open 
questions. And it would be a great step in crypto to provide a 
non-trivial lower bound for breaking a crypto system. In the case of 
RSA, for example, it would be great to prove that no algorithm can 
invert RSA in (parallel) time less than k^{20}, for k the security 
parameter. And knowing that, e.g., the result is valid for all reasonable k.

I believe that this is the biggest theoretical issue we face in crypto. 
There has been plenty of work on computational mathematics on lower 
bounds, even before public-key crypto existed, and yet lower-bounds are 
very hard to find. However, I am confident that there exists a 
public-key scheme which cannot be efficiently broken, though it might 
turn impractical (say, as compared to RSA and ECC). My guess, is that we 
will continue to use the same algorithms until practical attacks are 
presented )or deemed possible).

Regards,
Ariel


Jeff Williams wrote:
> All,
> 
>   A very interesting article. Some of you may have already read it...
> 
> See:
> http://www.technologyreview.com/articles/04/09/wo_garfinkel090104.asp
> 
> "The encryption algorithms that make virtually all electronic commerce
> possible work only because certain mathematical problems are very,
> very hard to solve. But some mathematicians are trying to prove that
> there's really no difference between 'hard' and 'not hard'
> problems--known
> in the math biz as P and NP. In an article on TechnologyReview.com,
> Simson Garfinkel spells out the real-world consequences of this
> mathematical conundrum."
> 
> Regards,
> 
> --
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
> "Be precise in the use of words and expect precision from others" -
>     Pierre Abelard
> 
> "If the probability be called P; the injury, L; and the burden, B;
> liability depends upon whether B is less than L multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> ===============================================================
> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> IDNS. div. of Information Network Eng.  INEG. INC.
> E-Mail jwkckid1@ix.netcom.com
>  Registered Email addr with the USPS
> Contact Number: 214-244-4827
> 
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 
From raeburn@MIT.EDU Wed Oct 27 21:48:14 2004
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU
	[18.7.7.80])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9S1mD6A027789
	for <saag@jis.mit.edu>; Wed, 27 Oct 2004 21:48:13 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	i9S1mD3k027253
	for <saag@mit.edu>; Wed, 27 Oct 2004 21:48:13 -0400 (EDT)
Received: from [18.101.0.226] ([18.101.0.226])
	(authenticated bits=0)
        (User authenticated as raeburn@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id i9S1mB1U016191
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
	for <saag@mit.edu>; Wed, 27 Oct 2004 21:48:12 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <6.1.2.0.2.20041027162204.04d4b0b0@mail.binhost.com>
References: <6.1.2.0.2.20041027162204.04d4b0b0@mail.binhost.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6CC708AA-2883-11D9-B5AB-000A95909EE2@mit.edu>
Content-Transfer-Encoding: 7bit
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [saag] Fwd: Counter-Spam
Date: Wed, 27 Oct 2004 21:48:11 -0400
To: saag@mit.edu
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.620404
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 28 Oct 2004 01:48:15 -0000

>     A hardware-based alternative to the Sender-ID specification has 
> been developed and patented. It is software independent. Thus, it is 
> not vulnerable to cyberattack. The technology is described in the 
> attachment TN006. Additional information is available, if there is 
> interest.

Ah, yes, preventing spam and email viruses by only accepting mail from 
systems that have also bought the patented encrypting hardware frob.  
Sounds like a good way to rake in the bucks if they can convince 
everyone in the world to buy into it.

Not much discussion of (a) how you prevent spammers from getting these 
devices in the same way that nonspammers get them, (b) how it would 
prevent a virus from attaching a copy of itself to an 
otherwise-legitimate message that really is being sent by the user, (c) 
whether it avoids one authorized session to the mail server for 
legitimate traffic from also being used to send spam/virus messages to 
other recipients over the same SMTP session, (d) patent licensing 
issues, (e) key administration on the large scale such as between 
random ISPs and companies (global PKI?), (f) bandwidth capabilities of 
the device, (g) compatible software implementations (which would of 
course be a bit less resistant to virus attack but should be "good 
enough" for a well-secured server just looking to reduce incoming 
spam), (h) server-to-server communications when no one is available to 
enter pass codes fast enough, (i) how expensive these devices are, (j) 
whether the user gets to review some information about the message 
being sent before authorizing the connection, (k) how it would cope 
with having several messages queued for sending when a network 
connection is re-established, (l) etc.

*yawn*

Sounds to me like they're selling a product to keep a small collection 
of hosts spam-free and virus-free, so long as they don't worry too much 
about being able to interact with the rest of the world.

Ken

From mouse@Sparkle.Rodents.Montreal.QC.CA Wed Oct 27 22:05:43 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9S25g6A028144
	for <saag@jis.mit.edu>; Wed, 27 Oct 2004 22:05:43 -0400 (EDT)
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA
	[216.46.5.7])i9S25fxW025328
	for <saag@mit.edu>; Wed, 27 Oct 2004 22:05:41 -0400 (EDT)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id WAA29306;
	Wed, 27 Oct 2004 22:05:38 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200410280205.WAA29306@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be
	part of it anyway.
Date: Wed, 27 Oct 2004 21:37:46 -0400 (EDT)
To: cfrg@ietf.org, saag@mit.edu
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
In-Reply-To: <20040926195031.59299.qmail@cr.yp.to>
References: 
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
	<20040926195031.59299.qmail@cr.yp.to>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.579544
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 28 Oct 2004 02:05:44 -0000

> A note to everyone using HMAC: Modern polynomial-evaluation MACs
> (such as GCM MAC) offer strong security guarantees (they're provably
> as secure as AES)

I'm not sure what this statement even _means_.  Block ciphers and MACs
have such drastically different security desires that it's not clear
how to perform the sort of comparison "as secure as" implies.  In
particular, each has some ways of being broken the other doesn't.

For that matter, what's "GCM MAC"?  Googling for it finds exactly two
hits: one is the message I'm responding to, the other is something in
some Latin tongue (Portugese? it's a .br host) and it looks like a
false positive to me - I for one find it hard to implement something
without any reference on it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
From ekr@rtfm.com Wed Oct 27 22:34:01 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9S2Xx6A028713
	for <saag@jis.mit.edu>; Wed, 27 Oct 2004 22:34:00 -0400 (EDT)
Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251])
	i9S2XaxW025471
	for <saag@mit.edu>; Wed, 27 Oct 2004 22:33:37 -0400 (EDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242])
	by sierra.rtfm.com (Postfix) with ESMTP
	id BB01A71D8; Wed, 27 Oct 2004 19:52:16 -0700 (PDT)
Received: by romeo.rtfm.com (Postfix, from userid 556)
	id 249C344AE7; Wed, 27 Oct 2004 19:33:35 -0700 (PDT)
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
References: <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
	<20040926195031.59299.qmail@cr.yp.to>
	<200410280205.WAA29306@Sparkle.Rodents.Montreal.QC.CA>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 27 Oct 2004 19:33:34 -0700
In-Reply-To: <200410280205.WAA29306@Sparkle.Rodents.Montreal.QC.CA> (der
 Mouse's message of "Wed, 27 Oct 2004 21:37:46 -0400 (EDT)")
Message-ID: <kjoeinh8qp.fsf@romeo.rtfm.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.587392
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: EKR <ekr@rtfm.com>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 28 Oct 2004 02:34:01 -0000

der Mouse <mouse@Rodents.Montreal.QC.CA> writes:

>> A note to everyone using HMAC: Modern polynomial-evaluation MACs
>> (such as GCM MAC) offer strong security guarantees (they're provably
>> as secure as AES)
>
> I'm not sure what this statement even _means_.  Block ciphers and MACs
> have such drastically different security desires that it's not clear
> how to perform the sort of comparison "as secure as" implies.  In
> particular, each has some ways of being broken the other doesn't.

How convenient you asked. 

Basically, you build a hash algorithm (or MAC) out of an encryption
algorithm. You can then demonstrate that the MAC/Hash is secure if the
encryption algorithm has a bunch of (somewhat idealized) properties.
Typically this is done by a reduction--showing that if you could break
the construction you could break the underlying encryption algorithm.

You might check out Tom Shrimpton's presentation on building
digests out of block ciphers from the recent DIMACS workshop. 

http://dimacs.rutgers.edu/Workshops/Practice/slides/shrimpton.ppt

As a side note, Tom makes the interesting point that the core of 
modern hash functions is basically a block cipher.

-Ekr


From raeburn@MIT.EDU Wed Oct 27 22:35:08 2004
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU
	[18.7.7.80])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9S2Z86A028760
	for <saag@jis.mit.edu>; Wed, 27 Oct 2004 22:35:08 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	i9S2Xd3k009837;	Wed, 27 Oct 2004 22:33:42 -0400 (EDT)
Received: from [18.101.0.226] ([18.101.0.226])
	(authenticated bits=0)
        (User authenticated as raeburn@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id i9S2Xb1U020635
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Wed, 27 Oct 2004 22:33:38 -0400 (EDT)
In-Reply-To: <200410280205.WAA29306@Sparkle.Rodents.Montreal.QC.CA>
References:
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
	<20040926195031.59299.qmail@cr.yp.to>
	<200410280205.WAA29306@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C517EF85-2889-11D9-B5AB-000A95909EE2@mit.edu>
Content-Transfer-Encoding: 7bit
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
Date: Wed, 27 Oct 2004 22:33:36 -0400
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000096
Spam-Alum-Time: 0.537944
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 28 Oct 2004 02:35:09 -0000

On Oct 27, 2004, at 21:37, der Mouse wrote:
> For that matter, what's "GCM MAC"?

I assumed it was Galois/Counter Mode, used as a MAC (i.e., no data to 
encrypt).
http://www.cryptobarn.com/papers/gcm-spec.pdf

Ken

From djb-dsn-1098932275.69942@cr.yp.to Wed Oct 27 22:57:32 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9S2vV6A029278
	for <saag@jis.mit.edu>; Wed, 27 Oct 2004 22:57:31 -0400 (EDT)
Received: from stoneport.math.uic.edu (stoneport.math.uic.edu
	[131.193.178.160])i9S2vULA012082
	for <saag@mit.edu>; Wed, 27 Oct 2004 22:57:30 -0400 (EDT)
Received: (qmail 69943 invoked by uid 1016); 28 Oct 2004 02:57:55 -0000
Date: 28 Oct 2004 02:57:55 -0000
Message-ID: <20041028025755.69942.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@ietf.org, saag@mit.edu
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
References:
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
	<20040926195031.59299.qmail@cr.yp.to>
	<200410280205.WAA29306@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 1.027988
X-Mailman-Approved-At: Wed, 27 Oct 2004 23:13:40 -0400
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 28 Oct 2004 02:57:33 -0000

der Mouse writes:
> I'm not sure what this statement even _means_.

Any message-forgery attack against a polynomial-evaluation MAC using AES
can be turned into a comparably fast algorithm to predict AES, i.e., to
distinguish AES from a uniform random permutation. AES was explicitly
designed to be indistinguishable from a uniform random permutation.

See, e.g., Rogaway, ``Bucket hashing and its application to fast message
authentication,'' J. Cryptology 12 (1999), 91-115, Proposition 14; or my
new paper http://cr.yp.to/papers.html#securitywcs, particularly Theorem
5.4; or http://www.google.com/search?as_q=wegman+carter+authentication.

Are MACs, message-encryption functions, etc. different objects from
block ciphers? Of course. Are there separate definitions of breaking a
MAC, breaking a message-encryption function, and breaking AES? Yes. But
that doesn't stop us from proving that breaking various AES-based MACs
implies breaking AES, that breaking counter-mode AES implies breaking
AES, etc.

> For that matter, what's "GCM MAC"?

http://eprint.iacr.org/2004/193/

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
From mcgrew@cisco.com Thu Oct 28 07:51:38 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9SBpb6A010812
	for <saag@jis.mit.edu>; Thu, 28 Oct 2004 07:51:37 -0400 (EDT)
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71])
	i9SBpXY6026927
	for <saag@mit.edu>; Thu, 28 Oct 2004 07:51:33 -0400 (EDT)
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 28 Oct 2004 05:00:48 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
	[171.71.163.14])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9SBodYJ002724;
	Thu, 28 Oct 2004 04:50:39 -0700 (PDT)
Received: from [10.32.254.214] (stealth-10-32-254-214.cisco.com
	[10.32.254.214])	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with SMTP id AYL99949;	Thu, 28 Oct 2004 04:53:41 -0700 (PDT)
In-Reply-To: <20040926195031.59299.qmail@cr.yp.to>
References:
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
	<20040926195031.59299.qmail@cr.yp.to>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B382BA62-28D7-11D9-8709-0003935495EC@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <mcgrew@cisco.com>
Subject: universal MACs [was: Re: [Cfrg] Re: [saag] Bad day at the hash
	function factory]
Date: Thu, 28 Oct 2004 04:51:27 -0700
To: "D. J. Bernstein" <djb@cr.yp.to>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.596736
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 28 Oct 2004 11:51:38 -0000

Dan,

On Sep 26, 2004, at 12:50 PM, D. J. Bernstein wrote:

> A note to everyone using HMAC: Modern polynomial-evaluation MACs (such
> as GCM MAC) offer strong security guarantees (they're provably as 
> secure
> as AES) and are faster than HMAC-SHA1.

yes, thanks for pointing this out.  It would be worth having a 
discussion on universal hash based message authentication on the CFRG 
list.  (We should probably start a new thread for it too, so I've done 
that.)  I know that several others in CFRG are interested in this sort 
of work.  They'd probably also be interested in your recent 
announcement on `Stronger security bounds for Wegman-Carter-Shoup 
authenticators'', http://cr.yp.to/papers.html#securitywcs.


> Some of them (not GCM MAC) are
> even faster than HMAC-MD5.

Do you mean "in software" here?  As you know, the design target for GCM 
was high-speed authenticated encryption.  Unlike much of the work that 
uses universal hashing, GCM aims to be implementable in hardware as 
well as software.

Some other hashes, like UMAC and hash127, are better in software.  It 
would be great if CFRG could produce a specification for one or more of 
these functions.  It should not be hard to get some others to verify 
the test vectors.    I suspect that the group preference would be 
towards hash functions that are portable (e.g. fast on a wide variety 
of CPUs) and that require minimal per-key state.  There may be other 
points of view; others please chime in if you have other priorities.

David

>
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>

From rja@extremenetworks.com Thu Oct 28 08:49:22 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9SCnL6A012135
	for <saag@jis.mit.edu>; Thu, 28 Oct 2004 08:49:21 -0400 (EDT)
Received: from smtp1.extremenetworks.com (smtp1.extremenetworks.com
	[216.52.8.6])i9SCnHY6013727
	for <saag@mit.edu>; Thu, 28 Oct 2004 08:49:18 -0400 (EDT)
Received: from [10.30.20.60] (unknown [10.30.20.60])
	by smtp1.extremenetworks.com (Postfix) with ESMTP
	id E55357946; Thu, 28 Oct 2004 05:49:15 -0700 (PDT)
In-Reply-To: <B382BA62-28D7-11D9-8709-0003935495EC@cisco.com>
References:
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
	<20040926195031.59299.qmail@cr.yp.to>
	<B382BA62-28D7-11D9-8709-0003935495EC@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <CA3957C9-28DF-11D9-A562-000D93B505E6@extremenetworks.com>
Content-Transfer-Encoding: 7bit
From: RJ Atkinson <rja@extremenetworks.com>
Date: Thu, 28 Oct 2004 08:49:21 -0400
To: "David A. McGrew" <mcgrew@cisco.com>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.705840
cc: cfrg@ietf.org
cc: saag@mit.edu
Subject: [saag] Re: universal MACs 
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 28 Oct 2004 12:49:22 -0000

David,

My protocol preference in an IETF context is for algorithm-independent 
protocols,
so that one does not need to change the protocol to add support for 
additional
algorithms in future.  This property holds for at least OSPFv2 
authentication and
RIPv2 authentication (and yes, I am working on documentation updates to 
each
of those specifications to document how SHA-1 and its relatives are 
implemented).

My algorithm preference in an IETF context is for algorithms that are 
acceptable
to the largest number of end users.  Right now, many governments (from 
multiple
governments, including several in Europe and several in Asia, NOT just 
the US)
and many non-governmental customers are insisting upon the same 
algorithm set,
which is the set of currently NIST-approved algorithms and modes.  This 
set of
algorithms appears to be the preferred set of algorithms and modes 
right now --
by a VERY wide margin.

In practice, that means there is a strong buyer preference from many 
countries
for SHA-1 (and its NIST-documented relatives) and for AES (in 
NIST-acceptable
modes).  Several countries, including several in Europe and several in 
Asia, are
also insisting that cryptographic products they buy have NIST FIPS 
140-2 approvals.
This also tends to reinforce the selection of algorithms and modes 
since only the
NIST-approved algorithms and modes can get a FIPS 140-2 approval.

I would even suggest that for the moment, any new security protocols 
developed
in an IETF context ought to include documentation on how NIST-approved 
algorithms
and modes are used with those protocols -- even if the IETF were to 
decide that
it preferred some non-NIST algorithm or mode for a particular security 
protocol
as the "default" algorithm/mode choice.

Yours,

Ran Atkinson
rja@extremenetworks.com

PS:  Nitpickers should please note well that all of my comments above 
are about
the end-user/marketplace desires, and there is no comment above about 
the quality
of any particular algorithm or mode.


On Oct 28, 2004, at 07:51, David A. McGrew wrote:
>     I suspect that the group preference would be towards hash 
> functions that are portable (e.g. fast on a wide variety of CPUs) and 
> that require minimal per-key state.  There may be other points of 
> view; others please chime in if you have other priorities.
>
> David

From steve@stevecrocker.com Thu Oct 28 14:46:52 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9SIkm6A021787
	for <saag@jis.mit.edu>; Thu, 28 Oct 2004 14:46:52 -0400 (EDT)
Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238])
	i9SIkiji005104
	for <saag@mit.edu>; Thu, 28 Oct 2004 14:46:47 -0400 (EDT)
Received: from [66.93.106.226] (HELO SCROCKER)
  by EXECDSL.COM (CommuniGate Pro SMTP 3.3)
  with ESMTP id 7836420; Thu, 28 Oct 2004 14:46:44 -0400
From: "Steve Crocker" <steve@stevecrocker.com>
To: <cfrg@ietf.org>, <saag@mit.edu>
Date: Thu, 28 Oct 2004 14:46:39 -0400
Message-ID: <003501c4bd1e$75c3a0c0$0302000a@SCROCKER>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <CA3957C9-28DF-11D9-A562-000D93B505E6@extremenetworks.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200
Importance: Normal
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.641448
Subject: [saag] Algorithm upgrades
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 28 Oct 2004 18:46:53 -0000

No matter what algorithms we choose today, it's likely that changes will
be required in the future.  Let me strengthen Ran's suggestion.  In
addition to building algorithm-independent protocols, the protocols
should also include an upgrade mechanism for changing algorithms in an
orderly way.  It's not good enough to say protocol FOO is independent of
algorithm if all of the initial deployment depends on crypto algorithm
SNARF and there's no way to introduce new crypto algorithm FARNS without
breaking interoperability.

Steve

> -----Original Message-----
> From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On 
> Behalf Of RJ Atkinson
> Sent: Thursday, October 28, 2004 8:49 AM
> To: David A. McGrew
> Cc: cfrg@ietf.org; saag@mit.edu
> Subject: [saag] Re: universal MACs 
> 
> 
> David,
> 
> My protocol preference in an IETF context is for 
> algorithm-independent 
> protocols,
> so that one does not need to change the protocol to add support for 
> additional
> algorithms in future.  This property holds for at least OSPFv2 
> authentication and
> RIPv2 authentication (and yes, I am working on documentation 
> updates to 
> each
> of those specifications to document how SHA-1 and its relatives are 
> implemented).
> 
> My algorithm preference in an IETF context is for algorithms that are 
> acceptable
> to the largest number of end users.  Right now, many 
> governments (from 
> multiple
> governments, including several in Europe and several in Asia, 
> NOT just 
> the US)
> and many non-governmental customers are insisting upon the same 
> algorithm set,
> which is the set of currently NIST-approved algorithms and 
> modes.  This 
> set of
> algorithms appears to be the preferred set of algorithms and modes 
> right now --
> by a VERY wide margin.
> 
> In practice, that means there is a strong buyer preference from many 
> countries
> for SHA-1 (and its NIST-documented relatives) and for AES (in 
> NIST-acceptable
> modes).  Several countries, including several in Europe and 
> several in 
> Asia, are
> also insisting that cryptographic products they buy have NIST FIPS 
> 140-2 approvals.
> This also tends to reinforce the selection of algorithms and modes 
> since only the
> NIST-approved algorithms and modes can get a FIPS 140-2 approval.
> 
> I would even suggest that for the moment, any new security protocols 
> developed
> in an IETF context ought to include documentation on how 
> NIST-approved 
> algorithms
> and modes are used with those protocols -- even if the IETF were to 
> decide that
> it preferred some non-NIST algorithm or mode for a particular 
> security 
> protocol
> as the "default" algorithm/mode choice.
> 
> Yours,
> 
> Ran Atkinson
> rja@extremenetworks.com
> 
> PS:  Nitpickers should please note well that all of my comments above 
> are about
> the end-user/marketplace desires, and there is no comment above about 
> the quality
> of any particular algorithm or mode.
> 
> 
> On Oct 28, 2004, at 07:51, David A. McGrew wrote:
> >     I suspect that the group preference would be towards hash
> > functions that are portable (e.g. fast on a wide variety of 
> CPUs) and 
> > that require minimal per-key state.  There may be other points of 
> > view; others please chime in if you have other priorities.
> >
> > David
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 

From jwkckid1@ix.netcom.com Thu Oct 28 15:24:12 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9SJOB6A022688
	for <saag@jis.mit.edu>; Thu, 28 Oct 2004 15:24:11 -0400 (EDT)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	i9SJO7q6013172
	for <saag@mit.edu>; Thu, 28 Oct 2004 15:24:07 -0400 (EDT)
Received: from 1cust171.tnt59.dfw5.da.uu.net ([67.203.43.171]
	helo=ix.netcom.com)	by smtp6.mindspring.com with esmtp (Exim 3.33 #1)
	id 1CNFsB-0002cW-00; Thu, 28 Oct 2004 15:23:47 -0400
Message-ID: <41816316.E6CCF1E9@ix.netcom.com>
Date: Thu, 28 Oct 2004 14:22:34 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: Steve Crocker <steve@stevecrocker.com>
Subject: Re: [saag] Algorithm upgrades
References: <003501c4bd1e$75c3a0c0$0302000a@SCROCKER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.721108
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 28 Oct 2004 19:24:12 -0000

Steve and all,

  Again we disagree in your conclusion here Steve.  Of course we
have been over this ground before.  Changing or introducing new
crypto algorithm's in no way should impede or prevent interoerability
and interface facilities now available can and do address this issue.

Steve Crocker wrote:

> No matter what algorithms we choose today, it's likely that changes will
> be required in the future.  Let me strengthen Ran's suggestion.  In
> addition to building algorithm-independent protocols, the protocols
> should also include an upgrade mechanism for changing algorithms in an
> orderly way.  It's not good enough to say protocol FOO is independent of
> algorithm if all of the initial deployment depends on crypto algorithm
> SNARF and there's no way to introduce new crypto algorithm FARNS without
> breaking interoperability.
>
> Steve
>
> > -----Original Message-----
> > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On
> > Behalf Of RJ Atkinson
> > Sent: Thursday, October 28, 2004 8:49 AM
> > To: David A. McGrew
> > Cc: cfrg@ietf.org; saag@mit.edu
> > Subject: [saag] Re: universal MACs
> >
> >
> > David,
> >
> > My protocol preference in an IETF context is for
> > algorithm-independent
> > protocols,
> > so that one does not need to change the protocol to add support for
> > additional
> > algorithms in future.  This property holds for at least OSPFv2
> > authentication and
> > RIPv2 authentication (and yes, I am working on documentation
> > updates to
> > each
> > of those specifications to document how SHA-1 and its relatives are
> > implemented).
> >
> > My algorithm preference in an IETF context is for algorithms that are
> > acceptable
> > to the largest number of end users.  Right now, many
> > governments (from
> > multiple
> > governments, including several in Europe and several in Asia,
> > NOT just
> > the US)
> > and many non-governmental customers are insisting upon the same
> > algorithm set,
> > which is the set of currently NIST-approved algorithms and
> > modes.  This
> > set of
> > algorithms appears to be the preferred set of algorithms and modes
> > right now --
> > by a VERY wide margin.
> >
> > In practice, that means there is a strong buyer preference from many
> > countries
> > for SHA-1 (and its NIST-documented relatives) and for AES (in
> > NIST-acceptable
> > modes).  Several countries, including several in Europe and
> > several in
> > Asia, are
> > also insisting that cryptographic products they buy have NIST FIPS
> > 140-2 approvals.
> > This also tends to reinforce the selection of algorithms and modes
> > since only the
> > NIST-approved algorithms and modes can get a FIPS 140-2 approval.
> >
> > I would even suggest that for the moment, any new security protocols
> > developed
> > in an IETF context ought to include documentation on how
> > NIST-approved
> > algorithms
> > and modes are used with those protocols -- even if the IETF were to
> > decide that
> > it preferred some non-NIST algorithm or mode for a particular
> > security
> > protocol
> > as the "default" algorithm/mode choice.
> >
> > Yours,
> >
> > Ran Atkinson
> > rja@extremenetworks.com
> >
> > PS:  Nitpickers should please note well that all of my comments above
> > are about
> > the end-user/marketplace desires, and there is no comment above about
> > the quality
> > of any particular algorithm or mode.
> >
> >
> > On Oct 28, 2004, at 07:51, David A. McGrew wrote:
> > >     I suspect that the group preference would be towards hash
> > > functions that are portable (e.g. fast on a wide variety of
> > CPUs) and
> > > that require minimal per-key state.  There may be other points of
> > > view; others please chime in if you have other priorities.
> > >
> > > David
> >
> > _______________________________________________
> > saag mailing list
> > saag@mit.edu
> > https://jis.mit.edu/mailman/listinfo/saag
> >
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From alten@escalonnetworks.com Fri Oct 29 09:25:47 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9TDPk6A016570
	for <saag@jis.mit.edu>; Fri, 29 Oct 2004 09:25:46 -0400 (EDT)
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	i9TDNqxa020095
	for <saag@mit.edu>; Fri, 29 Oct 2004 09:23:53 -0400 (EDT)
Received: from alten.comcast.net
	(c-24-5-244-112.client.comcast.net[24.5.244.112])
	by comcast.net (rwcrmhc13) with SMTP
	id <20041029132348015007h3fme>          (Authid: a.alton);
	Fri, 29 Oct 2004 13:23:52 +0000
Message-Id: <4.3.2.7.1.20041029061644.035f7948@mail.comcast.net>
X-Sender: a.alton@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 29 Oct 2004 06:23:40 -0700
To: Jeff Williams <jwkckid1@ix.netcom.com>,
   Steve Crocker <steve@stevecrocker.com>
From: Alex Alten <alten@escalonnetworks.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
In-Reply-To: <41816316.E6CCF1E9@ix.netcom.com>
References: <003501c4bd1e$75c3a0c0$0302000a@SCROCKER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.716753
X-Mailman-Approved-At: Sun, 31 Oct 2004 01:36:27 -0400
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 29 Oct 2004 13:25:48 -0000

All,

Let me point out as an example that the automated teller machines (ATMs) 
security
protocol has been using the same algorithm with DES since about 1982.  Making
protocols algorithm independent (with extra handshakes and upgrade mechanisms)
has the side effect of making them very complex and thus harder to certify for
interoperability, optimize for performance, etc.

- Alex

At 02:22 PM 10/28/2004 -0700, Jeff Williams wrote:
>Steve and all,
>
>   Again we disagree in your conclusion here Steve.  Of course we
>have been over this ground before.  Changing or introducing new
>crypto algorithm's in no way should impede or prevent interoerability
>and interface facilities now available can and do address this issue.
>
>Steve Crocker wrote:
>
> > No matter what algorithms we choose today, it's likely that changes will
> > be required in the future.  Let me strengthen Ran's suggestion.  In
> > addition to building algorithm-independent protocols, the protocols
> > should also include an upgrade mechanism for changing algorithms in an
> > orderly way.  It's not good enough to say protocol FOO is independent of
> > algorithm if all of the initial deployment depends on crypto algorithm
> > SNARF and there's no way to introduce new crypto algorithm FARNS without
> > breaking interoperability.
> >
> > Steve
> >
> > > -----Original Message-----
> > > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On
> > > Behalf Of RJ Atkinson
> > > Sent: Thursday, October 28, 2004 8:49 AM
> > > To: David A. McGrew
> > > Cc: cfrg@ietf.org; saag@mit.edu
> > > Subject: [saag] Re: universal MACs
> > >
> > >
> > > David,
> > >
> > > My protocol preference in an IETF context is for
> > > algorithm-independent
> > > protocols,
> > > so that one does not need to change the protocol to add support for
> > > additional
> > > algorithms in future.  This property holds for at least OSPFv2
> > > authentication and
> > > RIPv2 authentication (and yes, I am working on documentation
> > > updates to
> > > each
> > > of those specifications to document how SHA-1 and its relatives are
> > > implemented).
> > >
> > > My algorithm preference in an IETF context is for algorithms that are
> > > acceptable
> > > to the largest number of end users.  Right now, many
> > > governments (from
> > > multiple
> > > governments, including several in Europe and several in Asia,
> > > NOT just
> > > the US)
> > > and many non-governmental customers are insisting upon the same
> > > algorithm set,
> > > which is the set of currently NIST-approved algorithms and
> > > modes.  This
> > > set of
> > > algorithms appears to be the preferred set of algorithms and modes
> > > right now --
> > > by a VERY wide margin.
> > >
> > > In practice, that means there is a strong buyer preference from many
> > > countries
> > > for SHA-1 (and its NIST-documented relatives) and for AES (in
> > > NIST-acceptable
> > > modes).  Several countries, including several in Europe and
> > > several in
> > > Asia, are
> > > also insisting that cryptographic products they buy have NIST FIPS
> > > 140-2 approvals.
> > > This also tends to reinforce the selection of algorithms and modes
> > > since only the
> > > NIST-approved algorithms and modes can get a FIPS 140-2 approval.
> > >
> > > I would even suggest that for the moment, any new security protocols
> > > developed
> > > in an IETF context ought to include documentation on how
> > > NIST-approved
> > > algorithms
> > > and modes are used with those protocols -- even if the IETF were to
> > > decide that
> > > it preferred some non-NIST algorithm or mode for a particular
> > > security
> > > protocol
> > > as the "default" algorithm/mode choice.
> > >
> > > Yours,
> > >
> > > Ran Atkinson
> > > rja@extremenetworks.com
> > >
> > > PS:  Nitpickers should please note well that all of my comments above
> > > are about
> > > the end-user/marketplace desires, and there is no comment above about
> > > the quality
> > > of any particular algorithm or mode.
> > >
> > >
> > > On Oct 28, 2004, at 07:51, David A. McGrew wrote:
> > > >     I suspect that the group preference would be towards hash
> > > > functions that are portable (e.g. fast on a wide variety of
> > > CPUs) and
> > > > that require minimal per-key state.  There may be other points of
> > > > view; others please chime in if you have other priorities.
> > > >
> > > > David
> > >
> > > _______________________________________________
> > > saag mailing list
> > > saag@mit.edu
> > > https://jis.mit.edu/mailman/listinfo/saag
> > >
> >
> > _______________________________________________
> > saag mailing list
> > saag@mit.edu
> > https://jis.mit.edu/mailman/listinfo/saag
>
>Regards,
>
>--
>Jeffrey A. Williams
>Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
>"Be precise in the use of words and expect precision from others" -
>     Pierre Abelard
>
>"If the probability be called P; the injury, L; and the burden, B;
>liability depends upon whether B is less than L multiplied by
>P: i.e., whether B is less than PL."
>United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
>===============================================================
>Updated 1/26/04
>CSO/DIR. Internet Network Eng. SR. Eng. Network data security
>IDNS. div. of Information Network Eng.  INEG. INC.
>E-Mail jwkckid1@ix.netcom.com
>  Registered Email addr with the USPS
>Contact Number: 214-244-4827
>
>
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@ietf.org
>https://www1.ietf.org/mailman/listinfo/cfrg

--

Alex Alten
alten@EscalonNetworks.com
(925) 425-9600

From rja@extremenetworks.com Sun Oct 31 09:24:41 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id i9VEOe6A022531
	for <saag@jis.mit.edu>; Sun, 31 Oct 2004 09:24:40 -0500 (EST)
Received: from smtp1.extremenetworks.com (smtp1.extremenetworks.com
	[216.52.8.6])i9VEOcii004735
	for <saag@mit.edu>; Sun, 31 Oct 2004 09:24:38 -0500 (EST)
Received: from [10.30.20.60] (unknown [10.30.20.60])
	by smtp1.extremenetworks.com (Postfix) with ESMTP
	id 13EF87945; Sun, 31 Oct 2004 06:24:36 -0800 (PST)
In-Reply-To: <4.3.2.7.1.20041029061644.035f7948@mail.comcast.net>
References: <003501c4bd1e$75c3a0c0$0302000a@SCROCKER>
	<4.3.2.7.1.20041029061644.035f7948@mail.comcast.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9B270C7E-2B48-11D9-8B60-000D93B505E6@extremenetworks.com>
Content-Transfer-Encoding: 7bit
From: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Date: Sun, 31 Oct 2004 09:24:42 -0500
To: Alex Alten <alten@escalonnetworks.com>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.535945
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 31 Oct 2004 14:24:41 -0000


On Oct 29, 2004, at 09:23, Alex Alten wrote:
> Let me point out as an example that the automated teller machines 
> (ATMs) security
> protocol has been using the same algorithm with DES since about 1982.  
> Making
> protocols algorithm independent (with extra handshakes and upgrade 
> mechanisms)
> has the side effect of making them very complex and thus harder to 
> certify for
> interoperability, optimize for performance, etc.
>
> - Alex

I am not at all persuaded that making protocols algorithm-independent 
necessarily
has the side effect of making them more complex or harder to certify or 
harder to
performance optimise.  I've seen a lot of protocols that were not 
algorithm-independent
that *were* astonishingly complex, so the inverse is also not obvious 
to me.

Ran
rja@extremenetworks.com

From jwkckid1@ix.netcom.com Sun Oct 31 21:33:26 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA12XK6A013475
	for <saag@jis.mit.edu>; Sun, 31 Oct 2004 21:33:20 -0500 (EST)
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net
	[207.69.200.246])iA12XJIY008396
	for <saag@mit.edu>; Sun, 31 Oct 2004 21:33:19 -0500 (EST)
Received: from 1cust66.tnt36.dfw9.da.uu.net ([67.234.81.66]
	helo=ix.netcom.com)
	by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1)
	id 1COS0P-0001Td-00; Sun, 31 Oct 2004 21:33:14 -0500
Message-ID: <4185BC36.142F0142@ix.netcom.com>
Date: Sun, 31 Oct 2004 20:31:52 -0800
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References: <003501c4bd1e$75c3a0c0$0302000a@SCROCKER>
	<4.3.2.7.1.20041029061644.035f7948@mail.comcast.net>
	<9B270C7E-2B48-11D9-8B60-000D93B505E6@extremenetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.621551
cc: cfrg@ietf.org
cc: Alex Alten <alten@escalonnetworks.com>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 01 Nov 2004 02:33:27 -0000

RJ and all,

RJ Atkinson wrote:

> On Oct 29, 2004, at 09:23, Alex Alten wrote:
> > Let me point out as an example that the automated teller machines
> > (ATMs) security
> > protocol has been using the same algorithm with DES since about 1982.
> > Making
> > protocols algorithm independent (with extra handshakes and upgrade
> > mechanisms)
> > has the side effect of making them very complex and thus harder to
> > certify for
> > interoperability, optimize for performance, etc.
> >
> > - Alex
>
> I am not at all persuaded that making protocols algorithm-independent
> necessarily
> has the side effect of making them more complex or harder to certify or
> harder to
> performance optimise.  I've seen a lot of protocols that were not
> algorithm-independent
> that *were* astonishingly complex, so the inverse is also not obvious
> to me.

  We have similar experiences it seems.  So I entirely agree with you
here.  And as such, why I still believe that interface facilities for
multi-algorithm's is a far better approach.  But convincing
Steve and others on this seems to be improbable even though
such is being done and has been for several years.  Perhaps this
"Dates" Steve and those of his mindset.

>
>
> Ran
> rja@extremenetworks.com

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From djb-dsn-1099290484.56140@cr.yp.to Mon Nov  1 01:27:42 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA16Rf6A022077
	for <saag@jis.mit.edu>; Mon, 1 Nov 2004 01:27:41 -0500 (EST)
Received: from stoneport.math.uic.edu (stoneport.math.uic.edu
	[131.193.178.160])iA16RdFc019714
	for <saag@mit.edu>; Mon, 1 Nov 2004 01:27:39 -0500 (EST)
Received: (qmail 56141 invoked by uid 1016); 1 Nov 2004 06:28:04 -0000
Date: 1 Nov 2004 06:28:04 -0000
Message-ID: <20041101062804.56140.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: saag@mit.edu, cfrg@ietf.org
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
References:
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
	<20040926195031.59299.qmail@cr.yp.to>
	<200410280205.WAA29306@Sparkle.Rodents.Montreal.QC.CA>
	<kjoeinh8qp.fsf@romeo.rtfm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000001
Spam-Alum-Time: 0.537027
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 01 Nov 2004 06:27:42 -0000

Eric Rescorla writes:
> You can then demonstrate that the MAC/Hash is secure if the
> encryption algorithm has a bunch of (somewhat idealized) properties.

There's just one assumption needed for these proofs: namely, someone who
doesn't know the key k can't distinguish AES_k from a uniform random
permutation of the set of 16-byte strings. This was an explicit design
criterion for AES.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
From ekr@rtfm.com Mon Nov  1 08:05:51 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA1D5o6A002615
	for <saag@jis.mit.edu>; Mon, 1 Nov 2004 08:05:50 -0500 (EST)
Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251])
	iA1D5mf4023211
	for <saag@mit.edu>; Mon, 1 Nov 2004 08:05:49 -0500 (EST)
Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242])
	by sierra.rtfm.com (Postfix) with ESMTP
	id 6E27E7154; Mon,  1 Nov 2004 05:24:36 -0800 (PST)
Received: by romeo.rtfm.com (Postfix, from userid 556)
	id 1ECF744AE7; Mon,  1 Nov 2004 05:05:48 -0800 (PST)
To: "D. J. Bernstein" <djb@cr.yp.to>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
References: <151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
	<20040926195031.59299.qmail@cr.yp.to>
	<200410280205.WAA29306@Sparkle.Rodents.Montreal.QC.CA>
	<kjoeinh8qp.fsf@romeo.rtfm.com> <20041101062804.56140.qmail@cr.yp.to>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 01 Nov 2004 05:05:47 -0800
In-Reply-To: <20041101062804.56140.qmail@cr.yp.to> (D. J. Bernstein's
 message of "1 Nov 2004 06:28:04 -0000")
Message-ID: <kjbrehg1n8.fsf@romeo.rtfm.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.544877
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: EKR <ekr@rtfm.com>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 01 Nov 2004 13:05:52 -0000

"D. J. Bernstein" <djb@cr.yp.to> writes:

> Eric Rescorla writes:
>> You can then demonstrate that the MAC/Hash is secure if the
>> encryption algorithm has a bunch of (somewhat idealized) properties.
>
> There's just one assumption needed for these proofs: namely, someone who
> doesn't know the key k can't distinguish AES_k from a uniform random
> permutation of the set of 16-byte strings. This was an explicit design
> criterion for AES.

Hmm... I think this differs between MACs and hashes. 

My reading of [Simon02] is that the PRP assumption is insufficient for
proving that a digest construction is secure.

-Ekr
From rja@extremenetworks.com Mon Nov  1 08:15:53 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA1DFq6A002998
	for <saag@jis.mit.edu>; Mon, 1 Nov 2004 08:15:52 -0500 (EST)
Received: from smtp1.extremenetworks.com (smtp1.extremenetworks.com
	[216.52.8.6])iA1DFpf4002139
	for <saag@mit.edu>; Mon, 1 Nov 2004 08:15:51 -0500 (EST)
Received: from [10.30.20.60] (unknown [10.30.20.60])
	by smtp1.extremenetworks.com (Postfix) with ESMTP
	id 172947946; Mon,  1 Nov 2004 05:15:46 -0800 (PST)
In-Reply-To: <4185BC36.142F0142@ix.netcom.com>
References: <003501c4bd1e$75c3a0c0$0302000a@SCROCKER>
	<4.3.2.7.1.20041029061644.035f7948@mail.comcast.net>
	<9B270C7E-2B48-11D9-8B60-000D93B505E6@extremenetworks.com>
	<4185BC36.142F0142@ix.netcom.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <280DB916-2C08-11D9-84C0-000D93B505E6@extremenetworks.com>
Content-Transfer-Encoding: 7bit
From: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Date: Mon, 1 Nov 2004 08:15:52 -0500
To: Jeff Williams <jwkckid1@ix.netcom.com>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.551918
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 01 Nov 2004 13:15:54 -0000


On Oct 31, 2004, at 23:31, Jeff Williams wrote:
>   We have similar experiences it seems.  So I entirely agree with you
> here.  And as such, why I still believe that interface facilities for
> multi-algorithm's is a far better approach.  But convincing
> Steve and others on this seems to be improbable even though
> such is being done and has been for several years.  Perhaps this
> "Dates" Steve and those of his mindset.

Jeff,

	Perhaps you might not have read my words carefully enough.
I fully agree with Steve Crocker.  And I am utterly bafffled as to how
anyone could misread my written words as disagreeing with Steve Crocker.

Yours,

Ran
rja@extremenetworks.com

From mcgrew@cisco.com Mon Nov  1 09:13:05 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA1ED26A005340
	for <saag@jis.mit.edu>; Mon, 1 Nov 2004 09:13:02 -0500 (EST)
Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70])
	iA1ED0De018089
	for <saag@mit.edu>; Mon, 1 Nov 2004 09:13:00 -0500 (EST)
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-1.cisco.com with ESMTP; 01 Nov 2004 06:25:18 -0800
X-BrightmailFiltered: true
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com
	[171.71.163.14])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA1ECnom007988;
	Mon, 1 Nov 2004 06:12:53 -0800 (PST)
Received: from [10.32.254.210] ([10.32.254.210])
	by mira-sjc5-b.cisco.com (MOS 3.4.5-GR)
	with SMTP id AYO57141;
	Mon, 1 Nov 2004 06:15:40 -0800 (PST)
In-Reply-To: <4.3.2.7.1.20041029061644.035f7948@mail.comcast.net>
References: <003501c4bd1e$75c3a0c0$0302000a@SCROCKER>
	<4.3.2.7.1.20041029061644.035f7948@mail.comcast.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <1B25E69C-2C10-11D9-A7FD-0003935495EC@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Date: Mon, 1 Nov 2004 06:12:47 -0800
To: Alex Alten <alten@escalonnetworks.com>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.765904
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 01 Nov 2004 14:13:06 -0000

Alex,

On Oct 29, 2004, at 6:23 AM, Alex Alten wrote:

> All,
>
> Let me point out as an example that the automated teller machines 
> (ATMs) security
> protocol has been using the same algorithm with DES since about 1982.  
> Making
> protocols algorithm independent (with extra handshakes and upgrade 
> mechanisms)
> has the side effect of making them very complex and thus harder to 
> certify for
> interoperability, optimize for performance, etc.

I respectfully disagree.  Modern systems and protocols need to have the 
ability to utilize different crypto algorithms.  Otherwise, how can a 
deficient algorithm be replaced?  Consider the complexity of taking a 
legacy system in which the algorithms have been hard-wired and then 
trying to remove a deficient algorithm and replace it with a better 
one.

OTOH, I do think that we could do a better job of making the crypto 
easy to upgrade.  If there were a well defined, clean and simple 
interface to the crypto functions, and crypto functions were defined to 
match that interface, adoption would be easier.  One research paper 
that goes in this direction (but does not formally define an interface) 
is: Mihir Bellare and Tadayoshi Kohno and Chanathip Namprempre, 
Breaking and Provably Repairing the SSH Authenticated Encryption 
Scheme: A Case Study of the Encode-then-Encrypt-and-MAC Paradigm, To 
appear in ACM Transactions on Information and System Security, ACM, 
2004. An extended abstract of this paper appeared in Ninth ACM 
Conference on Computer and Communications Security, ACM, 2002. 
http://eprint.iacr.org/2002/078/

David

>
> - Alex
>
> At 02:22 PM 10/28/2004 -0700, Jeff Williams wrote:
>> Steve and all,
>>
>>   Again we disagree in your conclusion here Steve.  Of course we
>> have been over this ground before.  Changing or introducing new
>> crypto algorithm's in no way should impede or prevent interoerability
>> and interface facilities now available can and do address this issue.
>>
>> Steve Crocker wrote:
>>
>> > No matter what algorithms we choose today, it's likely that changes 
>> will
>> > be required in the future.  Let me strengthen Ran's suggestion.  In
>> > addition to building algorithm-independent protocols, the protocols
>> > should also include an upgrade mechanism for changing algorithms in 
>> an
>> > orderly way.  It's not good enough to say protocol FOO is 
>> independent of
>> > algorithm if all of the initial deployment depends on crypto 
>> algorithm
>> > SNARF and there's no way to introduce new crypto algorithm FARNS 
>> without
>> > breaking interoperability.
>> >
>> > Steve
>> >
>> > > -----Original Message-----
>> > > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On
>> > > Behalf Of RJ Atkinson
>> > > Sent: Thursday, October 28, 2004 8:49 AM
>> > > To: David A. McGrew
>> > > Cc: cfrg@ietf.org; saag@mit.edu
>> > > Subject: [saag] Re: universal MACs
>> > >
>> > >
>> > > David,
>> > >
>> > > My protocol preference in an IETF context is for
>> > > algorithm-independent
>> > > protocols,
>> > > so that one does not need to change the protocol to add support 
>> for
>> > > additional
>> > > algorithms in future.  This property holds for at least OSPFv2
>> > > authentication and
>> > > RIPv2 authentication (and yes, I am working on documentation
>> > > updates to
>> > > each
>> > > of those specifications to document how SHA-1 and its relatives 
>> are
>> > > implemented).
>> > >
>> > > My algorithm preference in an IETF context is for algorithms that 
>> are
>> > > acceptable
>> > > to the largest number of end users.  Right now, many
>> > > governments (from
>> > > multiple
>> > > governments, including several in Europe and several in Asia,
>> > > NOT just
>> > > the US)
>> > > and many non-governmental customers are insisting upon the same
>> > > algorithm set,
>> > > which is the set of currently NIST-approved algorithms and
>> > > modes.  This
>> > > set of
>> > > algorithms appears to be the preferred set of algorithms and modes
>> > > right now --
>> > > by a VERY wide margin.
>> > >
>> > > In practice, that means there is a strong buyer preference from 
>> many
>> > > countries
>> > > for SHA-1 (and its NIST-documented relatives) and for AES (in
>> > > NIST-acceptable
>> > > modes).  Several countries, including several in Europe and
>> > > several in
>> > > Asia, are
>> > > also insisting that cryptographic products they buy have NIST FIPS
>> > > 140-2 approvals.
>> > > This also tends to reinforce the selection of algorithms and modes
>> > > since only the
>> > > NIST-approved algorithms and modes can get a FIPS 140-2 approval.
>> > >
>> > > I would even suggest that for the moment, any new security 
>> protocols
>> > > developed
>> > > in an IETF context ought to include documentation on how
>> > > NIST-approved
>> > > algorithms
>> > > and modes are used with those protocols -- even if the IETF were 
>> to
>> > > decide that
>> > > it preferred some non-NIST algorithm or mode for a particular
>> > > security
>> > > protocol
>> > > as the "default" algorithm/mode choice.
>> > >
>> > > Yours,
>> > >
>> > > Ran Atkinson
>> > > rja@extremenetworks.com
>> > >
>> > > PS:  Nitpickers should please note well that all of my comments 
>> above
>> > > are about
>> > > the end-user/marketplace desires, and there is no comment above 
>> about
>> > > the quality
>> > > of any particular algorithm or mode.
>> > >
>> > >
>> > > On Oct 28, 2004, at 07:51, David A. McGrew wrote:
>> > > >     I suspect that the group preference would be towards hash
>> > > > functions that are portable (e.g. fast on a wide variety of
>> > > CPUs) and
>> > > > that require minimal per-key state.  There may be other points 
>> of
>> > > > view; others please chime in if you have other priorities.
>> > > >
>> > > > David
>> > >
>> > > _______________________________________________
>> > > saag mailing list
>> > > saag@mit.edu
>> > > https://jis.mit.edu/mailman/listinfo/saag
>> > >
>> >
>> > _______________________________________________
>> > saag mailing list
>> > saag@mit.edu
>> > https://jis.mit.edu/mailman/listinfo/saag
>>
>> Regards,
>>
>> --
>> Jeffrey A. Williams
>> Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
>> "Be precise in the use of words and expect precision from others" -
>>     Pierre Abelard
>>
>> "If the probability be called P; the injury, L; and the burden, B;
>> liability depends upon whether B is less than L multiplied by
>> P: i.e., whether B is less than PL."
>> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
>> ===============================================================
>> Updated 1/26/04
>> CSO/DIR. Internet Network Eng. SR. Eng. Network data security
>> IDNS. div. of Information Network Eng.  INEG. INC.
>> E-Mail jwkckid1@ix.netcom.com
>>  Registered Email addr with the USPS
>> Contact Number: 214-244-4827
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@ietf.org
>> https://www1.ietf.org/mailman/listinfo/cfrg
>
> --
>
> Alex Alten
> alten@EscalonNetworks.com
> (925) 425-9600
>
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>

From James_Hughes@StorageTek.com Mon Nov  1 16:42:49 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA1Lgl6A019774
	for <saag@jis.mit.edu>; Mon, 1 Nov 2004 16:42:48 -0500 (EST)
Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146])
	iA1LgkSI011581
	for <saag@mit.edu>; Mon, 1 Nov 2004 16:42:46 -0500 (EST)
Received: from sherman.stortek.com (localhost [127.0.0.1])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id iA1LgjDY001081
	for <saag@mit.edu>; Mon, 1 Nov 2004 14:42:45 -0700 (MST)
Received: from [129.191.4.222] ([129.191.4.222])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id iA1Lggur001078;
	Mon, 1 Nov 2004 14:42:43 -0700 (MST)
In-Reply-To: <4185BC36.142F0142@ix.netcom.com>
References: <4185BC36.142F0142@ix.netcom.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <CB3E4C2B-2C0B-11D9-B4FE-000A95A27482@StorageTek.com>
From: James Hughes <James_Hughes@StorageTek.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Date: Mon, 1 Nov 2004 08:41:55 -0500
To: "<saag@mit.edu> <saag@mit.edu>" <saag@mit.edu>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.881002
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by jis.mit.edu id
	iA1Lgl6A019774
cc: "<cfrg@ietf.org>" <cfrg@ietf.org>
cc: James Hughes <James_Hughes@StorageTek.com>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 01 Nov 2004 21:42:49 -0000

As an outsider I can see that there are politics and charged words 
here, but I can not understand them. So being the naive person that I 
am, I will respond to the literal words presented here and merrily step 
onto the well trodden land mines. If these things are obvious and 
already decided my apologies for wasting bandwidth.

My comment is this. In the case of backstitching algorithm independence 
into existing (especially non IETF) protocols is not what I would even 
contemplate. To any standards group, I would suggest taking the long 
term approach to solving this. Specifically the following two 
statements would be enough.

1. _New_ protocols that are being design should include the ability to 
negotiate algorithms. This is just good hygiene. If this is not 
formalized, it should be.

2. _Old_ non-negotiating IETF protocols that use obsolete or 
depreciated algorithms should be (formally?) put "on notice" that their 
_security_ should be addressed (not necessarily the protocol). This is 
not a panic, but it should not be tossed under the rug either. If they 
have a coming protocol upgrade planned, add algorithm negotiation. If 
they don't, maybe they can start a protocol upgrade wish-list so that 
the issue doesn't die. Otherwise do something, anything. The option of 
doing nothing is the only thing they shouldn't do.

If they (the standards group that standardizes ATM protocols) wants to 
have a "flag day" upgrade philosophy, or a wholesale replacement 
strategy, that's their choice. If I were a member of that group, I 
would argue for putting protocol upgrades into the long term roadmap so 
that protocol negotiation would get there someday. I believe it is a 
prudent measures to avoid another WEP fiasco.

Complexity should not a roadblock to security. Security is just another 
requirement like reliability and scalability. Reining in complexity 
should already be the responsibility of the workgroup regardless of 
why.

Protocols that do not do upgrade run the risk of being obsoleted in 
their entirety. Case in point, rlogin, telnet, etc. are dead (or should 
be).

I use the definition of "Obsolete or Depreciated" from:
	From: 	  Matthew_Chalmers@bankone.com
	Subject: 	RE: [Cfrg] Re: [saag] Bad day at the hash function factory
	Date: 	August 26, 2004 3:27:49 PM EDT

jim


On Oct 31, 2004, at 11:31 PM, Jeff Williams wrote:

> RJ and all,
>
> RJ Atkinson wrote:
>
> > On Oct 29, 2004, at 09:23, Alex Alten wrote:
>  > > Let me point out as an example that the automated teller machines
> > > (ATMs) security
>  > > protocol has been using the same algorithm with DES since about 
> 1982.
>  > > Making
>  > > protocols algorithm independent (with extra handshakes and upgrade
>  > > mechanisms)
>  > > has the side effect of making them very complex and thus harder to
>  > > certify for
>  > > interoperability, optimize for performance, etc.
>  > >
>  > > - Alex
>  >
>  > I am not at all persuaded that making protocols 
> algorithm-independent
>  > necessarily
>  > has the side effect of making them more complex or harder to 
> certify or
>  > harder to
>  > performance optimise.  I've seen a lot of protocols that were not
>  > algorithm-independent
>  > that *were* astonishingly complex, so the inverse is also not 
> obvious
>  > to me.
>
>   We have similar experiences it seems.  So I entirely agree with you
>  here.  And as such, why I still believe that interface facilities for
>  multi-algorithm's is a far better approach.  But convincing
>  Steve and others on this seems to be improbable even though
>  such is being done and has been for several years.  Perhaps this
>  "Dates" Steve and those of his mindset.
>
> >
>  >
>  > Ran
>  > rja@extremenetworks.com
>
> Regards,
>
> -- 
>  Jeffrey A. Williams
>  Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
>  "Be precise in the use of words and expect precision from others" -
>      Pierre Abelard
>
> "If the probability be called P; the injury, L; and the burden, B;
> liability depends upon whether B is less than L multiplied by
>  P: i.e., whether B is less than PL."
>  United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
>  ===============================================================
> Updated 1/26/04
>  CSO/DIR. Internet Network Eng. SR. Eng. Network data security
>  IDNS. div. of Information Network Eng.  INEG. INC.
>  E-Mail jwkckid1@ix.netcom.com
>  Registered Email addr with the USPS
> Contact Number: 214-244-4827
>
>
>
> _______________________________________________
> saag mailing list
>  saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag


From housley@vigilsec.com Mon Nov  1 17:05:53 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA1M5q6A020702
	for <saag@jis.mit.edu>; Mon, 1 Nov 2004 17:05:52 -0500 (EST)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	iA1M5pSI014041
	for <saag@mit.edu>; Mon, 1 Nov 2004 17:05:51 -0500 (EST)
Received: (qmail 7869 invoked by uid 0); 1 Nov 2004 22:05:44 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.136.114)
  by woodstock.binhost.com with SMTP; 1 Nov 2004 22:05:44 -0000
Message-Id: <6.1.2.0.2.20041101170306.038c9060@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Mon, 01 Nov 2004 17:05:47 -0500
To: saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.633742
Subject: [saag] EasyCert BOF 
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 01 Nov 2004 22:05:53 -0000

I wanted to make people aware of the EasyCert BoF that will be held at the 
DC IETF meeting.  I have been promised that this session will be scheduled 
right before the SAAG on Thursday.  It is intended to be a continuation of 
the discussion that started at the SAAG session at the last IETF 
meeting.  It is not clear what, if any, standards effort will result from 
this BoF.

Russ

>Description:
>         Public key technology -- certificates, the associated
>         private keys, PKIs, etc. -- are hard to use and hard to
>         deploy.  Some of that is merely perception, of course, but
>         some of it is reality.  The question for this BoF, and a
>         possible future working group is this:  what can the IETF
>         do to make life easier?  Some hardware technologies may
>         help, but of course the IETF doesn't develop such things.
>         On the other hand, if we think they're part of the solution,
>         some BCP we write can say so.
>
>         We assume that we're not missing any crucial over-the-wire
>         protocols -- though if we are, they'd be prime candidates
>         for IETF work.  Accordingly, an easycert working group
>         would be charged with writing a few BCPs and possibly
>         Informational RFCs.  So -- what are the titles of some such
>         RFCs?  If you're a service provider (for any sort of service
>         -- ISP, web site, ecommerce, etc.), what sort of advice
>         should the IETF give you?  The vendors you buy from?
>         Software developers?
>
>         The specific goal of the BoF is to figure out what the IETF
>         can do.  The desired outcome is a set of major charter
>         points, including the titles of some RFCs we'd produce.
>
>Agenda:
>         Jeff Schiller, MIT (20 minutes)
>         Robert Stahl, Johnson & Johnson (20 minutes)
>         Open discussion
>         Summarize main charter points (20 minutes)
>
>Mailing list:
>         easycert@machshav.com
>         https://www.machshav.com/mailman/listinfo.cgi/easycert

From pbaker@verisign.com Mon Nov  1 20:10:07 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA21A66A025806
	for <saag@jis.mit.edu>; Mon, 1 Nov 2004 20:10:06 -0500 (EST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	iA21A4ut016715
	for <saag@mit.edu>; Mon, 1 Nov 2004 20:10:04 -0500 (EST)
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com
	[65.205.251.54])iA219vL7025756;	Mon, 1 Nov 2004 17:10:01 -0800 (PST)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <WCAXWNXS>; Mon, 1 Nov 2004 17:09:57 -0800
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'James Hughes'" <James_Hughes@StorageTek.com>,
   "<saag@mit.edu> <saag@mit.edu>" <saag@mit.edu>
Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades
Date: Mon, 1 Nov 2004 17:09:55 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.544074
cc: "<cfrg@ietf.org>" <cfrg@ietf.org>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 01:10:07 -0000

>1. _New_ protocols that are being design should include the ability to 
>negotiate algorithms. This is just good hygiene. If this is not 
>formalized, it should be.

I strongly disagree. History has showed that negotiation mechanisms can lead
to worse security problems than they are meant to address. The IETF has
certainly showed an exceptional ability to overcomplicate them.

What we need is a policy layer for the whole application protocol layer
stack. It should not be part of the individual protocols, it should be part
of the DNS.


	Phill
From jwkckid1@ix.netcom.com Tue Nov  2 00:32:58 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA25Wv6A002745
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 00:32:57 -0500 (EST)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net
	[207.69.200.226])iA25WtGH016424
	for <saag@mit.edu>; Tue, 2 Nov 2004 00:32:55 -0500 (EST)
Received: from 1cust226.tnt59.dfw5.da.uu.net ([67.203.43.226]
	helo=ix.netcom.com)
	by blount.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1COrHY-0007oM-00; Tue, 02 Nov 2004 00:32:36 -0500
Message-ID: <418737BA.A11985D@ix.netcom.com>
Date: Mon, 01 Nov 2004 23:31:10 -0800
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References: <003501c4bd1e$75c3a0c0$0302000a@SCROCKER>
	<4.3.2.7.1.20041029061644.035f7948@mail.comcast.net>
	<9B270C7E-2B48-11D9-8B60-000D93B505E6@extremenetworks.com>
	<4185BC36.142F0142@ix.netcom.com>
	<280DB916-2C08-11D9-84C0-000D93B505E6@extremenetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.600421
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 05:32:58 -0000

RJ and all,

RJ Atkinson wrote:

> On Oct 31, 2004, at 23:31, Jeff Williams wrote:
> >   We have similar experiences it seems.  So I entirely agree with you
> > here.  And as such, why I still believe that interface facilities for
> > multi-algorithm's is a far better approach.  But convincing
> > Steve and others on this seems to be improbable even though
> > such is being done and has been for several years.  Perhaps this
> > "Dates" Steve and those of his mindset.
>
> Jeff,
>
>         Perhaps you might not have read my words carefully enough.
> I fully agree with Steve Crocker.  And I am utterly bafffled as to how
> anyone could misread my written words as disagreeing with Steve Crocker.

  If you say so.  However I still do not agree with Steve and if you had
read my response in it's entirety,  you would have taken noticed exactly
where and why I do not, yet also can agree with your previous response
on this thread which you seemed to have snipped for some odd reason...

>
>
> Yours,
>
> Ran
> rja@extremenetworks.com

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From jwkckid1@ix.netcom.com Tue Nov  2 00:43:28 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA25hP6A003008
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 00:43:25 -0500 (EST)
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net
	[207.69.200.226])iA25hOaR016349
	for <saag@mit.edu>; Tue, 2 Nov 2004 00:43:24 -0500 (EST)
Received: from 1cust226.tnt59.dfw5.da.uu.net ([67.203.43.226]
	helo=ix.netcom.com)
	by blount.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1COrRw-000138-00; Tue, 02 Nov 2004 00:43:20 -0500
Message-ID: <41873A41.CCA34034@ix.netcom.com>
Date: Mon, 01 Nov 2004 23:41:56 -0800
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: "David A. McGrew" <mcgrew@cisco.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References: <003501c4bd1e$75c3a0c0$0302000a@SCROCKER>
	<4.3.2.7.1.20041029061644.035f7948@mail.comcast.net>
	<1B25E69C-2C10-11D9-A7FD-0003935495EC@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.815830
cc: cfrg@ietf.org
cc: Alex Alten <alten@escalonnetworks.com>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 05:43:29 -0000

David and all,

  Thank you David for applying some common sense here.  Legacy
based or legacy methods are long out of date and do not or cannot
address the needs and demands of the marketplace.  Yet it is being
broader understood that some standards organization suffer from
an over familiarity with legacy y methods and will defend those methods
very strongly to the point of a religious fever...

David A. McGrew wrote:

> Alex,
>
> On Oct 29, 2004, at 6:23 AM, Alex Alten wrote:
>
> > All,
> >
> > Let me point out as an example that the automated teller machines
> > (ATMs) security
> > protocol has been using the same algorithm with DES since about 1982.
> > Making
> > protocols algorithm independent (with extra handshakes and upgrade
> > mechanisms)
> > has the side effect of making them very complex and thus harder to
> > certify for
> > interoperability, optimize for performance, etc.
>
> I respectfully disagree.  Modern systems and protocols need to have the
> ability to utilize different crypto algorithms.  Otherwise, how can a
> deficient algorithm be replaced?  Consider the complexity of taking a
> legacy system in which the algorithms have been hard-wired and then
> trying to remove a deficient algorithm and replace it with a better
> one.
>
> OTOH, I do think that we could do a better job of making the crypto
> easy to upgrade.  If there were a well defined, clean and simple
> interface to the crypto functions, and crypto functions were defined to
> match that interface, adoption would be easier.  One research paper
> that goes in this direction (but does not formally define an interface)
> is: Mihir Bellare and Tadayoshi Kohno and Chanathip Namprempre,
> Breaking and Provably Repairing the SSH Authenticated Encryption
> Scheme: A Case Study of the Encode-then-Encrypt-and-MAC Paradigm, To
> appear in ACM Transactions on Information and System Security, ACM,
> 2004. An extended abstract of this paper appeared in Ninth ACM
> Conference on Computer and Communications Security, ACM, 2002.
> http://eprint.iacr.org/2002/078/
>
> David
>
> >
> > - Alex
> >
> > At 02:22 PM 10/28/2004 -0700, Jeff Williams wrote:
> >> Steve and all,
> >>
> >>   Again we disagree in your conclusion here Steve.  Of course we
> >> have been over this ground before.  Changing or introducing new
> >> crypto algorithm's in no way should impede or prevent interoerability
> >> and interface facilities now available can and do address this issue.
> >>
> >> Steve Crocker wrote:
> >>
> >> > No matter what algorithms we choose today, it's likely that changes
> >> will
> >> > be required in the future.  Let me strengthen Ran's suggestion.  In
> >> > addition to building algorithm-independent protocols, the protocols
> >> > should also include an upgrade mechanism for changing algorithms in
> >> an
> >> > orderly way.  It's not good enough to say protocol FOO is
> >> independent of
> >> > algorithm if all of the initial deployment depends on crypto
> >> algorithm
> >> > SNARF and there's no way to introduce new crypto algorithm FARNS
> >> without
> >> > breaking interoperability.
> >> >
> >> > Steve
> >> >
> >> > > -----Original Message-----
> >> > > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On
> >> > > Behalf Of RJ Atkinson
> >> > > Sent: Thursday, October 28, 2004 8:49 AM
> >> > > To: David A. McGrew
> >> > > Cc: cfrg@ietf.org; saag@mit.edu
> >> > > Subject: [saag] Re: universal MACs
> >> > >
> >> > >
> >> > > David,
> >> > >
> >> > > My protocol preference in an IETF context is for
> >> > > algorithm-independent
> >> > > protocols,
> >> > > so that one does not need to change the protocol to add support
> >> for
> >> > > additional
> >> > > algorithms in future.  This property holds for at least OSPFv2
> >> > > authentication and
> >> > > RIPv2 authentication (and yes, I am working on documentation
> >> > > updates to
> >> > > each
> >> > > of those specifications to document how SHA-1 and its relatives
> >> are
> >> > > implemented).
> >> > >
> >> > > My algorithm preference in an IETF context is for algorithms that
> >> are
> >> > > acceptable
> >> > > to the largest number of end users.  Right now, many
> >> > > governments (from
> >> > > multiple
> >> > > governments, including several in Europe and several in Asia,
> >> > > NOT just
> >> > > the US)
> >> > > and many non-governmental customers are insisting upon the same
> >> > > algorithm set,
> >> > > which is the set of currently NIST-approved algorithms and
> >> > > modes.  This
> >> > > set of
> >> > > algorithms appears to be the preferred set of algorithms and modes
> >> > > right now --
> >> > > by a VERY wide margin.
> >> > >
> >> > > In practice, that means there is a strong buyer preference from
> >> many
> >> > > countries
> >> > > for SHA-1 (and its NIST-documented relatives) and for AES (in
> >> > > NIST-acceptable
> >> > > modes).  Several countries, including several in Europe and
> >> > > several in
> >> > > Asia, are
> >> > > also insisting that cryptographic products they buy have NIST FIPS
> >> > > 140-2 approvals.
> >> > > This also tends to reinforce the selection of algorithms and modes
> >> > > since only the
> >> > > NIST-approved algorithms and modes can get a FIPS 140-2 approval.
> >> > >
> >> > > I would even suggest that for the moment, any new security
> >> protocols
> >> > > developed
> >> > > in an IETF context ought to include documentation on how
> >> > > NIST-approved
> >> > > algorithms
> >> > > and modes are used with those protocols -- even if the IETF were
> >> to
> >> > > decide that
> >> > > it preferred some non-NIST algorithm or mode for a particular
> >> > > security
> >> > > protocol
> >> > > as the "default" algorithm/mode choice.
> >> > >
> >> > > Yours,
> >> > >
> >> > > Ran Atkinson
> >> > > rja@extremenetworks.com
> >> > >
> >> > > PS:  Nitpickers should please note well that all of my comments
> >> above
> >> > > are about
> >> > > the end-user/marketplace desires, and there is no comment above
> >> about
> >> > > the quality
> >> > > of any particular algorithm or mode.
> >> > >
> >> > >
> >> > > On Oct 28, 2004, at 07:51, David A. McGrew wrote:
> >> > > >     I suspect that the group preference would be towards hash
> >> > > > functions that are portable (e.g. fast on a wide variety of
> >> > > CPUs) and
> >> > > > that require minimal per-key state.  There may be other points
> >> of
> >> > > > view; others please chime in if you have other priorities.
> >> > > >
> >> > > > David
> >> > >
> >> > > _______________________________________________
> >> > > saag mailing list
> >> > > saag@mit.edu
> >> > > https://jis.mit.edu/mailman/listinfo/saag
> >> > >
> >> >
> >> > _______________________________________________
> >> > saag mailing list
> >> > saag@mit.edu
> >> > https://jis.mit.edu/mailman/listinfo/saag
> >>
> >> Regards,
> >>
> >> --
> >> Jeffrey A. Williams
> >> Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
> >> "Be precise in the use of words and expect precision from others" -
> >>     Pierre Abelard
> >>
> >> "If the probability be called P; the injury, L; and the burden, B;
> >> liability depends upon whether B is less than L multiplied by
> >> P: i.e., whether B is less than PL."
> >> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> >> ===============================================================
> >> Updated 1/26/04
> >> CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> >> IDNS. div. of Information Network Eng.  INEG. INC.
> >> E-Mail jwkckid1@ix.netcom.com
> >>  Registered Email addr with the USPS
> >> Contact Number: 214-244-4827
> >>
> >>
> >>
> >> _______________________________________________
> >> Cfrg mailing list
> >> Cfrg@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/cfrg
> >
> > --
> >
> > Alex Alten
> > alten@EscalonNetworks.com
> > (925) 425-9600
> >
> > _______________________________________________
> > saag mailing list
> > saag@mit.edu
> > https://jis.mit.edu/mailman/listinfo/saag
> >

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From smb@research.att.com Tue Nov  2 11:27:17 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA2GRG6A022618
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 11:27:16 -0500 (EST)
Received: from machshav.com (machshav.com [147.28.0.16])
	iA2GRFg0015612
	for <saag@mit.edu>; Tue, 2 Nov 2004 11:27:15 -0500 (EST)
Received: by machshav.com (Postfix, from userid 512)
	id BD05EFB27C; Tue,  2 Nov 2004 16:27:14 +0000 (UTC)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP
	id 4B48FFB27D; Tue,  2 Nov 2004 16:27:08 +0000 (UTC)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id 9D62F1AE88; Tue,  2 Nov 2004 10:02:08 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades 
In-Reply-To: Your message of "Mon, 01 Nov 2004 17:09:55 PST."
	<C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 02 Nov 2004 10:02:08 -0500
Message-Id: <20041102150208.9D62F1AE88@berkshire.research.att.com>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.541682
cc: cfrg@ietf.org
cc: James Hughes <James_Hughes@StorageTek.com>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 16:27:17 -0000

In message <C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.
com>, "Hallam-Baker, Phillip" writes:

>
>What we need is a policy layer for the whole application protocol layer
>stack. It should not be part of the individual protocols, it should be part
>of the DNS.
>

I'm very far from convinced that a single policy layer is feasible or
even desirable -- policies for individual applications will vary too 
much.  That said, I'm 100% certain that putting anything like policies
into the DNS is a bad idea.  The discussion in RFC 3445 outlines some 
reasons why this is a bad idea; I could go on about this at great 
length, but this is probably the wrong forum for that discussion.

		--Steve Bellovin, http://www.research.att.com/~smb


From hartmans@MIT.EDU Tue Nov  2 12:56:04 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA2Hu36A025550
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 12:56:03 -0500 (EST)
Received: from cz.mit.edu (CZ-HOTASS.MIT.EDU [18.101.1.53])
	iA2Hu2g0025360
	for <saag@mit.edu>; Tue, 2 Nov 2004 12:56:02 -0500 (EST)
Received: by cz.mit.edu (Postfix, from userid 8042)
	id A646316010B; Tue,  2 Nov 2004 12:56:03 -0500 (EST)
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References: <C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
From: Sam Hartman <hartmans@MIT.EDU>
Date: Tue, 02 Nov 2004 12:56:03 -0500
In-Reply-To:
	<C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
	(Phillip Hallam-Baker's message of "Mon, 1 Nov 2004 17:09:55 -0800")
Message-ID: <tslk6t49lu4.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.566566
cc: "<cfrg@ietf.org>" <cfrg@ietf.org>
cc: 'James Hughes' <James_Hughes@StorageTek.com>
cc: "<saag@mit.edu> <saag@mit.edu>" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 17:56:04 -0000

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <pbaker@verisign.com> writes:

    >> 1. _New_ protocols that are being design should include the
    >> ability to negotiate algorithms. This is just good hygiene. If
    >> this is not formalized, it should be.

    Hallam-Baker,> I strongly disagree. History has showed that
    Hallam-Baker,> negotiation mechanisms can lead to worse security
    Hallam-Baker,> problems than they are meant to address. The IETF
    Hallam-Baker,> has certainly showed an exceptional ability to
    Hallam-Baker,> overcomplicate them.

I agree there are problems with negotiation layers.  

However so far they seem to be the only mechanism I've found that
work.  Can you explain how we would have handled the conversion from
DES to AES for IPSec in an alternate universe where all the protocols
worked as you desire?  I think that will help me understand what you
propose much better.

--Sam

From hartmans@MIT.EDU Tue Nov  2 13:12:09 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA2IC86A026114
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 13:12:08 -0500 (EST)
Received: from cz.mit.edu (CZ-HOTASS.MIT.EDU [18.101.1.53])
	iA2IC74t011555
	for <saag@mit.edu>; Tue, 2 Nov 2004 13:12:07 -0500 (EST)
Received: by cz.mit.edu (Postfix, from userid 8042)
	id 9299416010B; Tue,  2 Nov 2004 13:12:05 -0500 (EST)
To: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] EasyCert BOF
References: <6.1.2.0.2.20041101170306.038c9060@mail.binhost.com>
From: Sam Hartman <hartmans@MIT.EDU>
Date: Tue, 02 Nov 2004 13:12:05 -0500
In-Reply-To: <6.1.2.0.2.20041101170306.038c9060@mail.binhost.com> (Russ
 Housley's message of "Mon, 01 Nov 2004 17:05:47 -0500")
Message-ID: <tslfz3s9l3e.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.600111
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 18:12:10 -0000

>>>>> "Russ" == Russ Housley <housley@vigilsec.com> writes:

    Russ> I wanted to make people aware of the EasyCert BoF that will
    Russ> be held at the DC IETF meeting.  I have been promised that
    Russ> this session will be scheduled right before the SAAG on
    Russ> Thursday.  It is intended to be a continuation of the
    Russ> discussion that started at the SAAG session at the last IETF
    Russ> meeting.  It is not clear what, if any, standards effort
    Russ> will result from this BoF.

Is the question "Is PKI even the right answer," in scope for this BOF?
Clearly PKI is part of the solution to some problems, but I think
there is significant room to ask whether PKI is at the root of our
entire security architecture.

It seemed fairly clear from the SAAG discussion that several people
believed the IETF's emphasis on PKI as the solution to our problems
was suspect.

Personally my conclusion after working on these problems for many
years and after listening to the security retrospective presented at
the plenary, I have come to conclude that we're pushing PKI too hard.
There is a lot of evidence that security works when we can manage to
find a match between what an organization needs and the available
technologies.  It also helps if technologies can be incrementally
deployed and it helps if you don't ask an organization to deploy more
than one technology.  


I actually think it may be best if we restrict ourselves to discussing
how to solve the deployment problems of PKI at this BOF.  However I
think that losing the general question would miss an excellent
opportunity to understand how to make security deployable.  There were
some interesting questions raised by the security retrospective
presentation and we should actually take the time to understand why
some technologies have been successful and others have had deployment
problems.  We should adjust our thinking to make sure that we learn
from real-world deployment.

--Sam

From kent@bbn.com Tue Nov  2 13:42:46 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA2Igk6A027290
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 13:42:46 -0500 (EST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62])
	iA2IgiuW016546
	for <saag@mit.edu>; Tue, 2 Nov 2004 13:42:45 -0500 (EST)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iA2Ig6jf012054;
	Tue, 2 Nov 2004 13:42:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06110409bdad81d64ccd@[128.89.89.75]>
In-Reply-To: 
 <C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
References: 
 <C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
Date: Tue, 2 Nov 2004 13:34:43 -0500
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.42
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.606106
cc: "<cfrg@ietf.org>" <cfrg@ietf.org>
cc: 'James Hughes' <James_Hughes@StorageTek.com>
cc: "<saag@mit.edu> <saag@mit.edu>" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 18:42:47 -0000

At 5:09 PM -0800 11/1/04, Hallam-Baker, Phillip wrote:
>  >1. _New_ protocols that are being design should include the ability to
>>negotiate algorithms. This is just good hygiene. If this is not
>>formalized, it should be.
>
>I strongly disagree. History has showed that negotiation mechanisms can lead
>to worse security problems than they are meant to address. The IETF has
>certainly showed an exceptional ability to overcomplicate them.
>
>What we need is a policy layer for the whole application protocol layer
>stack. It should not be part of the individual protocols, it should be part
>of the DNS.

I'm not convinced that the choice of algorithm, modes, key length, 
etc. is always an application decision.  One may want to impose 
constraints on algorithms in a more secure context than that provided 
by an application. Also, the role of the DNS in this context is 
questionable, and may be in conflict with your application layer 
negotiation. Protocols like e-mail  where there is no realtime 
ability to negotiate security parameters, could benefit from some 
form of directory advertisement of algorithm capabilities, but 
primarily for encryption. (If I send a signed message to a bunch of 
folks, I may not want to check to determine what algorithms each 
recipient supports, to add signatures to accommodate all of them.) 
Selection of mandatory defaults makes interoperability generally 
viable in the absence of posted algorithm capability schemes. Also, 
making algorithm capabilities known via DNS requires an ability to 
update DNS entries, and if one really wanted to do this on an 
individual basis, it would require more user access to DNS data than 
we typically support today, which could cause all sorts of problems 
for both users and DNS administrators.

Steve
From housley@vigilsec.com Tue Nov  2 14:19:06 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA2JJ56A028584
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 14:19:05 -0500 (EST)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	iA2JJ31C000369
	for <saag@mit.edu>; Tue, 2 Nov 2004 14:19:04 -0500 (EST)
Received: (qmail 5493 invoked by uid 0); 2 Nov 2004 19:18:56 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.136.114)
  by woodstock.binhost.com with SMTP; 2 Nov 2004 19:18:56 -0000
Message-Id: <6.1.2.0.2.20041102141614.04fdc840@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Tue, 02 Nov 2004 14:17:26 -0500
To: Sam Hartman <hartmans@mit.edu>
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] EasyCert BOF
In-Reply-To: <tslfz3s9l3e.fsf@cz.mit.edu>
References: <6.1.2.0.2.20041101170306.038c9060@mail.binhost.com>
 <tslfz3s9l3e.fsf@cz.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.639904
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 19:19:07 -0000

Sam:

The topic for this BoF is PKI deployment.

I suggest that we discuss your other topic at the open mic portion of SAAG.

Russ

At 01:12 PM 11/2/2004, Sam Hartman wrote:
> >>>>> "Russ" == Russ Housley <housley@vigilsec.com> writes:
>
>     Russ> I wanted to make people aware of the EasyCert BoF that will
>     Russ> be held at the DC IETF meeting.  I have been promised that
>     Russ> this session will be scheduled right before the SAAG on
>     Russ> Thursday.  It is intended to be a continuation of the
>     Russ> discussion that started at the SAAG session at the last IETF
>     Russ> meeting.  It is not clear what, if any, standards effort
>     Russ> will result from this BoF.
>
>Is the question "Is PKI even the right answer," in scope for this BOF?
>Clearly PKI is part of the solution to some problems, but I think
>there is significant room to ask whether PKI is at the root of our
>entire security architecture.
>
>It seemed fairly clear from the SAAG discussion that several people
>believed the IETF's emphasis on PKI as the solution to our problems
>was suspect.
>
>Personally my conclusion after working on these problems for many
>years and after listening to the security retrospective presented at
>the plenary, I have come to conclude that we're pushing PKI too hard.
>There is a lot of evidence that security works when we can manage to
>find a match between what an organization needs and the available
>technologies.  It also helps if technologies can be incrementally
>deployed and it helps if you don't ask an organization to deploy more
>than one technology.
>
>
>I actually think it may be best if we restrict ourselves to discussing
>how to solve the deployment problems of PKI at this BOF.  However I
>think that losing the general question would miss an excellent
>opportunity to understand how to make security deployable.  There were
>some interesting questions raised by the security retrospective
>presentation and we should actually take the time to understand why
>some technologies have been successful and others have had deployment
>problems.  We should adjust our thinking to make sure that we learn
>from real-world deployment.
>
>--Sam

From hartmans@MIT.EDU Tue Nov  2 14:52:26 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA2JqP6A029655
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 14:52:26 -0500 (EST)
Received: from cz.mit.edu (STRATTON-FOUR-SEVENTY-FOUR.MIT.EDU [18.187.6.219])
	iA2JqOuW019617
	for <saag@mit.edu>; Tue, 2 Nov 2004 14:52:25 -0500 (EST)
Received: by cz.mit.edu (Postfix, from userid 8042)
	id C1D6C16011E; Tue,  2 Nov 2004 14:52:25 -0500 (EST)
To: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] EasyCert BOF
References: <6.1.2.0.2.20041101170306.038c9060@mail.binhost.com>
	<tslfz3s9l3e.fsf@cz.mit.edu>
	<6.1.2.0.2.20041102141614.04fdc840@mail.binhost.com>
From: Sam Hartman <hartmans@MIT.EDU>
Date: Tue, 02 Nov 2004 14:52:25 -0500
In-Reply-To: <6.1.2.0.2.20041102141614.04fdc840@mail.binhost.com> (Russ
 Housley's message of "Tue, 02 Nov 2004 14:17:26 -0500")
Message-ID: <tslvfcom3k6.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.590680
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 19:52:27 -0000

>>>>> "Russ" == Russ Housley <housley@vigilsec.com> writes:

    Russ> Sam: The topic for this BoF is PKI deployment.

    Russ> I suggest that we discuss your other topic at the open mic
    Russ> portion of SAAG.


This sounds like a good idea to me.

In the interests of hopefully encouraging others to think about the
issue let me describe in a bit more detail what I'm getting at.

I believe there is a perception that PKI is the solution for security
problems on the Internet.

In practice, people actually tend to find other solutions.  Many
people use RADIUS and CHAP/other challenge based systems, possibly
with TLS to authenticate servers to clients.  The ssh key model has
been fairly popular for that application.  EAP is becoming
increasingly popular in some of the simpler modes of authentication.
Kerberos and SASL have their own places.

There seem to be a lot of people claiming that PKI is hard to deploy.
They want to make it easier.  At the same time I'd like to ask us to
make sure we are not proposing PKI as a solution when it is not
needed.


Perhaps people are using technologies like RADIUS, EAP, SASL, digest
authentication and self-signed certificates because they meet their
needs.

Perhaps there are things we could do to design protocols that work
better in these sort of low-security modes while also working well
when a PKI or other infrastructure is available.  Perhaps we should
make that a design goal for the Internet security architecture.

From djb-dsn-1099428920.89918@cr.yp.to Tue Nov  2 15:54:57 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA2Ksu6A001486
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 15:54:56 -0500 (EST)
Received: from stoneport.math.uic.edu (stoneport.math.uic.edu
	[131.193.178.160])iA2KstuW012854
	for <saag@mit.edu>; Tue, 2 Nov 2004 15:54:55 -0500 (EST)
Received: (qmail 89919 invoked by uid 1016); 2 Nov 2004 20:55:20 -0000
Date: 2 Nov 2004 20:55:20 -0000
Message-ID: <20041102205520.89918.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: saag@mit.edu, cfrg@ietf.org
References:
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
	<20040926195031.59299.qmail@cr.yp.to>
	<B382BA62-28D7-11D9-8709-0003935495EC@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.565375
Subject: [saag] Re: universal MACs
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 20:54:57 -0000

David A. McGrew writes:
> I suspect that the group preference would be towards hash functions
> that are portable (e.g. fast on a wide variety of CPUs) and that
> require minimal per-key state.

I've just posted http://cr.yp.to/papers.html#poly1305, introducing and
analyzing Poly1305-AES, a 128-bit MAC. Main features:

   * Guaranteed security, even for long-term keys, if AES is secure.
   * Cipher replaceability: can switch from AES if desired.
   * Extremely high speed: for example, 3.625 Athlon cycles per byte.
   * Low per-message overhead: 800 cycles total for a 64-byte message.
   * Key agility: the key is stored in memory as just 32 bytes.
   * Parallelizability, incrementality, low circuit depth, etc.
   * No intellectual-property claims.

Guaranteed security, cipher replaceability, and parallelizability are
provided by the standard polynomial-evaluation-Wegman-Carter-MAC
framework. Within that framework, hash127 achieved high speed at the
expense of a large table for each key. The added feature of Poly1305-AES
is key agility: high speed without any key expansion.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
From James_Hughes@StorageTek.com Tue Nov  2 17:15:58 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA2MFv6A003518
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 17:15:57 -0500 (EST)
Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146])
	iA2MFtRp008626
	for <saag@mit.edu>; Tue, 2 Nov 2004 17:15:55 -0500 (EST)
Received: from sherman.stortek.com (localhost [127.0.0.1])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id iA2MFrDY004458
	for <saag@mit.edu>; Tue, 2 Nov 2004 15:15:54 -0700 (MST)
Received: from [129.191.4.222] ([129.191.4.222])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id iA2MCqv3003557;
	Tue, 2 Nov 2004 15:15:48 -0700 (MST)
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
References: <C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C7A64FF8-2C9E-11D9-B4FE-000A95A27482@StorageTek.com>
Content-Transfer-Encoding: 7bit
From: James Hughes <James_Hughes@StorageTek.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Date: Tue, 2 Nov 2004 02:14:05 -0500
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.610081
cc: cfrg@ietf.org
cc: James Hughes <James_Hughes@StorageTek.com>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 22:15:58 -0000

On Nov 1, 2004, at 8:09 PM, Hallam-Baker, Phillip wrote:

>> 1. _New_ protocols that are being design should include the ability 
>> to negotiate algorithms. This is just good hygiene. If this is not 
>> formalized, it should be.
>
> I strongly disagree. History has showed that negotiation mechanisms 
> can lead
>  to worse security problems than they are meant to address. The IETF 
> has
>  certainly showed an exceptional ability to overcomplicate them.

Well. We disagree then.

The only history of negotiation failures that I have seen is the GSM 
vulnerability where they put ECC under weak encryption and then used 
that same key for high strength, cracked the key, spoofed a base 
station, mounted a MIM attack and got in. Yes this is a protocol 
vulnerability with 2 (Doh!) stupid crypto mistakes. Was this caused 
because there was algorithm flexibility or because of other reasons? I 
would suggest that this is more about the other mistakes than about the 
fact that there were protocol vulnerabilities. If you have other 
examples, I'm all ears.

Keeping a protocol centered on the problem without the siren call of  
"feature creep" is not easy. It is this creep of "just one more feature 
cuz its a simple tweak" that, when compounded created a 
incomprehensible stew of incongruous kludges. If one can keep their eye 
on the ball, and is managed as a fundamental feature ( not an add on ) 
along with scalability and reliability, then it -is- possible to have 
algorithm flexibility.

Half of the IETF protocols are more complicated than the average IETF 
protocol.

Well, maybe we strongly agree. What we need is an ability to add new 
algorithms, remove bad algorithms with causing undue complexity to the 
user.



> What we need is a policy layer for the whole application protocol layer
>  stack. It should not be part of the individual protocols, it should 
> be part
> of the DNS.

This seems like a policy punt. what are you suggesting and why?

Thanks

jim

From nw141292@binky.central.sun.com Tue Nov  2 17:55:01 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA2Mt06A004536
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 17:55:01 -0500 (EST)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	iA2MsvRp023595
	for <saag@mit.edu>; Tue, 2 Nov 2004 17:54:58 -0500 (EST)
Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iA2Msv7q015557
	for <saag@mit.edu>; Tue, 2 Nov 2004 14:54:57 -0800 (PST)
Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104])
	with ESMTP id iA2MsuJh011362
	for <saag@mit.edu>; Tue, 2 Nov 2004 15:54:56 -0700 (MST)
Received: from binky.central.sun.com (localhost [127.0.0.1])
	iA2MsRqW027881;	Tue, 2 Nov 2004 16:54:27 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA2MsRbf027880;
	Tue, 2 Nov 2004 16:54:27 -0600 (CST)
Date: Tue, 2 Nov 2004 16:54:27 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: James Hughes <James_Hughes@StorageTek.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Message-ID: <20041102225426.GH21427@binky.central.sun.com>
References:
	<C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
	<C7A64FF8-2C9E-11D9-B4FE-000A95A27482@StorageTek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C7A64FF8-2C9E-11D9-B4FE-000A95A27482@StorageTek.com>
User-Agent: Mutt/1.4.1i
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.536351
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 22:55:02 -0000

On Tue, Nov 02, 2004 at 02:14:05AM -0500, James Hughes wrote:
> Half of the IETF protocols are more complicated than the average IETF 
> protocol.

If you'd said 'median' I might disagree (or not).

Nico
-- 
From pbaker@verisign.com Tue Nov  2 20:04:38 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA314b6A007907
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 20:04:37 -0500 (EST)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	iA314aAl027429
	for <saag@mit.edu>; Tue, 2 Nov 2004 20:04:36 -0500 (EST)
Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com
	[65.205.251.33])
	by robin.verisign.com (8.12.11/8.12.11) with ESMTP id iA314WAf000089;
	Tue, 2 Nov 2004 17:04:32 -0800 (PST)
Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <476DDTML>; Tue, 2 Nov 2004 17:04:32 -0800
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECF9@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'James Hughes'" <James_Hughes@StorageTek.com>,
   "Hallam-Baker, Phillip"
	 <pbaker@verisign.com>
Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades
Date: Tue, 2 Nov 2004 17:04:31 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.635731
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 03 Nov 2004 01:04:38 -0000


> On Nov 1, 2004, at 8:09 PM, Hallam-Baker, Phillip wrote:
> 
> >> 1. _New_ protocols that are being design should include the ability
> >> to negotiate algorithms. This is just good hygiene. If this is not 
> >> formalized, it should be.
> >
> > I strongly disagree. History has showed that negotiation mechanisms
> > can lead
> >  to worse security problems than they are meant to address. 
> The IETF 
> > has
> >  certainly showed an exceptional ability to overcomplicate them.
> 
> Well. We disagree then.
> 
> The only history of negotiation failures that I have seen is the GSM 
> vulnerability where they put ECC under weak encryption and then used 
> that same key for high strength, cracked the key, spoofed a base 
> station, mounted a MIM attack and got in. Yes this is a protocol 
> vulnerability with 2 (Doh!) stupid crypto mistakes.

The IETF can start criticizing others for crypto errors after it delivers a
viable spec for ubiquitous IPSEC and DNSSEC. 

Failure to deliver a viable protocol after a decade renders the quality
somewhat meaningless.

> Keeping a protocol centered on the problem without the siren call of  
> "feature creep" is not easy. It is this creep of "just one 
> more feature 
> cuz its a simple tweak" that, when compounded created a 
> incomprehensible stew of incongruous kludges. 

Despite knowing rather more than the average user and several hours of
effort I am unable to get my WiFi card to talk to my main Wifi router with
crypto turned on. 

Apart from SSL I can't think of any IETF protocol that manages a better user
experience.

> Half of the IETF protocols are more complicated than the average IETF 
> protocol.

With the exception of SSL/TLS and WEP virtually all crypto protocols have
failled. WEP also had the minor inconvenience of not working but at least it
is used and the next version will be fixed.

> Well, maybe we strongly agree. What we need is an ability to add new 
> algorithms, remove bad algorithms with causing undue 
> complexity to the 
> user.

What we need is a plan to get people to use the stuff. Real people, not
geeks.

> 
> 
> > What we need is a policy layer for the whole application protocol 
> > layer  stack. It should not be part of the individual protocols, it 
> > should be part of the DNS.
> 
> This seems like a policy punt. what are you suggesting and why?

Nope, recognition of a shortcomming of the Internet architecture. A
principled policy architecture, not the usual punt.
From viega@list.org Mon Nov  1 09:54:52 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA1Esk6A006629
	for <saag@jis.mit.edu>; Mon, 1 Nov 2004 09:54:51 -0500 (EST)
Received: from strongbadia.list.org (strongbadia.list.org [206.131.226.62])
	iA1EsiDe005284
	for <saag@mit.edu>; Mon, 1 Nov 2004 09:54:45 -0500 (EST)
Received: by strongbadia.list.org (Postfix, from userid 1002)
	id 792CF130EF0; Mon,  1 Nov 2004 09:45:17 -0500 (EST)
Date: Mon, 1 Nov 2004 09:45:17 -0500
From: John Viega <viega@securesoftware.com>
To: "D. J. Bernstein" <djb@cr.yp.to>
Subject: Re: [Cfrg] Re: [saag] Bad day at the hash function factory
Message-ID: <20041101144517.GE61972@zork.org>
References:
	<151A63B4E33B4F49896AC6D1BA788A6E15C57F@EXCHVS2.louisville.stortek.com>
	<20040926155422.1F55F1AE84@berkshire.research.att.com>
	<20040926195031.59299.qmail@cr.yp.to>
	<200410280205.WAA29306@Sparkle.Rodents.Montreal.QC.CA>
	<kjoeinh8qp.fsf@romeo.rtfm.com> <20041101062804.56140.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041101062804.56140.qmail@cr.yp.to>
User-Agent: Mutt/1.5.5.1i
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.626827
X-Mailman-Approved-At: Wed, 03 Nov 2004 10:34:41 -0500
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 01 Nov 2004 14:54:52 -0000

What Dan says is true in the case of modern MACs, but is not true for
the case of unkeyed hash functions built from a block cipher. There,
the best we have been able to do is prove security if the underlying
block cipher behaves like an ideal block cipher, much weaker than the
PRP assumption used in proving block cipher-based MACs secure.

As Eric mentioned, modern hash functions can be viewed as block
ciphers in Davies-Meyer mode. There's a proof of security for
Davies-Meyer mode in the ideal cipher model, and yet the recent
cryptanalytic results due to Joux et al. really take advantage of
Davies-Meyer mode. That is not to say that Davies-Meyer with a
stronger underlying block cipher wouldn't be better (e.g., Whirlpool),
but it does suggest that it might be good to move to one of the other
modes with similar security proofs, one that doesn't use the data
being hashed as the block cipher key, such as Matyas-Meyer-Oseas. 

This will slow down our hash functions, because the Davies-Meyer
approach essentially allows one to avoid key scheduling, and run fewer
iterations of the block cipher at the same time.  But it seems far
more conservative.

John

On Mon, Nov 01, 2004 at 06:28:04AM -0000, D. J. Bernstein wrote:
> Eric Rescorla writes:
> > You can then demonstrate that the MAC/Hash is secure if the
> > encryption algorithm has a bunch of (somewhat idealized) properties.
> 
> There's just one assumption needed for these proofs: namely, someone who
> doesn't know the key k can't distinguish AES_k from a uniform random
> permutation of the set of 16-byte strings. This was an explicit design
> criterion for AES.
> 
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
From pgut001@cs.auckland.ac.nz Tue Nov  2 05:21:24 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA2ALN6A010393
	for <saag@jis.mit.edu>; Tue, 2 Nov 2004 05:21:23 -0500 (EST)
Received: from smtpa.itss.auckland.ac.nz (mailhost.auckland.ac.nz
	[130.216.190.11])iA2ALKKr023883
	for <saag@mit.edu>; Tue, 2 Nov 2004 05:21:21 -0500 (EST)
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1])
	by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 8A25834053;
	Tue,  2 Nov 2004 23:21:19 +1300 (NZDT)
Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1])port 10024)
	with ESMTP id 25333-06; Tue,  2 Nov 2004 23:21:19 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz
	[130.216.33.152])
	by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id E0BD633F21;
	Tue,  2 Nov 2004 23:21:18 +1300 (NZDT)
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33])
	by iris.cs.auckland.ac.nz (Postfix) with ESMTP
	id D5AC637748; Tue,  2 Nov 2004 23:21:18 +1300 (NZDT)
Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian))
	id 1COvn4-0008Tj-00; Tue, 02 Nov 2004 23:21:26 +1300
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: James_Hughes@StorageTek.com, pbaker@verisign.com, saag@mit.edu
Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
Message-Id: <E1COvn4-0008Tj-00@medusa01>
Sender: pgut001 <pgut001@cs.auckland.ac.nz>
Date: Tue, 02 Nov 2004 23:21:26 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.539380
X-Mailman-Approved-At: Wed, 03 Nov 2004 10:34:41 -0500
cc: cfrg@ietf.org
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 02 Nov 2004 10:21:25 -0000

"Hallam-Baker, Phillip" <pbaker@verisign.com> writes:

>What we need is a policy layer for the whole application protocol layer
>stack. It should not be part of the individual protocols, it should be part
>of the DNS.

Hmm, time to dig out the policy issues quote... from an anonymous contributor
to PKIX, this being a reference to the UK comedy "Father Ted":

  Ted says that whenever he gets asked a religious question he doesn't
  understand he always responds with "Ah, that must be an ecumenical matter"
  which univerally produces nods of admiration at the profound wisdom of the
  statement. It seems that that the PKIX list equivalent is "Ah that must be a
  policy matter".

I believe that in both cases here "policy layer"/"policy matter" is being used
as a synonym for either "too-hard basket" or "someone else's problem".

Peter.
From djb-dsn-1099685913.66837@cr.yp.to Fri Nov  5 15:18:14 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA5KID6A016164
	for <saag@jis.mit.edu>; Fri, 5 Nov 2004 15:18:13 -0500 (EST)
Received: from stoneport.math.uic.edu (stoneport.math.uic.edu
	[131.193.178.160])iA5KI7Em010681
	for <saag@mit.edu>; Fri, 5 Nov 2004 15:18:12 -0500 (EST)
Received: (qmail 66838 invoked by uid 1016); 5 Nov 2004 20:18:33 -0000
Date: 5 Nov 2004 20:18:33 -0000
Message-ID: <20041105201833.66837.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: saag@mit.edu, cfrg@ietf.org
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References:
	<C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
	<tslk6t49lu4.fsf@cz.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000005
Spam-Alum-Time: 0.525430
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 05 Nov 2004 20:18:15 -0000

Sam Hartman writes:
> Can you explain how we would have handled the conversion from
> DES to AES for IPSec in an alternate universe where all the protocols
> worked as you desire?

May I ask how the conversion worked in your universe, and exactly what
conversion costs were avoided by the negotiation mechanism?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
From sommerfeld@sun.com Fri Nov  5 16:54:37 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA5Lsa6A018069
	for <saag@jis.mit.edu>; Fri, 5 Nov 2004 16:54:36 -0500 (EST)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	iA5LsXfP025784
	for <saag@mit.edu>; Fri, 5 Nov 2004 16:54:34 -0500 (EST)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA5LsPNH022942;
	Fri, 5 Nov 2004 14:54:25 -0700 (MST)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	ESMTP id iA5LsPQH024016;	Fri, 5 Nov 2004 16:54:25 -0500 (EST)
Received: from thunk.east.sun.com (localhost [127.0.0.1])
	iA5LsPPs018372;	Fri, 5 Nov 2004 16:54:25 -0500 (EST)
Received: (from sommerfeld@localhost)
	by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iA5LsLVT018371;
	Fri, 5 Nov 2004 16:54:21 -0500 (EST)
X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to
	sommerfeld@sun.com using -f
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
From: Bill Sommerfeld <sommerfeld@sun.com>
To: "D. J. Bernstein" <djb@cr.yp.to>
In-Reply-To: <20041105201833.66837.qmail@cr.yp.to>
References: 
	<C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
	<tslk6t49lu4.fsf@cz.mit.edu>  <20041105201833.66837.qmail@cr.yp.to>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1099691659.5870.283.camel@thunk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Fri, 05 Nov 2004 16:54:20 -0500
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.538379
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 05 Nov 2004 21:54:38 -0000

On Fri, 2004-11-05 at 15:18, D. J. Bernstein wrote:
> > Can you explain how we would have handled the conversion from
> > DES to AES for IPSec in an alternate universe where all the protocols
> > worked as you desire?
> 
> May I ask how the conversion worked in your universe, and exactly what
> conversion costs were avoided by the negotiation mechanism?

In our universe, we configured IPsec security gateways to accept both
AES and 3DES, then incrementally changed the preferred algorithm of the
clients. 

The conversion cost avoided was the need for a "flag day" during which
all clients needed to be changed simultaneously.

						- Bill

From hartmans@MIT.EDU Fri Nov  5 17:18:24 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA5MIN6A018628
	for <saag@jis.mit.edu>; Fri, 5 Nov 2004 17:18:23 -0500 (EST)
Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197])
	iA5MILfP027432
	for <saag@mit.edu>; Fri, 5 Nov 2004 17:18:21 -0500 (EST)
Received: by cz.mit.edu (Postfix, from userid 8042)
	id E2E12E0004; Fri,  5 Nov 2004 17:18:26 -0500 (EST)
To: "D. J. Bernstein" <djb@cr.yp.to>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References: <C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
	<tslk6t49lu4.fsf@cz.mit.edu> <20041105201833.66837.qmail@cr.yp.to>
From: Sam Hartman <hartmans@MIT.EDU>
Date: Fri, 05 Nov 2004 17:18:26 -0500
In-Reply-To: <20041105201833.66837.qmail@cr.yp.to> (D. J. Bernstein's
 message of "5 Nov 2004 20:18:33 -0000")
Message-ID: <tslr7n8ndn1.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.569985
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 05 Nov 2004 22:18:25 -0000


[I've dropped cfrg as this seems like more of a saag issue.]

>>>>> "D" == D J Bernstein <djb@cr.yp.to> writes:

    D> Sam Hartman writes:
    >> Can you explain how we would have handled the conversion from
    >> DES to AES for IPSec in an alternate universe where all the
    >> protocols worked as you desire?

    D> May I ask how the conversion worked in your universe, and
    D> exactly what conversion costs were avoided by the negotiation
    D> mechanism?

Sure.  IKE proposals include a list of acceptable algorithms.  So, So
my system can offer and start trying to use some new algorithm without
breaking interoperability.  The new algorithms start getting used over
time.  Eventually I make a policy decision that the old algorithm's
use is unacceptable and I would rather have no interoperability than
to use the old algorithm.  I tell my client to stop accepting the old
algorithm.


The conversion costs that are avoided are the need to upgrade all
peers before starting to use a new algorithm.  In addition, an
advantage over a system where algorithms are not even labeled is that
I know when interoperability is possible.

--Sam

From nw141292@binky.central.sun.com Fri Nov  5 17:55:22 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA5MtL6A019375
	for <saag@jis.mit.edu>; Fri, 5 Nov 2004 17:55:21 -0500 (EST)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	iA5MtIfP008006;	Fri, 5 Nov 2004 17:55:18 -0500 (EST)
Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14])
	by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iA5MtHs3019583;
	Fri, 5 Nov 2004 14:55:17 -0800 (PST)
Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104])
	with ESMTP id iA5MtGJh020094;	Fri, 5 Nov 2004 15:55:17 -0700 (MST)
Received: from binky.central.sun.com (localhost [127.0.0.1])
	iA5MslRZ470013;	Fri, 5 Nov 2004 16:54:47 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA5MskLJ470012;
	Fri, 5 Nov 2004 16:54:46 -0600 (CST)
Date: Fri, 5 Nov 2004 16:54:46 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Sam Hartman <hartmans@mit.edu>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Message-ID: <20041105225446.GI102351@binky.central.sun.com>
References:
	<C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp.ad.vrsn.com>
	<tslk6t49lu4.fsf@cz.mit.edu> <20041105201833.66837.qmail@cr.yp.to>
	<tslr7n8ndn1.fsf@cz.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <tslr7n8ndn1.fsf@cz.mit.edu>
User-Agent: Mutt/1.4.1i
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.580313
cc: "D. J. Bernstein" <djb@cr.yp.to>
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 05 Nov 2004 22:55:22 -0000

On Fri, Nov 05, 2004 at 05:18:26PM -0500, Sam Hartman wrote:
> >>>>> "D" == D J Bernstein <djb@cr.yp.to> writes:
> 
>     D> May I ask how the conversion worked in your universe, and
>     D> exactly what conversion costs were avoided by the negotiation
>     D> mechanism?
> 
> Sure.  IKE proposals include a list of acceptable algorithms.  So, So
> my system can offer and start trying to use some new algorithm without
> breaking interoperability.  The new algorithms start getting used over
> time.  Eventually I make a policy decision that the old algorithm's
> use is unacceptable and I would rather have no interoperability than
> to use the old algorithm.  I tell my client to stop accepting the old
> algorithm.
> 
> 
> The conversion costs that are avoided are the need to upgrade all
> peers before starting to use a new algorithm.  In addition, an
> advantage over a system where algorithms are not even labeled is that
> I know when interoperability is possible.

This applies to Kerberos V, SSHv2, and probably a few others.

And it works and works well enough, mind you, that it's not really
noticeable, particularly for protocols which derive keys for a
negotiated  session cipher from key exchange that is, ignoring DH group
size as a relation to symmetric ciphers' key strengths, not
cipher-specific (e.g., not Kerberos V, but certainly SSHv2).  Upgrade
two peers and suddenly they're using better ciphers than prior to the
upgrade.

Nico
-- 
From djb-dsn-1099731356.96474@cr.yp.to Sat Nov  6 03:55:33 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA68tW6A028354
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 03:55:32 -0500 (EST)
Received: from stoneport.math.uic.edu (stoneport.math.uic.edu
	[131.193.178.160])iA68tVZn023869
	for <saag@mit.edu>; Sat, 6 Nov 2004 03:55:31 -0500 (EST)
Received: (qmail 96475 invoked by uid 1016); 6 Nov 2004 08:55:56 -0000
Date: 6 Nov 2004 08:55:56 -0000
Message-ID: <20041106085556.96474.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: saag@mit.edu, cfrg@ietf.org
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References: <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.545479
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 08:55:33 -0000

> In our universe, we configured IPsec security gateways to accept both
> AES and 3DES, then incrementally changed the preferred algorithm of the
> clients. 

I was able to incrementally switch clients from telnet to ssh, where the
server supported both telnet and ssh. The client indicated its protocol
selection through its choice of TCP port number.

We already have many levels of protocol selection: IP protocol numbers,
TCP port numbers, and more. Was it impossible to encode a DES-vs.-AES
bit for IPSec into one of those numbers?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
From rja@extremenetworks.com Sat Nov  6 06:46:08 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA6Bk86A000612
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 06:46:08 -0500 (EST)
Received: from smtp1.extremenetworks.com (smtp1.extremenetworks.com
	[216.52.8.6])iA6Bk5Yl013773
	for <saag@mit.edu>; Sat, 6 Nov 2004 06:46:05 -0500 (EST)
Received: from [10.30.20.60] (unknown [10.30.20.60])
	by smtp1.extremenetworks.com (Postfix) with ESMTP
	id 85B5C7944; Sat,  6 Nov 2004 03:46:03 -0800 (PST)
In-Reply-To: <20041106085556.96474.qmail@cr.yp.to>
References:
	<6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <756D2920-2FE9-11D9-B79B-000D93B505E6@extremenetworks.com>
Content-Transfer-Encoding: 7bit
From: RJ Atkinson <rja@extremenetworks.com>
Subject: Re: [Cfrg] [saag] Algorithm upgrades
Date: Sat, 6 Nov 2004 06:46:12 -0500
To: saag@mit.edu
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.558743
cc: cfrg@ietf.org
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 11:46:09 -0000


On Nov 6, 2004, at 03:55, D. J. Bernstein wrote:
> I was able to incrementally switch clients from telnet to ssh, where 
> the
> server supported both telnet and ssh. The client indicated its protocol
> selection through its choice of TCP port number.
>
> We already have many levels of protocol selection: IP protocol numbers,
> TCP port numbers, and more. Was it impossible to encode a DES-vs.-AES
> bit for IPSec into one of those numbers?

	It would be remarkably bad protocol design to burn an additional
port number just to indicate an algorithm difference.  And, as others
have been kind enough to describe here, better ways to incrementally
upgrade IPsec clients are already supported and work well operationally.

	I really prefer the universe described by Bill Sommerfeld.

Cheers,

Ran Atkinson
rja@extremenetworks.com

From sommerfeld@sun.com Sat Nov  6 07:40:38 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA6Ceb6A001325
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 07:40:37 -0500 (EST)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	iA6CeaYd010750
	for <saag@mit.edu>; Sat, 6 Nov 2004 07:40:36 -0500 (EST)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA6CeYNH020019;
	Sat, 6 Nov 2004 05:40:34 -0700 (MST)
Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12])
	ESMTP id iA6CeVkt017115;	Sat, 6 Nov 2004 07:40:32 -0500 (EST)
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
From: Bill Sommerfeld <sommerfeld@sun.com>
To: "D. J. Bernstein" <djb@cr.yp.to>
In-Reply-To: <20041106085556.96474.qmail@cr.yp.to>
References: 
	<6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
Content-Type: text/plain; charset=ASCII
Message-Id: <1099744744.13142.65.camel@unknown.hamachi.org>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Sat, 06 Nov 2004 07:39:05 -0500
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.561700
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 12:40:38 -0000

On Sat, 2004-11-06 at 03:55, D. J. Bernstein wrote:
> > In our universe, we configured IPsec security gateways to accept both
> > AES and 3DES, then incrementally changed the preferred algorithm of the
> > clients. 
> 
> I was able to incrementally switch clients from telnet to ssh, where the
> server supported both telnet and ssh. The client indicated its protocol
> selection through its choice of TCP port number.

and then, perhaps unknown to you, ssh and sshd negotiated about a half
dozen algorithm parameters, each of which would require a bit or two to
encode even using the most compact encoding...

> We already have many levels of protocol selection: IP protocol numbers,
> TCP port numbers, and more. Was it impossible to encode a DES-vs.-AES
> bit for IPSec into one of those numbers?

in a word, yes, because there are only 16 bits of well-known port, and
you generally need much more than one bit to encode sufficiently rich
combinations of algorithm parameters.

					- Bill





From gis-saag@gmane.org Sat Nov  6 08:10:56 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA6DAt6A002035
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 08:10:55 -0500 (EST)
Received: from main.gmane.org (main.gmane.org [80.91.229.2])
	iA6DAoNk013810
	for <saag@mit.edu>; Sat, 6 Nov 2004 08:10:50 -0500 (EST)
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1CQQLB-0004pt-00
	for <saag@mit.edu>; Sat, 06 Nov 2004 14:10:49 +0100
Received: from c494102a.s-bi.bostream.se ([217.215.27.65])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <saag@mit.edu>; Sat, 06 Nov 2004 14:10:49 +0100
Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1
	(Debian))        id 1AlnuQ-0007hv-00
	for <saag@mit.edu>; Sat, 06 Nov 2004 14:10:49 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: saag@mit.edu
From: Simon Josefsson <jas@extundo.com>
Date: Sat, 06 Nov 2004 14:03:30 +0100
Lines: 49
Message-ID: <ilusm7nb04d.fsf@latte.josefsson.org>
References: <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
	<756D2920-2FE9-11D9-B79B-000D93B505E6@extremenetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
Cancel-Lock: sha1:OWOp1LRZHONcz1UYQZPt/V0yd8o=
Sender: news <news@sea.gmane.org>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.620122
Subject: [saag] Re: Algorithm upgrades
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 13:10:57 -0000

RJ Atkinson <rja@extremenetworks.com> writes:

> On Nov 6, 2004, at 03:55, D. J. Bernstein wrote:
>> I was able to incrementally switch clients from telnet to ssh, where
>> the
>> server supported both telnet and ssh. The client indicated its protocol
>> selection through its choice of TCP port number.
>>
>> We already have many levels of protocol selection: IP protocol numbers,
>> TCP port numbers, and more. Was it impossible to encode a DES-vs.-AES
>> bit for IPSec into one of those numbers?
>
> 	It would be remarkably bad protocol design to burn an additional
> port number just to indicate an algorithm difference.

Considering techniques like SRV (RFC 2782) that (ideally would) let
organizations chose which port telnet and ssh are used on, I'm not
sure that argument is convincing.

The fact that port numbers is a scarce resource is a problem.  To take
advantage of port numbers, to remove complex negotiation inside
protocols, is not a problem itself.

The cost of adding negotiation inside the protocol should not be
underestimated.  Burning port numbers instead might be justified, at
least I think it would be worth discussing it.

If negotiation was on the port-number level, implementations might be
considerably less complex.

And practically, the end user experience might be the same.  As long
as the client and server implementations support both the old and the
new protocol, whether the negotiation happens outside of the
protocols, or inside the protocols, seems like an implementation
detail.

> And, as others have been kind enough to describe here, better ways
> to incrementally upgrade IPsec clients are already supported and
> work well operationally.

Whether IPSEC works well depend on what problem you believe it should
solve.  If the problem is to protect communication on the Internet in
general, TLS seem far more successful than IPSEC.

Thanks,
Simon

PS.  Note that BOTH telnet and ssh are protocols that have their own
negotiation in them.

From ekr@rtfm.com Sat Nov  6 08:31:51 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA6DVn6A002297
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 08:31:49 -0500 (EST)
Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251])
	iA6DVlYd020587
	for <saag@mit.edu>; Sat, 6 Nov 2004 08:31:48 -0500 (EST)
Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242])
	by sierra.rtfm.com (Postfix) with ESMTP
	id AC8AE7500; Sat,  6 Nov 2004 05:50:44 -0800 (PST)
Received: by romeo.rtfm.com (Postfix, from userid 556)
	id 43C8C44AB0; Sat,  6 Nov 2004 05:31:44 -0800 (PST)
To: Simon Josefsson <jas@extundo.com>
Subject: Re: [saag] Re: Algorithm upgrades
References: <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
	<756D2920-2FE9-11D9-B79B-000D93B505E6@extremenetworks.com>
	<ilusm7nb04d.fsf@latte.josefsson.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 06 Nov 2004 05:31:43 -0800
In-Reply-To: <ilusm7nb04d.fsf@latte.josefsson.org> (Simon Josefsson's
 message of "Sat, 06 Nov 2004 14:03:30 +0100")
Message-ID: <kjmzxv9k8w.fsf@romeo.rtfm.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.540940
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: EKR <ekr@rtfm.com>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 13:31:51 -0000

Simon Josefsson <jas@extundo.com> writes:
> RJ Atkinson <rja@extremenetworks.com> writes:
>> And, as others have been kind enough to describe here, better ways
>> to incrementally upgrade IPsec clients are already supported and
>> work well operationally.
>
> Whether IPSEC works well depend on what problem you believe it should
> solve.  If the problem is to protect communication on the Internet in
> general, TLS seem far more successful than IPSEC.
TLS, of course, also contains a negotiation scheme.

-Ekr
From moore@cs.utk.edu Sat Nov  6 09:31:36 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA6EVX6A003165
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 09:31:33 -0500 (EST)
Received: from cardinal.mail.pas.earthlink.net
	(cardinal.mail.pas.earthlink.net [207.217.121.226])iA6EVUNk014365
	for <saag@mit.edu>; Sat, 6 Nov 2004 09:31:30 -0500 (EST)
Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182]
	helo=[192.168.0.4])
	by cardinal.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1CQRbF-0006UG-00; Sat, 06 Nov 2004 06:31:29 -0800
In-Reply-To: <ilusm7nb04d.fsf@latte.josefsson.org>
References:
	<6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
	<756D2920-2FE9-11D9-B79B-000D93B505E6@extremenetworks.com>
	<ilusm7nb04d.fsf@latte.josefsson.org>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8DB09B9C-3000-11D9-95D3-000393DB5366@cs.utk.edu>
Content-Transfer-Encoding: 7bit
From: Keith Moore <moore@cs.utk.edu>
Subject: Re: [saag] Re: Algorithm upgrades
Date: Sat, 6 Nov 2004 09:31:31 -0500
To: Simon Josefsson <jas@extundo.com>
X-Mailer: Apple Mail (2.619)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.620503
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 14:31:36 -0000

>>> I was able to incrementally switch clients from telnet to ssh, where
>>> the server supported both telnet and ssh. The client indicated its 
>>> protocol
>>> selection through its choice of TCP port number.
>>>
>>> We already have many levels of protocol selection: IP protocol 
>>> numbers,
>>> TCP port numbers, and more. Was it impossible to encode a DES-vs.-AES
>>> bit for IPSec into one of those numbers?
>>
>> 	It would be remarkably bad protocol design to burn an additional
>> port number just to indicate an algorithm difference.
>
> Considering techniques like SRV (RFC 2782) that (ideally would) let
> organizations chose which port telnet and ssh are used on, I'm not
> sure that argument is convincing.
>
> The fact that port numbers is a scarce resource is a problem.  To take
> advantage of port numbers, to remove complex negotiation inside
> protocols, is not a problem itself.

there are several problems with using port numbers to do protocol 
feature negotiation.

for various reasons (including the existence of NAPTs, and historical 
circumstances) it should not be assumed that port A at IP address X and 
port B at IP address X are different versions of the same service (even 
when those services are similar, such as for ssh and telnet), or even 
the same host.   tunnels from one address:port to another are 
increasingly used to work around NAT restrictions, and in some cases, 
to provide a means for an IPv6-only host to have some services 
accessible via IPv4.

also, for clients that try to negotiate which protocol feature to use 
by trying one port, and if that fails, trying another, this may 
introduce a potential for an attacker to force the client to downgrade 
to the less secure protocol - say, by forging TCP resets or ICMP port 
unreachable messages in response to attempts to connect to the 
preferred port.  whereas with a single port protocol these would just 
be denial-of-service attacks.  this should at least be analyzed.

From phoffman@imc.org Sat Nov  6 10:59:48 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA6Fxl6A004305
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 10:59:47 -0500 (EST)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	iA6FxjaM020546
	for <saag@mit.edu>; Sat, 6 Nov 2004 10:59:46 -0500 (EST)
Received: from [10.20.30.249] (user-2ivelit.dialup.mindspring.com
	[165.247.86.93])	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6FxMY1040248;
	Sat, 6 Nov 2004 07:59:39 -0800 (PST)	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110426bdb2a00ae044@[10.20.30.249]>
In-Reply-To: <20041106085556.96474.qmail@cr.yp.to>
References: 
 <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
 <20041106085556.96474.qmail@cr.yp.to>
Date: Sat, 6 Nov 2004 10:48:06 -0500
To: "D. J. Bernstein" <djb@cr.yp.to>, saag@mit.edu, cfrg@ietf.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.657939
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 15:59:49 -0000

At 8:55 AM +0000 11/6/04, D. J. Bernstein wrote:
>Was it impossible to encode a DES-vs.-AES
>bit for IPSec into one of those numbers?

No, it was not. And we arguably should have done so. At the risk of 
causing my brain to explode, I will agree with Dan and disagree with 
Bill and Ran here.

Statements like "not really noticeable" and "work well operationally" 
are absurdly out of touch with typical IPsec VPN users. Even the best 
UIs for gateways force low-ability admins and lower-ability end users 
to make multiple selections of things that they don't (and shouldn't 
need to!) understand.

The IPsec WG has recently agreed to two "UI suites" for sets of 
algorithms that we think make sense for the vast majority of users. 
These UI suites don't prevent fine-grained negotiation of crypto 
details, but they allow vendors to have one or two buttons, plus an 
optional third that says "advanced users: get lots more choices here".

If we knew we would come this this point when IKEv1 was developed, it 
would make imminent sense to allocate three port numbers to it: one 
for button A, one for button B, and one for fine-grained 
negotiations. It is arguable that we should have done that for IKEv2; 
no one suggested it, but in hindsight it seems quite reasonable.

Pre-defined suites *are* TCP port-level choices. A responding system 
that can only do Suite A can announce that simply by listening on 
that port, and the initiator knows their capability. Systems that 
also want negotiation can.

The scarcity of port numbers is over-rated relative to having simpler 
and more robust security protocols.

--Paul Hoffman, Director
--Internet Mail Consortium
From pbaker@verisign.com Sat Nov  6 12:42:46 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA6Hgj6A005718
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 12:42:45 -0500 (EST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	iA6HgiSp019849
	for <saag@mit.edu>; Sat, 6 Nov 2004 12:42:44 -0500 (EST)
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com
	[65.205.251.54])iA6HgYMp017977;	Sat, 6 Nov 2004 09:42:34 -0800 (PST)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <W2HFNWNN>; Sat, 6 Nov 2004 09:42:34 -0800
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BED20@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Paul Hoffman / IMC'" <phoffman@imc.org>,
   "D. J. Bernstein"
	 <djb@cr.yp.to>, saag@mit.edu, cfrg@ietf.org
Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades
Date: Sat, 6 Nov 2004 09:42:34 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.659390
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 17:42:46 -0000

I agree with Paul's analysis of the problem, if not the solution.

IPSEC is a miserable, miserable protocol to use. It only works in many cases
because of ad hoc infrastructure allowances that are outside the
specification.

It is certainly no occasion for a victory dance. If I was going to design a
VPN from scratch I would simply tunnel over SSL and completely ignore the
IPSEC stack. IPSEC is useless to me unless it works in the hotel I am
staying in. SSL works through NAT reliably. IPSEC does not.

People need to decide whether the purpose of the protocol design is to meet
the real needs of users or to amuse ourselves. 




> -----Original Message-----
> From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On 
> Behalf Of Paul Hoffman / IMC
> Sent: Saturday, November 06, 2004 10:48 AM
> To: D. J. Bernstein; saag@mit.edu; cfrg@ietf.org
> Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
> 
> 
> At 8:55 AM +0000 11/6/04, D. J. Bernstein wrote:
> >Was it impossible to encode a DES-vs.-AES
> >bit for IPSec into one of those numbers?
> 
> No, it was not. And we arguably should have done so. At the risk of 
> causing my brain to explode, I will agree with Dan and disagree with 
> Bill and Ran here.
> 
> Statements like "not really noticeable" and "work well operationally" 
> are absurdly out of touch with typical IPsec VPN users. Even the best 
> UIs for gateways force low-ability admins and lower-ability end users 
> to make multiple selections of things that they don't (and shouldn't 
> need to!) understand.
> 
> The IPsec WG has recently agreed to two "UI suites" for sets of 
> algorithms that we think make sense for the vast majority of users. 
> These UI suites don't prevent fine-grained negotiation of crypto 
> details, but they allow vendors to have one or two buttons, plus an 
> optional third that says "advanced users: get lots more choices here".
> 
> If we knew we would come this this point when IKEv1 was developed, it 
> would make imminent sense to allocate three port numbers to it: one 
> for button A, one for button B, and one for fine-grained 
> negotiations. It is arguable that we should have done that for IKEv2; 
> no one suggested it, but in hindsight it seems quite reasonable.
> 
> Pre-defined suites *are* TCP port-level choices. A responding system 
> that can only do Suite A can announce that simply by listening on 
> that port, and the initiator knows their capability. Systems that 
> also want negotiation can.
> 
> The scarcity of port numbers is over-rated relative to having simpler 
> and more robust security protocols.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
> 
From gis-saag@gmane.org Sat Nov  6 14:07:06 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA6J706A006979
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 14:07:00 -0500 (EST)
Received: from main.gmane.org (main.gmane.org [80.91.229.2])
	iA6J6wga028257
	for <saag@mit.edu>; Sat, 6 Nov 2004 14:06:59 -0500 (EST)
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1CQVtq-0004Qz-00
	for <saag@mit.edu>; Sat, 06 Nov 2004 20:06:58 +0100
Received: from c494102a.s-bi.bostream.se ([217.215.27.65])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <saag@mit.edu>; Sat, 06 Nov 2004 20:06:58 +0100
Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1
	(Debian))        id 1AlnuQ-0007hv-00
	for <saag@mit.edu>; Sat, 06 Nov 2004 20:06:58 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: saag@mit.edu
From: Simon Josefsson <jas@extundo.com>
Date: Sat, 06 Nov 2004 20:06:53 +0100
Lines: 45
Message-ID: <ilu8y9ebxv6.fsf@latte.josefsson.org>
References: <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
	<756D2920-2FE9-11D9-B79B-000D93B505E6@extremenetworks.com>
	<ilusm7nb04d.fsf@latte.josefsson.org>
	<8DB09B9C-3000-11D9-95D3-000393DB5366@cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
Cancel-Lock: sha1:DAI5OogeZa2dMT7iurZVz41xrbw=
Sender: news <news@sea.gmane.org>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.609718
Subject: [saag] Re: Algorithm upgrades
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 19:07:06 -0000

Keith Moore <moore@cs.utk.edu> writes:

> there are several problems with using port numbers to do protocol 
> feature negotiation.
>
> for various reasons (including the existence of NAPTs, and historical 
> circumstances) it should not be assumed that port A at IP address X and 
> port B at IP address X are different versions of the same service (even 
> when those services are similar, such as for ssh and telnet), or even 
> the same host.   tunnels from one address:port to another are 
> increasingly used to work around NAT restrictions, and in some cases, 
> to provide a means for an IPv6-only host to have some services 
> accessible via IPv4.

Cannot SRV be used to solve this problem?

> also, for clients that try to negotiate which protocol feature to use 
> by trying one port, and if that fails, trying another, this may 
> introduce a potential for an attacker to force the client to downgrade 
> to the less secure protocol - say, by forging TCP resets or ICMP port 
> unreachable messages in response to attempts to connect to the 
> preferred port.  whereas with a single port protocol these would just 
> be denial-of-service attacks.  this should at least be analyzed.

Right.  However, in some situations it might be acceptable to rely
only on policy to control which protocol features are acceptable or
not, instead of a in-protocol negotiation.

As an example, if I remember correctly, transition from Kerberos IV to
Kerberos V happened by changing to new ports (port 750 to port 88).
Some implementations support(ed) both protocols.  Presumably, the
risks involved were acceptable.

As another example, I believe that the complexity and weaknesses in
the telnet negotiation protocol was itself a reason ssh was developed.
My point is that negotiation in a protocol can become "too complex" to
be useful.  I'll let others comment on this aspect regarding IKE.  If
instead a new port, say 24 (telnet is port 23), was allocated to mean
DES encrypted telnet, and later on port (say) 26 was allocated to mean
AES encrypted telnet, perhaps encrypted telnet would have been more
successful.  If someone want to tinker with blowfish encrypted telnet,
or even integrity protected encrypted telnet (e.g., AES-CCM), they
could use SRV or some non-standard port.

Thanks.

From djb-dsn-1099768374.35404@cr.yp.to Sat Nov  6 14:12:31 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA6JCU6A007065
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 14:12:30 -0500 (EST)
Received: from stoneport.math.uic.edu (stoneport.math.uic.edu
	[131.193.178.160])iA6JCTOm018873
	for <saag@mit.edu>; Sat, 6 Nov 2004 14:12:29 -0500 (EST)
Received: (qmail 35418 invoked by uid 1016); 6 Nov 2004 19:12:54 -0000
Date: 6 Nov 2004 19:12:54 -0000
Message-ID: <20041106191254.35404.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: saag@mit.edu, cfrg@ietf.org
Subject: Re: [Cfrg] [saag] Algorithm upgrades
References:
	<6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
	<756D2920-2FE9-11D9-B79B-000D93B505E6@extremenetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.573955
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 19:12:32 -0000

RJ Atkinson writes:
> It would be remarkably bad protocol design to burn an additional
> port number just to indicate an algorithm difference.

Why?

An obvious advantage of putting ssh on a separate port from telnet is
that---since UNIX makes it easy to have separate programs for separate
ports---sshd was easier to write, and telnetd was easier to turn off.
If they had been on the same port, with the ssh encryption as a telnet
option, then implementors would have had fewer options.

Similarly, it has been helpful to put mail submission on a separate port
from SMTP, and it has been helpful to put HTTP on a separate port from
FTP, and it would have been extremely helpful to put DNS caches on a
separate port from DNS servers. What's the disadvantage?

I don't claim that UNIX has the same modularity for handling separate
IPSecDES and IPSecAES protocols, but I still don't see what you think
the disadvantage is. Do you think we're running out of IP protocol
numbers? Were you also saying that the use of both 50 and 51 for IPSec
(and UDP port 500) was ``remarkably bad protocol design''?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
From moore@cs.utk.edu Sat Nov  6 14:38:27 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA6JcQ6A007588
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 14:38:26 -0500 (EST)
Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50])
	iA6JcOOm007743
	for <saag@mit.edu>; Sat, 6 Nov 2004 14:38:24 -0500 (EST)
Received: from localhost (klutz [127.0.0.1])
	by klutz.cs.utk.edu (Postfix) with ESMTP id 14A7540151;
	Sat,  6 Nov 2004 14:38:24 -0500 (EST)
Received: from klutz.cs.utk.edu ([127.0.0.1])
 by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 29959-05; Sat,  6 Nov 2004 14:38:22 -0500 (EST)
Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com
	[66.149.133.182])
	by klutz.cs.utk.edu (Postfix) with ESMTP id 6DA324001F;
	Sat,  6 Nov 2004 14:38:22 -0500 (EST)
Date: Sat, 6 Nov 2004 14:37:00 -0500
From: Keith Moore <moore@cs.utk.edu>
To: Simon Josefsson <jas@extundo.com>
Subject: Re: [saag] Re: Algorithm upgrades
Message-Id: <20041106143700.6fbfcf12.moore@cs.utk.edu>
In-Reply-To: <ilu8y9ebxv6.fsf@latte.josefsson.org>
References: <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
	<756D2920-2FE9-11D9-B79B-000D93B505E6@extremenetworks.com>
	<ilusm7nb04d.fsf@latte.josefsson.org>
	<8DB09B9C-3000-11D9-95D3-000393DB5366@cs.utk.edu>
	<ilu8y9ebxv6.fsf@latte.josefsson.org>
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at cs.utk.edu by ClamAV and McAfee
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.642992
cc: saag@mit.edu
cc: moore@cs.utk.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sat, 06 Nov 2004 19:38:28 -0000

> > there are several problems with using port numbers to do protocol 
> > feature negotiation.
> >
> > for various reasons (including the existence of NAPTs, and historical 
> > circumstances) it should not be assumed that port A at IP address X and 
> > port B at IP address X are different versions of the same service (even 
> > when those services are similar, such as for ssh and telnet), or even 
> > the same host.   tunnels from one address:port to another are 
> > increasingly used to work around NAT restrictions, and in some cases, 
> > to provide a means for an IPv6-only host to have some services 
> > accessible via IPv4.
> 
> Cannot SRV be used to solve this problem?

it would be possible to associate multiple SRV records with a domain such
that when you looked up domain+service you'd get a list of domains+ports to
use.  however the question remains - are those at the same host or different
hosts?  the binding between domains and hosts is fuzzy.  the fact that
multiple SRV records exist for a domain does not mean that those are all
at the same host.  

also, SRV only works when you control your own DNS servers.  so it has
limited applicability.

> > also, for clients that try to negotiate which protocol feature to use 
> > by trying one port, and if that fails, trying another, this may 
> > introduce a potential for an attacker to force the client to downgrade 
> > to the less secure protocol - say, by forging TCP resets or ICMP port 
> > unreachable messages in response to attempts to connect to the 
> > preferred port.  whereas with a single port protocol these would just 
> > be denial-of-service attacks.  this should at least be analyzed.
> 
> Right.  However, in some situations it might be acceptable to rely
> only on policy to control which protocol features are acceptable or
> not, instead of a in-protocol negotiation.

correct.  this is not an argument against separate ports so much as it's
an argument that clients not try to automagically discover which port
to use through trial and error.  though experience with POP and IMAP and SMTP
clients seems to indicate that in practice, if you have separate ports for a
secure and non-secure service, clients will try to automagically discover
which ports to use.

> As an example, if I remember correctly, transition from Kerberos IV to
> Kerberos V happened by changing to new ports (port 750 to port 88).
> Some implementations support(ed) both protocols.  Presumably, the
> risks involved were acceptable.

seems like for the implementations I used, Kerberos hosts had to be explicitly
configured as to which port to use to talk to the server.  the server could
support both K4 and K5, but that's not the same thing as automagically
selecting the host-to-server protocol.  and as long as Kerberos requires 
explicit configuration of hosts and servers anyway (e.g. hosts have to
be configured as to which server to use, host keys have to be generated
and distributed to hosts, etc.) it's hard to see what the advantage would
be in having clients automatically figure out which port to use.

Keith
From jwkckid1@ix.netcom.com Sat Nov  6 22:17:15 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA73H86A013223
	for <saag@jis.mit.edu>; Sat, 6 Nov 2004 22:17:09 -0500 (EST)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	iA73H6QC011606
	for <saag@mit.edu>; Sat, 6 Nov 2004 22:17:06 -0500 (EST)
Received: from 1cust35.tnt36.dfw9.da.uu.net ([67.234.81.35]
	helo=ix.netcom.com)	by smtp6.mindspring.com with esmtp (Exim 3.33 #1)
	id 1CQdY4-0007Ls-00; Sat, 06 Nov 2004 22:17:01 -0500
Message-ID: <418DAF6B.B3DACA18@ix.netcom.com>
Date: Sat, 06 Nov 2004 21:15:25 -0800
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References: <C6DDA43B91BFDA49AA2F1E473732113E010BED20@mou1wnexm05.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.729442
cc: "vinton g. cerf" <vinton.g.cerf@mci.com>
cc: "D. J. Bernstein" <djb@cr.yp.to>
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 07 Nov 2004 03:17:15 -0000

Phillip and all,

  I agree entirely with Phil here. However there are some whom
still wish to push IPsec such as Vint Cerf, for reasons that defy
good operational reason.  IPsec as it currently stands, is not
effective in any real world sense...

Hallam-Baker, Phillip wrote:

> I agree with Paul's analysis of the problem, if not the solution.
>
> IPSEC is a miserable, miserable protocol to use. It only works in many cases
> because of ad hoc infrastructure allowances that are outside the
> specification.
>
> It is certainly no occasion for a victory dance. If I was going to design a
> VPN from scratch I would simply tunnel over SSL and completely ignore the
> IPSEC stack. IPSEC is useless to me unless it works in the hotel I am
> staying in. SSL works through NAT reliably. IPSEC does not.
>
> People need to decide whether the purpose of the protocol design is to meet
> the real needs of users or to amuse ourselves.
>
> > -----Original Message-----
> > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On
> > Behalf Of Paul Hoffman / IMC
> > Sent: Saturday, November 06, 2004 10:48 AM
> > To: D. J. Bernstein; saag@mit.edu; cfrg@ietf.org
> > Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
> >
> >
> > At 8:55 AM +0000 11/6/04, D. J. Bernstein wrote:
> > >Was it impossible to encode a DES-vs.-AES
> > >bit for IPSec into one of those numbers?
> >
> > No, it was not. And we arguably should have done so. At the risk of
> > causing my brain to explode, I will agree with Dan and disagree with
> > Bill and Ran here.
> >
> > Statements like "not really noticeable" and "work well operationally"
> > are absurdly out of touch with typical IPsec VPN users. Even the best
> > UIs for gateways force low-ability admins and lower-ability end users
> > to make multiple selections of things that they don't (and shouldn't
> > need to!) understand.
> >
> > The IPsec WG has recently agreed to two "UI suites" for sets of
> > algorithms that we think make sense for the vast majority of users.
> > These UI suites don't prevent fine-grained negotiation of crypto
> > details, but they allow vendors to have one or two buttons, plus an
> > optional third that says "advanced users: get lots more choices here".
> >
> > If we knew we would come this this point when IKEv1 was developed, it
> > would make imminent sense to allocate three port numbers to it: one
> > for button A, one for button B, and one for fine-grained
> > negotiations. It is arguable that we should have done that for IKEv2;
> > no one suggested it, but in hindsight it seems quite reasonable.
> >
> > Pre-defined suites *are* TCP port-level choices. A responding system
> > that can only do Suite A can announce that simply by listening on
> > that port, and the initiator knows their capability. Systems that
> > also want negotiation can.
> >
> > The scarcity of port numbers is over-rated relative to having simpler
> > and more robust security protocols.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> > _______________________________________________
> > saag mailing list
> > saag@mit.edu
> > https://jis.mit.edu/mailman/listinfo/saag
> >
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From ekr@rtfm.com Sun Nov  7 08:21:50 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA7DLn6A021363
	for <saag@jis.mit.edu>; Sun, 7 Nov 2004 08:21:49 -0500 (EST)
Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251])
	iA7DLjh4001942
	for <saag@mit.edu>; Sun, 7 Nov 2004 08:21:46 -0500 (EST)
Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242])
	by sierra.rtfm.com (Postfix) with ESMTP
	id 24F8C73E9; Sun,  7 Nov 2004 05:40:46 -0800 (PST)
Received: by romeo.rtfm.com (Postfix, from userid 556)
	id 33C4944ACF; Sun,  7 Nov 2004 05:21:44 -0800 (PST)
To: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References: <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
	<p06110426bdb2a00ae044@[10.20.30.249]>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 07 Nov 2004 05:21:43 -0800
In-Reply-To: <p06110426bdb2a00ae044@[10.20.30.249]> (Paul Hoffman's message
 of "Sat, 6 Nov 2004 10:48:06 -0500")
Message-ID: <kjactt23rs.fsf@romeo.rtfm.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity, berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.546933
cc: "D. J. Bernstein" <djb@cr.yp.to>
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: EKR <ekr@rtfm.com>
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 07 Nov 2004 13:21:51 -0000

Paul Hoffman / IMC <phoffman@imc.org> writes:

> At 8:55 AM +0000 11/6/04, D. J. Bernstein wrote:
>>Was it impossible to encode a DES-vs.-AES
>>bit for IPSec into one of those numbers?
>
> No, it was not. And we arguably should have done so. At the risk of
> causing my brain to explode, I will agree with Dan and disagree with
> Bill and Ran here.
>
> Statements like "not really noticeable" and "work well operationally"
> are absurdly out of touch with typical IPsec VPN users. Even the best
> UIs for gateways force low-ability admins and lower-ability end users
> to make multiple selections of things that they don't (and shouldn't
> need to!) understand.
Maybe so, but why blame algorithm negotiation for this? Both SSH 
and TLS have algorithm negotiation and in practice noone even
notices. 

-Ekr
From jari.arkko@piuha.net Sun Nov  7 11:25:49 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA7GPm6A023520
	for <saag@jis.mit.edu>; Sun, 7 Nov 2004 11:25:48 -0500 (EST)
Received: from p2.piuha.net (p2.piuha.net [131.160.192.2])
	iA7GPkEk002157
	for <saag@mit.edu>; Sun, 7 Nov 2004 11:25:46 -0500 (EST)
Received: from piuha.net (p2.piuha.net [131.160.192.2])
	by p2.piuha.net (Postfix) with ESMTP id BF6EF8987C;
	Sun,  7 Nov 2004 18:25:42 +0200 (EET)
Message-ID: <418E36BA.5050308@piuha.net>
Date: Sun, 07 Nov 2004 16:52:42 +0200
From: Jari Arkko <jari.arkko@piuha.net>
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: EKR <ekr@rtfm.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References:
	<6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>	<p06110426bdb2a00ae044@[10.20.30.249]>
	<kjactt23rs.fsf@romeo.rtfm.com>
In-Reply-To: <kjactt23rs.fsf@romeo.rtfm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.571157
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: jari.arkko@piuha.net
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 07 Nov 2004 16:25:49 -0000

Eric Rescorla wrote:

>>Statements like "not really noticeable" and "work well operationally"
>>are absurdly out of touch with typical IPsec VPN users. Even the best
>>UIs for gateways force low-ability admins and lower-ability end users
>>to make multiple selections of things that they don't (and shouldn't
>>need to!) understand.
> 
> Maybe so, but why blame algorithm negotiation for this? Both SSH 
> and TLS have algorithm negotiation and in practice noone even
> notices. 

I agree that the algorithm negotiation is not the reason.
If you look at the difference between the SSL and IPsec
models, I think the difficulties come from two areas:

o  Separation of the application and the security layer. In
    SSL, applications are in direct control of the security
    layer and the configuration of the security layer also
    goes through the application's user interface. Given
    that the application knows its security requirements
    and its traffic flows, it knows what traffic needs to
    be protected and how. So you can skip, for instance,
    port number and address pattern specifications. Personally,
    I like entering IPv6 addresses in hex to configuration
    files, but I'm not quite sure most people on the planet
    agree with me.

o  Harder requirements. For instance, IPsec applications
    typically require all parties to be provisioned with
    keys and configuration, whereas in SSL some applications
    work with just server-side keys.

--Jari

From djb-dsn-1099858318.70219@cr.yp.to Sun Nov  7 15:11:36 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA7KBZ6A026860
	for <saag@jis.mit.edu>; Sun, 7 Nov 2004 15:11:35 -0500 (EST)
Received: from stoneport.math.uic.edu (stoneport.math.uic.edu
	[131.193.178.160])iA7KBWCD025201
	for <saag@mit.edu>; Sun, 7 Nov 2004 15:11:33 -0500 (EST)
Received: (qmail 70220 invoked by uid 1017); 7 Nov 2004 20:11:58 -0000
Date: 7 Nov 2004 20:11:58 -0000
Message-ID: <20041107201158.70219.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: saag@mit.edu, cfrg@ietf.org
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References:
	<6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.555768
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 07 Nov 2004 20:11:36 -0000

Bill Sommerfeld writes:
> there are only 16 bits of well-known port, and you generally need much
> more than one bit to encode sufficiently rich combinations of
> algorithm parameters

Sufficient for what, exactly?

A moment ago we were talking about the upgrade from DES to AES. That's a
one-bit switch, and obviously an important one. AES is faster and more
secure; DES is on the way out, and AES is on the way in.

Now you seem to have in mind a much more complicated set of options, and
an unstated reason that it's important to have all those options (but no
others!). What's the reason? How do you get from that reason to the
exact list of options that you have in mind?

Where can I find the archived analysis of how the exact list of options
was created? Are you sure that the options weren't simply accreted by
the typical ``Let's support every conceivable option we can document''
committee-think, without regard for actual costs and benefits?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
From pbaker@verisign.com Sun Nov  7 17:25:28 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA7MPR6A029115
	for <saag@jis.mit.edu>; Sun, 7 Nov 2004 17:25:27 -0500 (EST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	iA7MPQra005416
	for <saag@mit.edu>; Sun, 7 Nov 2004 17:25:26 -0500 (EST)
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com
	[65.205.251.54])iA7MPNVe001069;	Sun, 7 Nov 2004 14:25:23 -0800 (PST)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <W2HFP40Y>; Sun, 7 Nov 2004 14:25:23 -0800
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BED22@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'D. J. Bernstein'" <djb@cr.yp.to>, saag@mit.edu, cfrg@ietf.org
Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades
Date: Sun, 7 Nov 2004 14:25:22 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.621824
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 07 Nov 2004 22:25:28 -0000

I agree on the sentiment, disagree on the method.

There are three viable ways to signal the change:

1) Use a new port
2) Define a DNS RR to describe the configuration of the protocol
3) Use a prefixed DNS TXT record to describe the configuration

(1) and (2) suffer from the limited ports problem, only 1024 well known
ports, 65K TOTAL, same for RRs. The use of new RRs also has the severe
disadvantage of not working for about 50% of the deployed infrastructure
(and don't believe the fariy stories that claim otherwise, it ain't true
unless your definition of 'working' does not require production strength
code).

_telnet._security.example.com TXT "encrypt=AES,DES; auth=RSA288382811k=="

Deployable, viable, simple, workable.

The Internet needs a policy layer, the people who say that is too hard
should be told to go home, shut up and not bother the grownups who do know
how to make it work.

	Phill

 

> -----Original Message-----
> From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On 
> Behalf Of D. J. Bernstein
> Sent: Sunday, November 07, 2004 3:12 PM
> To: saag@mit.edu; cfrg@ietf.org
> Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
> 
> 
> Bill Sommerfeld writes:
> > there are only 16 bits of well-known port, and you 
> generally need much 
> > more than one bit to encode sufficiently rich combinations of 
> > algorithm parameters
> 
> Sufficient for what, exactly?
> 
> A moment ago we were talking about the upgrade from DES to 
> AES. That's a one-bit switch, and obviously an important one. 
> AES is faster and more secure; DES is on the way out, and AES 
> is on the way in.
> 
> Now you seem to have in mind a much more complicated set of 
> options, and an unstated reason that it's important to have 
> all those options (but no others!). What's the reason? How do 
> you get from that reason to the exact list of options that 
> you have in mind?
> 
> Where can I find the archived analysis of how the exact list 
> of options was created? Are you sure that the options weren't 
> simply accreted by the typical ``Let's support every 
> conceivable option we can document'' committee-think, without 
> regard for actual costs and benefits?
> 
> ---D. J. Bernstein, Associate Professor, Department of 
> Mathematics, Statistics, and Computer Science, University of 
> Illinois at Chicago
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
> 
From jwkckid1@ix.netcom.com Sun Nov  7 22:11:47 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA83Bk6A003677
	for <saag@jis.mit.edu>; Sun, 7 Nov 2004 22:11:46 -0500 (EST)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net
	[207.69.200.148])iA83BhvG014562
	for <saag@mit.edu>; Sun, 7 Nov 2004 22:11:44 -0500 (EST)
Received: from 1cust184.tnt59.dfw5.da.uu.net ([67.203.43.184]
	helo=ix.netcom.com)
	by granger.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1CQzwT-0000u1-00; Sun, 07 Nov 2004 22:11:41 -0500
Message-ID: <418EFFAA.D8423C07@ix.netcom.com>
Date: Sun, 07 Nov 2004 21:10:03 -0800
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References: <C6DDA43B91BFDA49AA2F1E473732113E010BED22@mou1wnexm05.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.709601
cc: "'D. J. Bernstein'" <djb@cr.yp.to>
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 08 Nov 2004 03:11:48 -0000

Phillip and all,

  I agree with you fully here.  Especially your last sentence below.
However as you likely already know that are still many within the
IETF that are not likely to agree with you here.  Some of which
are more adept at gamesmanship and who's knowledge base is
dated, that will fight your nicely and simply stated approach/method
of choice here..

Hallam-Baker, Phillip wrote:

> I agree on the sentiment, disagree on the method.
>
> There are three viable ways to signal the change:
>
> 1) Use a new port
> 2) Define a DNS RR to describe the configuration of the protocol
> 3) Use a prefixed DNS TXT record to describe the configuration
>
> (1) and (2) suffer from the limited ports problem, only 1024 well known
> ports, 65K TOTAL, same for RRs. The use of new RRs also has the severe
> disadvantage of not working for about 50% of the deployed infrastructure
> (and don't believe the fariy stories that claim otherwise, it ain't true
> unless your definition of 'working' does not require production strength
> code).
>
> _telnet._security.example.com TXT "encrypt=AES,DES; auth=RSA288382811k=="
>
> Deployable, viable, simple, workable.
>
> The Internet needs a policy layer, the people who say that is too hard
> should be told to go home, shut up and not bother the grownups who do know
> how to make it work.
>
>         Phill
>
>
>
> > -----Original Message-----
> > From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On
> > Behalf Of D. J. Bernstein
> > Sent: Sunday, November 07, 2004 3:12 PM
> > To: saag@mit.edu; cfrg@ietf.org
> > Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
> >
> >
> > Bill Sommerfeld writes:
> > > there are only 16 bits of well-known port, and you
> > generally need much
> > > more than one bit to encode sufficiently rich combinations of
> > > algorithm parameters
> >
> > Sufficient for what, exactly?
> >
> > A moment ago we were talking about the upgrade from DES to
> > AES. That's a one-bit switch, and obviously an important one.
> > AES is faster and more secure; DES is on the way out, and AES
> > is on the way in.
> >
> > Now you seem to have in mind a much more complicated set of
> > options, and an unstated reason that it's important to have
> > all those options (but no others!). What's the reason? How do
> > you get from that reason to the exact list of options that
> > you have in mind?
> >
> > Where can I find the archived analysis of how the exact list
> > of options was created? Are you sure that the options weren't
> > simply accreted by the typical ``Let's support every
> > conceivable option we can document'' committee-think, without
> > regard for actual costs and benefits?
> >
> > ---D. J. Bernstein, Associate Professor, Department of
> > Mathematics, Statistics, and Computer Science, University of
> > Illinois at Chicago
> >
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/cfrg
> >
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From pbaker@verisign.com Sun Nov  7 23:14:40 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA84Ed6A004860
	for <saag@jis.mit.edu>; Sun, 7 Nov 2004 23:14:39 -0500 (EST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74])
	iA84EbIB007917
	for <saag@mit.edu>; Sun, 7 Nov 2004 23:14:38 -0500 (EST)
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com
	[65.205.251.54])iA84EQbA016066;	Sun, 7 Nov 2004 20:14:30 -0800 (PST)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service
	(5.5.2657.72)	id <WPBZAN6W>; Sun, 7 Nov 2004 20:14:25 -0800
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BED24@mou1wnexm05.vcorp.ad.vrsn.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Jeff Williams'" <jwkckid1@ix.netcom.com>,
   "Hallam-Baker, Phillip"
	 <pbaker@verisign.com>
Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades
Date: Sun, 7 Nov 2004 20:14:25 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.743241
cc: "'D. J. Bernstein'" <djb@cr.yp.to>
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 08 Nov 2004 04:14:40 -0000



> From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] 

> Phillip and all,
> 
>   I agree with you fully here.  Especially your last sentence 
> below. However as you likely already know that are still many 
> within the IETF that are not likely to agree with you here.  
> Some of which are more adept at gamesmanship and who's 
> knowledge base is dated, that will fight your nicely and 
> simply stated approach/method of choice here..

People can play what games they like in their personal playpen. But the real
world has ceased listening to them. I will be in DC next week, but not at
the IETF.

It has been obvious to me for eight years that the inability to upgrade
deployed protocols is the critical flaw of the IETF stack. The generally
agreed way to correct that problem from an architectural standpoint is
through a policy layer.

The only response I have ever got back is passive aggressive dismissals, oh
that's hard, needs lots of thought, too hard, problems you would not
understand, etc.

Then we have the, yes that's great, just stick my personal project into your
critical path types.




> Hallam-Baker, Phillip wrote:
> 
> > I agree on the sentiment, disagree on the method.
> >
> > There are three viable ways to signal the change:
> >
> > 1) Use a new port
> > 2) Define a DNS RR to describe the configuration of the protocol
> > 3) Use a prefixed DNS TXT record to describe the configuration
> >
> > (1) and (2) suffer from the limited ports problem, only 1024 well 
> > known ports, 65K TOTAL, same for RRs. The use of new RRs 
> also has the 
> > severe disadvantage of not working for about 50% of the deployed 
> > infrastructure (and don't believe the fariy stories that claim 
> > otherwise, it ain't true unless your definition of 
> 'working' does not 
> > require production strength code).
> >
> > _telnet._security.example.com TXT "encrypt=AES,DES; 
> > auth=RSA288382811k=="
> >
> > Deployable, viable, simple, workable.
> >
> > The Internet needs a policy layer, the people who say that 
> is too hard 
> > should be told to go home, shut up and not bother the 
> grownups who do 
> > know how to make it work.
> >
> >         Phill
> >
> >
> >
> > > -----Original Message-----
> > > From: cfrg-bounces@ietf.org 
> [mailto:cfrg-bounces@ietf.org] On Behalf 
> > > Of D. J. Bernstein
> > > Sent: Sunday, November 07, 2004 3:12 PM
> > > To: saag@mit.edu; cfrg@ietf.org
> > > Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
> > >
> > >
> > > Bill Sommerfeld writes:
> > > > there are only 16 bits of well-known port, and you
> > > generally need much
> > > > more than one bit to encode sufficiently rich combinations of 
> > > > algorithm parameters
> > >
> > > Sufficient for what, exactly?
> > >
> > > A moment ago we were talking about the upgrade from DES to AES. 
> > > That's a one-bit switch, and obviously an important one. AES is 
> > > faster and more secure; DES is on the way out, and AES is 
> on the way 
> > > in.
> > >
> > > Now you seem to have in mind a much more complicated set 
> of options, 
> > > and an unstated reason that it's important to have all 
> those options 
> > > (but no others!). What's the reason? How do you get from 
> that reason 
> > > to the exact list of options that you have in mind?
> > >
> > > Where can I find the archived analysis of how the exact list of 
> > > options was created? Are you sure that the options weren't simply 
> > > accreted by the typical ``Let's support every conceivable 
> option we 
> > > can document'' committee-think, without regard for actual 
> costs and 
> > > benefits?
> > >
> > > ---D. J. Bernstein, Associate Professor, Department of 
> Mathematics, 
> > > Statistics, and Computer Science, University of Illinois 
> at Chicago
> > >
> > > _______________________________________________
> > > Cfrg mailing list
> > > Cfrg@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/cfrg
> > >
> > _______________________________________________
> > saag mailing list
> > saag@mit.edu
> > https://jis.mit.edu/mailman/listinfo/saag
> 
> Regards,
> --
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 134k members/stakeholders 
> strong!) "Be precise in the use of words and expect precision 
> from others" -
>     Pierre Abelard
> 
> "If the probability be called P; the injury, L; and the 
> burden, B; liability depends upon whether B is less than L 
> multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947] 
> ===============================================================
> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security 
> IDNS. div. of Information Network Eng.  INEG. INC. E-Mail 
> jwkckid1@ix.netcom.com  Registered Email addr with the USPS 
> Contact Number: 214-244-4827
> 
> 
From jwkckid1@ix.netcom.com Mon Nov  8 03:10:58 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA88Av6A008402
	for <saag@jis.mit.edu>; Mon, 8 Nov 2004 03:10:57 -0500 (EST)
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net
	[207.69.200.157])iA88AuQE029803
	for <saag@mit.edu>; Mon, 8 Nov 2004 03:10:56 -0500 (EST)
Received: from 1cust184.tnt59.dfw5.da.uu.net ([67.203.43.184]
	helo=ix.netcom.com)
	by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1CR4c0-0001GM-00; Mon, 08 Nov 2004 03:10:52 -0500
Message-ID: <418F45C8.A586873F@ix.netcom.com>
Date: Mon, 08 Nov 2004 02:09:15 -0800
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
References: <C6DDA43B91BFDA49AA2F1E473732113E010BED24@mou1wnexm05.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.757534
cc: "'D. J. Bernstein'" <djb@cr.yp.to>
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 08 Nov 2004 08:10:59 -0000

Phillip and all,

Hallam-Baker, Phillip wrote:

> > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com]
>
> > Phillip and all,
> >
> >   I agree with you fully here.  Especially your last sentence
> > below. However as you likely already know that are still many
> > within the IETF that are not likely to agree with you here.
> > Some of which are more adept at gamesmanship and who's
> > knowledge base is dated, that will fight your nicely and
> > simply stated approach/method of choice here..
>
> People can play what games they like in their personal playpen. But the real
> world has ceased listening to them. I will be in DC next week, but not at
> the IETF.
>
> It has been obvious to me for eight years that the inability to upgrade
> deployed protocols is the critical flaw of the IETF stack. The generally
> agreed way to correct that problem from an architectural standpoint is
> through a policy layer.
>
> The only response I have ever got back is passive aggressive dismissals, oh
> that's hard, needs lots of thought, too hard, problems you would not
> understand, etc.
>
> Then we have the, yes that's great, just stick my personal project into your
> critical path types.

 Yes, I have gotten allot of the same kind of responses over the past
4-5 years or worse myself from many old timers in the IETF myself.
To me this shows a near total lack of consideration and willingness
to belly up to the bar as it were..  I believe that this has become a
systemic problem now and as Richard Clark had once indicated
some very radical and specific changes are needed in order to
adequately address this broad problem...

>
>
> > Hallam-Baker, Phillip wrote:
> >
> > > I agree on the sentiment, disagree on the method.
> > >
> > > There are three viable ways to signal the change:
> > >
> > > 1) Use a new port
> > > 2) Define a DNS RR to describe the configuration of the protocol
> > > 3) Use a prefixed DNS TXT record to describe the configuration
> > >
> > > (1) and (2) suffer from the limited ports problem, only 1024 well
> > > known ports, 65K TOTAL, same for RRs. The use of new RRs
> > also has the
> > > severe disadvantage of not working for about 50% of the deployed
> > > infrastructure (and don't believe the fariy stories that claim
> > > otherwise, it ain't true unless your definition of
> > 'working' does not
> > > require production strength code).
> > >
> > > _telnet._security.example.com TXT "encrypt=AES,DES;
> > > auth=RSA288382811k=="
> > >
> > > Deployable, viable, simple, workable.
> > >
> > > The Internet needs a policy layer, the people who say that
> > is too hard
> > > should be told to go home, shut up and not bother the
> > grownups who do
> > > know how to make it work.
> > >
> > >         Phill
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: cfrg-bounces@ietf.org
> > [mailto:cfrg-bounces@ietf.org] On Behalf
> > > > Of D. J. Bernstein
> > > > Sent: Sunday, November 07, 2004 3:12 PM
> > > > To: saag@mit.edu; cfrg@ietf.org
> > > > Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
> > > >
> > > >
> > > > Bill Sommerfeld writes:
> > > > > there are only 16 bits of well-known port, and you
> > > > generally need much
> > > > > more than one bit to encode sufficiently rich combinations of
> > > > > algorithm parameters
> > > >
> > > > Sufficient for what, exactly?
> > > >
> > > > A moment ago we were talking about the upgrade from DES to AES.
> > > > That's a one-bit switch, and obviously an important one. AES is
> > > > faster and more secure; DES is on the way out, and AES is
> > on the way
> > > > in.
> > > >
> > > > Now you seem to have in mind a much more complicated set
> > of options,
> > > > and an unstated reason that it's important to have all
> > those options
> > > > (but no others!). What's the reason? How do you get from
> > that reason
> > > > to the exact list of options that you have in mind?
> > > >
> > > > Where can I find the archived analysis of how the exact list of
> > > > options was created? Are you sure that the options weren't simply
> > > > accreted by the typical ``Let's support every conceivable
> > option we
> > > > can document'' committee-think, without regard for actual
> > costs and
> > > > benefits?
> > > >
> > > > ---D. J. Bernstein, Associate Professor, Department of
> > Mathematics,
> > > > Statistics, and Computer Science, University of Illinois
> > at Chicago
> > > >
> > > > _______________________________________________
> > > > Cfrg mailing list
> > > > Cfrg@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/cfrg
> > > >
> > > _______________________________________________
> > > saag mailing list
> > > saag@mit.edu
> > > https://jis.mit.edu/mailman/listinfo/saag
> >
> > Regards,
> > --
> > Jeffrey A. Williams
> > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders
> > strong!) "Be precise in the use of words and expect precision
> > from others" -
> >     Pierre Abelard
> >
> > "If the probability be called P; the injury, L; and the
> > burden, B; liability depends upon whether B is less than L
> > multiplied by
> > P: i.e., whether B is less than PL."
> > United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> > ===============================================================
> > Updated 1/26/04
> > CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> > IDNS. div. of Information Network Eng.  INEG. INC. E-Mail
> > jwkckid1@ix.netcom.com  Registered Email addr with the USPS
> > Contact Number: 214-244-4827
> >
> >

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827


From vincent.bufferne@capgemini.com Mon Nov  8 03:23:47 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA88Nk6A008692
	for <saag@jis.mit.edu>; Mon, 8 Nov 2004 03:23:46 -0500 (EST)
Received: from mxepar01.capgemini.com (MXEPAR01.capgemini.com [194.3.247.82])
	iA88NhQE008811
	for <saag@mit.edu>; Mon, 8 Nov 2004 03:23:44 -0500 (EST)
Received: from mxipar01.capgemini.com (prvmta2 [194.3.224.82])
	iA88Ngc4011601
	for <saag@mit.edu>; Mon, 8 Nov 2004 09:23:42 +0100 (MET)
Received: from prvmta2.capgemini.com (localhost [127.0.0.1])
	iA88NfOB002871
	for <saag@mit.edu>; Mon, 8 Nov 2004 09:23:41 +0100 (MET)
Received: from pasteur2.capgemini.fr (smtp.capgemini.fr [10.67.1.90])by 
	prvmta2.capgemini.com (8.12.11/8.12.11) with ESMTP id iA88Nf7e002868;
	Mon, 8	 Nov 2004 09:23:41 +0100 (MET)
Received: from pasteur.capgemini.fr (localhost [127.0.0.1])by 
	pasteur2.capgemini.fr (8.12.10/8.12.10) with ESMTP id iA88Nejd007012;
	Mon, 8	 Nov 2004 09:23:40 +0100 (MET)
Received: from VBUFFERNXP ([10.68.150.254])by pasteur.capgemini.fr 
	(8.12.10/8.12.10) with SMTP id iA88NcUg006943;
	Mon, 8 Nov 2004 09:23:39 	+0100 (MET)
Message-ID: <005d01c4c56c$289aa5e0$fe96440a@VBUFFERNXP>
From: "Vincent Bufferne" <vincent.bufferne@capgemini.com>
To: <saag@mit.edu>
References: <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stort
	ek.com><20041106085556.96474.qmail@cr.yp.to> 
	<p06110426bdb2a00ae044@[10.20.30.249]>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Date: Mon, 8 Nov 2004 09:22:58 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-imss-version: 2.5
X-imss-result: Passed
X-imss-scores: Clean:37.71086 C:19 M:2 S:5 R:5
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.562322
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 08 Nov 2004 08:23:47 -0000


> The IPsec WG has recently agreed to two "UI suites" for sets of 
> algorithms that we think make sense for the vast majority of users. 
> These UI suites don't prevent fine-grained negotiation of crypto 
> details, but they allow vendors to have one or two buttons, plus an 
> optional third that says "advanced users: get lots more choices here".
> 
Is there a document that presents these "UI suites"?

Thanks,

Vincent

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.

From smb@research.att.com Mon Nov  8 08:05:18 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA8D5H6A013601
	for <saag@jis.mit.edu>; Mon, 8 Nov 2004 08:05:17 -0500 (EST)
Received: from machshav.com (machshav.com [147.28.0.16])
	iA8D5G9X017517
	for <saag@mit.edu>; Mon, 8 Nov 2004 08:05:16 -0500 (EST)
Received: by machshav.com (Postfix, from userid 512)
	id 7F439FB256; Mon,  8 Nov 2004 13:05:15 +0000 (UTC)
Received: from berkshire.research.att.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP
	id 14443FB24A; Mon,  8 Nov 2004 13:05:15 +0000 (UTC)
Received: from research.att.com (localhost [127.0.0.1])
	by berkshire.research.att.com (Postfix) with ESMTP
	id BBB211AE9F; Mon,  8 Nov 2004 08:05:13 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades 
In-Reply-To: Your message of "Sun, 07 Nov 2004 14:25:22 PST."
	<C6DDA43B91BFDA49AA2F1E473732113E010BED22@mou1wnexm05.vcorp.ad.vrsn.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 08 Nov 2004 08:05:13 -0500
Message-Id: <20041108130513.BBB211AE9F@berkshire.research.att.com>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.524279
cc: "'D. J. Bernstein'" <djb@cr.yp.to>
cc: cfrg@ietf.org
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 08 Nov 2004 13:05:18 -0000

In message <C6DDA43B91BFDA49AA2F1E473732113E010BED22@mou1wnexm05.vcorp.ad.vrsn.

>
>The Internet needs a policy layer, the people who say that is too hard
>should be told to go home, shut up and not bother the grownups who do know
>how to make it work.


Phil -- please read RFC 3184.  You're welcome to propose technical 
idea, no matter how different than the norm (and no matter how much 
many people disagree with them).  You're not welcome to indulge in 
childish name-calling on IETF mailing lists.

		--Steve Bellovin
		Security AD

From HugheJP@LOUISVILLE.STORTEK.COM Fri Nov  5 17:31:20 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA5MVJ6A018935
	for <saag@jis.mit.edu>; Fri, 5 Nov 2004 17:31:19 -0500 (EST)
Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146])
	iA5MVGfP012981
	for <saag@mit.edu>; Fri, 5 Nov 2004 17:31:17 -0500 (EST)
Received: from sherman.stortek.com (localhost [127.0.0.1])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id iA5MVEDY021240
	for <saag@mit.edu>; Fri, 5 Nov 2004 15:31:16 -0700 (MST)
Received: from lsv-msg07.louisville.stortek.com
	(lsv-msg07.louisville.stortek.com [129.80.18.77])
	by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id iA5MVEur021237;
	Fri, 5 Nov 2004 15:31:14 -0700 (MST)
Received: by lsv-msg07.louisville.stortek.com with Internet Mail Service
	(5.5.2653.19)	id <WJHMLPJS>; Fri, 5 Nov 2004 15:31:14 -0700
Message-ID: <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
From: "Hughes, James P" <HugheJP@LOUISVILLE.STORTEK.COM>
To: "'sommerfeld@sun.com'" <sommerfeld@sun.com>,
   "'djb@cr.yp.to'"
	 <djb@cr.yp.to>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Date: Fri, 5 Nov 2004 15:30:58 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.579035
X-Mailman-Approved-At: Mon, 08 Nov 2004 10:00:58 -0500
cc: "'cfrg@ietf.org'" <cfrg@ietf.org>
cc: "'saag@mit.edu'" <saag@mit.edu>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 05 Nov 2004 22:31:21 -0000

I agree. My company loves these "policy knobs". Without this kind of
negotiation in the standard, vendors will do it themselves in an
incompatible proprietary way making the standard less valuable. 


-----Original Message-----
From: saag-bounces@mit.edu <saag-bounces@mit.edu>
To: D. J. Bernstein <djb@cr.yp.to>
CC: cfrg@ietf.org <cfrg@ietf.org>; saag@mit.edu <saag@mit.edu>
Sent: Fri Nov 05 14:54:20 2004
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades

On Fri, 2004-11-05 at 15:18, D. J. Bernstein wrote:
> > Can you explain how we would have handled the conversion from
> > DES to AES for IPSec in an alternate universe where all the protocols
> > worked as you desire?
> 
> May I ask how the conversion worked in your universe, and exactly what
> conversion costs were avoided by the negotiation mechanism?

In our universe, we configured IPsec security gateways to accept both
AES and 3DES, then incrementally changed the preferred algorithm of the
clients. 

The conversion cost avoided was the need for a "flag day" during which
all clients needed to be changed simultaneously.

						- Bill

_______________________________________________
saag mailing list
saag@mit.edu
https://jis.mit.edu/mailman/listinfo/saag
From kivinen@iki.fi Sun Nov  7 09:25:24 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA7EPN6A022286
	for <saag@jis.mit.edu>; Sun, 7 Nov 2004 09:25:23 -0500 (EST)
Received: from mail.kivinen.iki.fi ([83.145.195.1])iA7EPIh4017166
	for <saag@mit.edu>; Sun, 7 Nov 2004 09:25:18 -0500 (EST)
Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1])
	by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA7EPERm010126
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Sun, 7 Nov 2004 16:25:14 +0200 (EET)
Received: (from kivinen@localhost)
	by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA7EPBfj010123;
	Sun, 7 Nov 2004 16:25:11 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to
	kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16782.12359.737060.244930@fireball.kivinen.iki.fi>
Date: Sun, 7 Nov 2004 16:25:11 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Simon Josefsson <jas@extundo.com>
Subject: [saag] Re: Algorithm upgrades
In-Reply-To: <ilu8y9ebxv6.fsf@latte.josefsson.org>
References: <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
	<756D2920-2FE9-11D9-B79B-000D93B505E6@extremenetworks.com>
	<ilusm7nb04d.fsf@latte.josefsson.org>
	<8DB09B9C-3000-11D9-95D3-000393DB5366@cs.utk.edu>
	<ilu8y9ebxv6.fsf@latte.josefsson.org>
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Edit-Time: 18 min
X-Total-Time: 18 min
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.672412
X-Mailman-Approved-At: Mon, 08 Nov 2004 10:00:58 -0500
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Sun, 07 Nov 2004 14:25:25 -0000

Simon Josefsson writes:
> As an example, if I remember correctly, transition from Kerberos IV to
> Kerberos V happened by changing to new ports (port 750 to port 88).
> Some implementations support(ed) both protocols.  Presumably, the
> risks involved were acceptable.

The problem with changing port numbers is that it requires exterenal
negotation to know which protocol to us (i.e. to which port to
connect), or you need to try both. If the other end is configured like
most systems seem to that they simply drop packets to unknown ports,
it would mean that you need to waith until the negotiation times out
before you really know that the other host is not running that
service (and you do not want to fall back to the older / weaker
version just because it decided to answer first (or attacked made it
to answer first)).

People do consider delays in the process quite bad, thus that was the
reason IKEv1 and IKEv2 do use the same port, and instead use the
version number in the packet to identify the version. This way even
old IKEv1 implementations can send error message back. Without it
mostimplementations would either be configured to use IKEv1 to get rid
of delay, or try IKEv2 first, and when that times out try IKEv1 then
(or, try IKEv1 and IKEv2 simultaneously, consuming extra resources,
and making the combined implementations even more complex).

> As another example, I believe that the complexity and weaknesses in
> the telnet negotiation protocol was itself a reason ssh was developed.

Not really.

In the university nobody used telnet at all. Everybody used rsh
because of the automatic login feature it allowed (i.e. .rhosts). When
Tatu started writing ssh, he took the model from the protocol that
everybody used, i.e. rsh, not from protocol that nobody used (telnet).

Also the reason it uses different port than telnet and rsh, is that
using different port allowed adminstrators to install it as a separate
deamon, thus they could install it without touching the system
provided telnet or rsh deamons. This made big impact on the
deployability of the ssh.

And, yes there was extra configuration information selecting the port.
If user typed rsh, then it used rsh port, if user typed ssh, it
selected ssh port :-)

This extra "configuration" information was distributed in the
newsletters, etc, i.e. the computer center of the university asked
their users to use ssh instead of telnet or rsh.

There was also these timeouts, after computer center stoped telnet and
rsh deamons, i.e. after that user would get connection refused or
timeout error from telnet/rsh command, and then he would connect the
computer center and ask what is wrong, and after instructions modified
his own configuration file (in his brains) to use ssh instead...

> My point is that negotiation in a protocol can become "too complex" to
> be useful.  I'll let others comment on this aspect regarding IKE.  If
> instead a new port, say 24 (telnet is port 23), was allocated to mean
> DES encrypted telnet, and later on port (say) 26 was allocated to mean
> AES encrypted telnet, perhaps encrypted telnet would have been more
> successful.  If someone want to tinker with blowfish encrypted telnet,
> or even integrity protected encrypted telnet (e.g., AES-CCM), they
> could use SRV or some non-standard port.

Both using the port number and using the negotiation inside the
protocol itself are useful, and sometimes you need to use one, and
sometimes another. For the IKEv1 and IKEv2 this was hard call. For
using port numbers to negotiate crypto parameters of the IPsec, I do
not think there was even options to use port numbers. We do not have
those 2 universally approved UI suites, which would have meant that
every implementation would still have had to implement the full
negotiation, and in that case port numbers for fixed suites would have
simply made the implementations even more complex. 
-- 
kivinen@safenet-inc.com
From pgut001@cs.auckland.ac.nz Sun Nov  7 20:24:01 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA81O06A002092
	for <saag@jis.mit.edu>; Sun, 7 Nov 2004 20:24:00 -0500 (EST)
Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz
	[130.216.190.11])iA81NwP1017156
	for <saag@mit.edu>; Sun, 7 Nov 2004 20:23:59 -0500 (EST)
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1])
	by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 5C4FF34257;
	Mon,  8 Nov 2004 14:23:57 +1300 (NZDT)
Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1])port 10024)
	with ESMTP id 01507-04; Mon,  8 Nov 2004 14:23:57 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz
	[130.216.33.152])
	by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id C993234246;
	Mon,  8 Nov 2004 14:23:56 +1300 (NZDT)
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33])
	by iris.cs.auckland.ac.nz (Postfix) with ESMTP
	id 95EC437744; Mon,  8 Nov 2004 14:23:56 +1300 (NZDT)
Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian))
	id 1CQyGG-0008OY-00; Mon, 08 Nov 2004 14:24:00 +1300
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cfrg@ietf.org, djb@cr.yp.to, pbaker@verisign.com, phoffman@imc.org,
   saag@mit.edu
Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BED20@mou1wnexm05.vcorp.ad.vrsn.com>
Message-Id: <E1CQyGG-0008OY-00@medusa01>
Sender: pgut001 <pgut001@cs.auckland.ac.nz>
Date: Mon, 08 Nov 2004 14:24:00 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.611459
X-Mailman-Approved-At: Mon, 08 Nov 2004 10:00:58 -0500
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 08 Nov 2004 01:24:01 -0000

"Hallam-Baker, Phillip" <pbaker@verisign.com> writes:

>It is certainly no occasion for a victory dance. If I was going to design a
>VPN from scratch I would simply tunnel over SSL and completely ignore the
>IPSEC stack. IPSEC is useless to me unless it works in the hotel I am staying
>in. SSL works through NAT reliably. IPSEC does not.

One of the most practical designs I've seen uses TLS for the initial
negotiation (completely sidestepping the IKE quagmire) and then ESP for
transport. The best-known implementation of this is OpenVPN, which is more or
less the SSH of VPNs, it's easily available, runs on everything, and works out
of the box without any need for endless fiddling and configuration problems.
Just like SSH did years ago, it seems to be slipping in everywhere for more or
less the same reasons that SSH was adopted.

(There was a plan to do an RFC on this a while back but it kinda fizzled out,
 mostly because everyone just grabs OpenVPN and uses it rather than bothering
 to read/write about it.  Again, it's a strong parallel to the original SSH).

Peter.

From alten@attbi.com Sun Nov  7 21:01:49 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA821m6A002741
	for <saag@jis.mit.edu>; Sun, 7 Nov 2004 21:01:48 -0500 (EST)
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56])
	iA821jvG010908
	for <saag@mit.edu>; Sun, 7 Nov 2004 21:01:45 -0500 (EST)
Received: from alten.comcast.net
	(c-24-5-244-112.client.comcast.net[24.5.244.112])
	by comcast.net (sccrmhc12) with SMTP
	id <20041108020144012009qsmqe>          (Authid: a.alton);
	Mon, 8 Nov 2004 02:01:45 +0000
Message-Id: <4.3.2.7.1.20041107174534.03737dc8@mail.comcast.net>
X-Sender: a.alton@mail.comcast.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 07 Nov 2004 18:01:48 -0800
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>,
   "'James Hughes'" <James_Hughes@StorageTek.com>,
   "<saag@mit.edu> <saag@mit.edu>" <saag@mit.edu>
From: Alex Alten <alten@attbi.com>
Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BECF3@mou1wnexm05.vcorp
 .ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.584337
X-Mailman-Approved-At: Mon, 08 Nov 2004 10:00:58 -0500
cc: "<cfrg@ietf.org>" <cfrg@ietf.org>
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 08 Nov 2004 02:01:50 -0000

At 05:09 PM 11/1/2004 -0800, Hallam-Baker, Phillip wrote:
> >1. _New_ protocols that are being design should include the ability to
> >negotiate algorithms. This is just good hygiene. If this is not
> >formalized, it should be.
>
>I strongly disagree. History has showed that negotiation mechanisms can lead
>to worse security problems than they are meant to address. The IETF has
>certainly showed an exceptional ability to overcomplicate them.

I agree with Phillip (sorry David McGrew).  It is bad enough to deal with 
keying
materials for one type of algorithm (say a cipher like AES), without having
to deal with all the headaches of dealing with two or more known algorithms
plus an unknown number of future algorithms.  Based on my own experience
plus witnessing other designs (like IPSec and ATM), when it comes to security
systems (or secure networks), simpler really is much better.

I think that the age of dealing with multiple ciphers is drawing to a 
close. Unless
I'm greatly mistaken, AES should be sufficient for just about anything, 
probably
for the next 50 years.  One could put a flag in for the encryption 
algorithm just
in case an upgrade is needed in 2054.

However, the same probably can't yet be said of hashes.

- Alex


--

Alex Alten
alten@ATTBI.com

From phoffman@imc.org Mon Nov  8 10:04:39 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iA8F4b6A016478
	for <saag@jis.mit.edu>; Mon, 8 Nov 2004 10:04:38 -0500 (EST)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	iA8F4a9X001242
	for <saag@mit.edu>; Mon, 8 Nov 2004 10:04:36 -0500 (EST)
Received: from [130.129.135.64] ([130.129.135.64])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8F4H0Z081385;
	Mon, 8 Nov 2004 07:04:24 -0800 (PST)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110410bdb538aeac3a@[130.129.135.64]>
In-Reply-To: <005d01c4c56c$289aa5e0$fe96440a@VBUFFERNXP>
References: 
 <6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stort
 ek.com><20041106085556.96474.qmail@cr.yp.to> 
 <p06110426bdb2a00ae044@[10.20.30.249]>
 <005d01c4c56c$289aa5e0$fe96440a@VBUFFERNXP>
Date: Mon, 8 Nov 2004 09:53:00 -0500
To: "Vincent Bufferne" <vincent.bufferne@capgemini.com>, <saag@mit.edu>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.669731
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 08 Nov 2004 15:04:39 -0000

At 9:22 AM +0100 11/8/04, Vincent Bufferne wrote:
>  > The IPsec WG has recently agreed to two "UI suites" for sets of
>>  algorithms that we think make sense for the vast majority of users.
>>  These UI suites don't prevent fine-grained negotiation of crypto
>>  details, but they allow vendors to have one or two buttons, plus an
>>  optional third that says "advanced users: get lots more choices here".
>>
>Is there a document that presents these "UI suites"?

draft-ietf-ipsec-ui-suites-06.txt, which has approved as a BCP RFC.

--Paul Hoffman, Director
--Internet Mail Consortium
From jaltman@columbia.edu Wed Nov 10 13:47:00 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iAAIkx6A017886
	for <saag@jis.mit.edu>; Wed, 10 Nov 2004 13:47:00 -0500 (EST)
Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu
	[128.59.206.19])iAAIksZj011960
	for <saag@mit.edu>; Wed, 10 Nov 2004 13:46:54 -0500 (EST)
Received: from [130.129.134.169] ([130.129.134.169])
	(user=jaltman mech=PLAIN bits=0)iAAIkNMn003573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <saag@mit.edu>; Wed, 10 Nov 2004 13:46:53 -0500 (EST)
Message-ID: <41926230.2070707@columbia.edu>
Date: Wed, 10 Nov 2004 13:47:12 -0500
From: Jeffrey Altman <jaltman@columbia.edu>
Organization: Mass
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: saag@mit.edu
Subject: Re: [saag] Re: Algorithm upgrades
References:
	<6C588E657934BB438F46B92D4BBCCD8A763F07@EXCHVS2.louisville.stortek.com>
	<20041106085556.96474.qmail@cr.yp.to>
	<756D2920-2FE9-11D9-B79B-000D93B505E6@extremenetworks.com>
	<ilusm7nb04d.fsf@latte.josefsson.org>
	<8DB09B9C-3000-11D9-95D3-000393DB5366@cs.utk.edu>
	<ilu8y9ebxv6.fsf@latte.josefsson.org>
In-Reply-To: <ilu8y9ebxv6.fsf@latte.josefsson.org>
X-Enigmail-Version: 0.84.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="------------ms080107050908010901040207"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.42
X-Scanned-By: MIMEDefang 2.48 on 128.59.206.19
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.632641
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 10 Nov 2004 18:47:01 -0000

This is a cryptographically signed message in MIME format.

--------------ms080107050908010901040207
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Simon Josefsson wrote:

> As another example, I believe that the complexity and weaknesses in
> the telnet negotiation protocol was itself a reason ssh was developed.

I would disagree with this assessment.  SSH and Telnet overlap on one
application use of the SSH protocol.  They are not equivalnet.  Neither
are Telnet and RSH.  The reason separate port numbers are used is that
the protocols are in fact different.  A server which implements one can
not be expected to handle the other.

> My point is that negotiation in a protocol can become "too complex" to
> be useful.  I'll let others comment on this aspect regarding IKE.  If
> instead a new port, say 24 (telnet is port 23), was allocated to mean
> DES encrypted telnet, and later on port (say) 26 was allocated to mean
> AES encrypted telnet, perhaps encrypted telnet would have been more
> successful.  If someone want to tinker with blowfish encrypted telnet,
> or even integrity protected encrypted telnet (e.g., AES-CCM), they
> could use SRV or some non-standard port.

TELNET option negotiations can be used to produce a secure protocol.
This has been done with the START_TLS option with or without channel
bindings to Kerberos 5 or SRP mutual authentication.  There is no need
to use a separate port for this.

I would argue that the reason so many TELNET is considered too complex 
and as a result that a large number of implementations are broken
has very little to do with the quality of the published RFCs.  Instead,
my experience has been that the majority of implementors have failed
to read the RFCs but instead of decided to base their implementations
on duplicating the traffic seen on the wire or on broken open source
distributions.

Implementing separate ports cannot be used to avoid this problem.
In fact, the use of multiple ports to select the strength of 
authentication or confideniality simply opens up additional attacks
against the clients which can be used to manipulate the outcome of
the desired result.

Jeffrey Altman


--------------ms080107050908010901040207
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC
AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4
WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT
SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l
ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2
+nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp
z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9
WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02
lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r
1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s
dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0
eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe
L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M
CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1
MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx
HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A
Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M
3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs
Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A
B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD
GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf
u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq
YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH
lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b
rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU
njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT
ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB
MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx
NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0
ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK
mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/
cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8
YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4
oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j
cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy
LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4
Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg
T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB
MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw
CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMDQxMTEwMTg0NzEyWjAjBgkqhkiG9w0BCQQxFgQUTLC5xn45UHBkDoEl5lksTQF4/eEw
UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN
AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD
VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B
CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB
AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAGH/t92dEB3cX0StjQ5UK/GRhl3E/TA3S54c6I+k2
rwyO224/pU4+PRPdJM2Oe52zLSGG9qSYT79qjJp1D88N3u1mAHw2Z79cCSgzk4mixQ4El41q
+0lFim1tHbbx8lq/+uW2/A/hOOAxB4xN40FeQ2twjOzcOGHHtO5VSX2h1knKn5LTbvbWN/hg
U2u5d7hJlNEVD6y5xe0j5HYTLhF71M/+7rtrTxvdrgPIzPIcHF6hthXOlupLG6SHgQfBBpbf
tI8qL7xpMtOe8I4ZCQCbv+GdMYBVvps2RzeWkb4QPj+O9z2vVGuOR8E4Aa0BHzJrkOymr3vb
EB9AY/wseYr8GwAAAAAAAA==
--------------ms080107050908010901040207--
From housley@vigilsec.com Thu Nov 11 10:26:59 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iABFQw6A011671
	for <saag@jis.mit.edu>; Thu, 11 Nov 2004 10:26:58 -0500 (EST)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	iABFQvGh028380
	for <saag@mit.edu>; Thu, 11 Nov 2004 10:26:57 -0500 (EST)
Received: (qmail 24513 invoked by uid 0); 11 Nov 2004 15:26:54 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.135.212)
  by woodstock.binhost.com with SMTP; 11 Nov 2004 15:26:54 -0000
Message-Id: <6.1.2.0.2.20041110211613.049ceeb0@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Thu, 11 Nov 2004 23:15:00 -0500
To: saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.059958
Spam-Alum-Time: 0.497099
cc: RBennett@certicom.com
cc: jjstasa@orion.ncsc.mil
Subject: [saag] Slides for the SAAG session on Nov 11th
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 11 Nov 2004 15:26:59 -0000


http://www.machshav.com/~smb/saag-11-2004/

From gregory-ietf@earthlink.net Thu Nov 11 16:28:54 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iABLSs6A019485
	for <saag@jis.mit.edu>; Thu, 11 Nov 2004 16:28:54 -0500 (EST)
Received: from smtpauth09.mail.atl.earthlink.net
	(smtpauth09.mail.atl.earthlink.net [209.86.89.69])iABLSLcV029009
	for <saag@mit.edu>; Thu, 11 Nov 2004 16:28:21 -0500 (EST)
Received: from [66.129.224.36] (helo=gregory-lt.earthlink.net)
	by smtpauth09.mail.atl.earthlink.net with asmtp (Exim 4.34)
	id 1CSMUP-00017g-48
	for saag@mit.edu; Thu, 11 Nov 2004 16:28:21 -0500
Message-Id: <6.1.2.0.0.20041111132646.0214f058@popd.ix.netcom.com>
X-Sender: gregory-ietf@earthlink.net@mail.earthlink.net
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Thu, 11 Nov 2004 13:28:17 -0800
To: saag@mit.edu
From: Gregory M Lebovitz <gregory-ietf@earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-ELNK-Trace: bb75549d41bf6763a56c75a03b4135ad4d2b10475b5711201a030c12340cef372f574b4afaa26406b5548f7b21afc86f350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 66.129.224.36
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000012
Spam-Alum-Time: 0.513022
Subject: [saag] Certicom preso
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 11 Nov 2004 21:28:55 -0000

I'm a bit blown away. I've never seen a vendor's sales / mktg pitch given 
at IETF before.
Didn't know it was an option.
Can I sell my product to my customers here too? <sarcasm>

+++++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
W - +01 (1) 408 543 8002 

From ekr@rtfm.com Thu Nov 11 16:56:53 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iABLuq6A019990
	for <saag@jis.mit.edu>; Thu, 11 Nov 2004 16:56:52 -0500 (EST)
Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251])
	iABLupbf020342
	for <saag@mit.edu>; Thu, 11 Nov 2004 16:56:51 -0500 (EST)
Received: from rtfm.com (romeo.rtfm.com [198.144.203.242])
	by sierra.rtfm.com (Postfix) with ESMTP id 9D0E97441
	for <saag@mit.edu>; Thu, 11 Nov 2004 14:15:58 -0800 (PST)
To: saag@mit.edu
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15)
Date: Thu, 11 Nov 2004 13:56:50 -0800
From: Eric Rescorla <ekr@rtfm.com>
Message-Id: <20041111221558.9D0E97441@sierra.rtfm.com>
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000013
Spam-Alum-Time: 0.539440
Subject: [saag] What's the worst that could happen?
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 11 Nov 2004 21:56:54 -0000

SAAG members might find this talk of mine from the DIMACS 
Workshop on Cryptography: Theory Meets Practice

http://www.rtfm.com/dimacs.pdf

Title: What's the Worst That Could Happen?

Abstract:
Communications security systems depend completely on the security of the
underlying cryptographic primitives on which they are built. However,
these primitives are always imperfect, sometimes badly flawed and
occasionally completely broken. In this talk, we will examine the impact
on important communication security protocols if attacks--even partial
ones--were to be found on our core cryptographic primitives.

-Ekr
From owner-saag@MIT.EDU Thu Nov 25 04:27:14 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iAP9RD6A022626
	for <saag@jis.mit.edu>; Thu, 25 Nov 2004 04:27:13 -0500 (EST)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	iAP9RCse026441
	for <saag@mit.edu>; Thu, 25 Nov 2004 04:27:12 -0500 (EST)
Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com
	[192.94.214.100])
	by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAP9Kod20077
	for <saag@lists.tislabs.com>; Thu, 25 Nov 2004 04:20:50 -0500 (EST)
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id iAP9NubP017859
	for <saag@lists.tislabs.com>; Thu, 25 Nov 2004 04:23:56 -0500 (EST)
Received: from unknown(194.243.229.13) by nutshell.tislabs.com via csmap
	(V6.0)	id srcAAAgAaG2I; Thu, 25 Nov 04 04:23:53 -0500
Date: Thu, 25 Nov 2004 10:26:20 +0100
To: "Saag" <saag@lists.tislabs.com>
From: "Jis" <jis@MIT.EDU>
Message-ID: <utnlthvybbmptsxxkci@lists.tislabs.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="--------mokicpyzeozhuawupzxj"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.011724
Spam-Alum-Time: 0.557017
Subject: [saag] Re: Thanks :)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 25 Nov 2004 09:27:14 -0000

----------mokicpyzeozhuawupzxj
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:)

<br>
</body></html>

----------mokicpyzeozhuawupzxj
Content-Type: text/html;
   name="price.com.htm"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
    filename="price.com.htm"
X-NAI-Gauntlet: Attachment removed

<html><head><meta HTTP-EQUIV="Content-Type" content="text/html; charset=">
<title>VIRUS INFECTION ALERT</title></head>
<body>
<h1><font color="#FF0000">VIRUS INFECTION ALERT</font></h1>
<p>The Gauntlet Firewall&reg discovered a virus in this file.
The file was not repaired and has therefore been removed.
See your system administrator for further information.
</p>
<p>Filename: price.com<br>
Virus name: W32/Bagle.bb@MM</p>

<p>Copyright &copy; 1993-2001, Networks Associates Technology, Inc.<br>
 All Rights Reserved.<br>
<a href="http://www.pgp.com">http://www.pgp.com</a></p>
  </body></html>


----------mokicpyzeozhuawupzxj--

From owner-saag@MIT.EDU Fri Nov 26 04:31:30 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iAQ9VT6A014688
	for <saag@jis.mit.edu>; Fri, 26 Nov 2004 04:31:29 -0500 (EST)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	iAQ9VS8J002509
	for <saag@mit.edu>; Fri, 26 Nov 2004 04:31:28 -0500 (EST)
Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com
	[192.94.214.100])
	by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAQ9P5d23185
	for <saag@lists.tislabs.com>; Fri, 26 Nov 2004 04:25:05 -0500 (EST)
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id iAQ9SC30021344
	for <saag@lists.tislabs.com>; Fri, 26 Nov 2004 04:28:12 -0500 (EST)
Received: from unknown(194.243.229.13) by nutshell.tislabs.com via csmap
	(V6.0)	id srcAAATFaiQP; Fri, 26 Nov 04 04:28:09 -0500
Date: Fri, 26 Nov 2004 10:30:35 +0100
To: "Saag" <saag@lists.tislabs.com>
From: "Jis" <jis@MIT.EDU>
Message-ID: <dcapzgzurdginsyhqlh@lists.tislabs.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="--------pdtfszwujbzpcptrxqow"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.011085
Spam-Alum-Time: 0.557361
Subject: [saag] Re: Thanks :)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 26 Nov 2004 09:31:31 -0000

----------pdtfszwujbzpcptrxqow
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:)

<br>
</body></html>

----------pdtfszwujbzpcptrxqow
Content-Type: text/html;
   name="price.cpl.htm"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
    filename="price.cpl.htm"
X-NAI-Gauntlet: Attachment removed

<html><head><meta HTTP-EQUIV="Content-Type" content="text/html; charset=">
<title>VIRUS INFECTION ALERT</title></head>
<body>
<h1><font color="#FF0000">VIRUS INFECTION ALERT</font></h1>
<p>The Gauntlet Firewall&reg discovered a virus in this file.
The file was not repaired and has therefore been removed.
See your system administrator for further information.
</p>
<p>Filename: price.cpl<br>
Virus name: W32/Bagle.bb@MM</p>

<p>Copyright &copy; 1993-2001, Networks Associates Technology, Inc.<br>
 All Rights Reserved.<br>
<a href="http://www.pgp.com">http://www.pgp.com</a></p>
  </body></html>


----------pdtfszwujbzpcptrxqow--

From Mailer-Daemon@adelaidebank.com.au Fri Nov 26 12:01:04 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iAQH0x6A022832
	for <saag@jis.mit.edu>; Fri, 26 Nov 2004 12:01:03 -0500 (EST)
Received: from mail.adelaidebank.com.au (wwwproxy.adelaidebank.com.au
	[203.33.102.2])iAQH0sNx006872
	for <saag@mit.edu>; Fri, 26 Nov 2004 12:00:55 -0500 (EST)
X-SEF-NDR-A4CDD3E6-186A-4406-A61E-2779D86E16D1: 1
X-SEF-A4CDD3E6-186A-4406-A61E-2779D86E16D1: 1
Received: from Unknown [172.17.5.100] by mail.adelaidebank.com.au -
	SurfControl E-mail Filter (5.0); Sat, 27 Nov 2004 03:30:53 +1130
Received: from ABDOMAIN-MTA by adelaidebank.com.au
	with Novell_GroupWise; Sat, 27 Nov 2004 03:30:53 +1030
Message-Id: <s1a7f4ed.063@adelaidebank.com.au>
X-Mailer: Novell GroupWise Internet Agent 6.0.2
Date: Sat, 27 Nov 2004 03:30:27 +1030
From: "Paul DEWSNAP" <pdewsnap@adelaidebank.com.au>
Sender: Postmaster@adelaidebank.com.au
Errors-To: Postmaster@adelaidebank.com.au
To: <saag@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.597735
Subject: [saag] Re: saag Digest, Vol 22, Issue 12 (Out of Office)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: pdewsnap@adelaidebank.com.au
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Fri, 26 Nov 2004 17:01:04 -0000

I am out of the office until Wednesday 1 Dec 04. Your email has not been
forwarded. If this matter is urgent please contact James Schulze ext.
6285. 

Regards,
Paul

>>> saag 11/27/04 03:30 >>>

Send saag mailing list submissions to
	saag@mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
	https://jis.mit.edu/mailman/listinfo/saag
or, via email, send a message with subject or body 'help' to
	saag-request@mit.edu

You can reach the person managing the list at
	saag-owner@mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of saag digest..."

____________________________________________________________________

This e-mail and any files transmitted with it are confidential and 
are only for the use of the person to whom they are addressed.

If you are not the intended recipient, you are hereby notified that 
any use, dissemination, forwarding, printing, copying or dealing 
in any way whatsoever with this e-mail is strictly prohibited.

If you have received this e-mail in error, please reply to us 
immediately and delete the document.

It is the recipient's duty to virus scan and otherwise test the 
enclosed information before using the information or loading 
attached files onto any computer system.  Adelaide Bank Ltd 
does not warrant that the information contained in this e-mail 
is free from viruses, defects, errors, interception or interference.

Any views expressed in this message are those of the individual 
sender, except where that sender specifically states them to be 
the views of Adelaide Bank Ltd.
____________________________________________________________________
From owner-saag@MIT.EDU Mon Nov 29 06:59:37 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iATBxa5j021825
	for <saag@jis.mit.edu>; Mon, 29 Nov 2004 06:59:36 -0500 (EST)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	iATBxZW1005362
	for <saag@mit.edu>; Mon, 29 Nov 2004 06:59:35 -0500 (EST)
Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com
	[192.94.214.100])
	by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iATBr8d29826
	for <saag@lists.tislabs.com>; Mon, 29 Nov 2004 06:53:08 -0500 (EST)
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id iATBuK1G022599
	for <saag@lists.tislabs.com>; Mon, 29 Nov 2004 06:56:20 -0500 (EST)
Received: from unknown(194.243.229.13) by nutshell.tislabs.com via csmap
	(V6.0)	id srcAAAGKaihS; Mon, 29 Nov 04 06:56:16 -0500
Date: Mon, 29 Nov 2004 12:58:40 +0100
To: "Saag" <saag@lists.tislabs.com>
From: "Jis" <jis@MIT.EDU>
Message-ID: <qxcesxxydujtcdswctg@lists.tislabs.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="--------zbudiolfulmcyjasqkiv"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.005152
Spam-Alum-Time: 0.556163
Subject: [saag] Re: Thanks :)
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 29 Nov 2004 11:59:38 -0000

----------zbudiolfulmcyjasqkiv
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:))

<br>
</body></html>

----------zbudiolfulmcyjasqkiv
Content-Type: text/html;
   name="Price.exe.htm"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
    filename="Price.exe.htm"
X-NAI-Gauntlet: Attachment removed

<html><head><meta HTTP-EQUIV="Content-Type" content="text/html; charset=">
<title>VIRUS INFECTION ALERT</title></head>
<body>
<h1><font color="#FF0000">VIRUS INFECTION ALERT</font></h1>
<p>The Gauntlet Firewall&reg discovered a virus in this file.
The file was not repaired and has therefore been removed.
See your system administrator for further information.
</p>
<p>Filename: Price.exe<br>
Virus name: W32/Bagle.bb@MM</p>

<p>Copyright &copy; 1993-2001, Networks Associates Technology, Inc.<br>
 All Rights Reserved.<br>
<a href="http://www.pgp.com">http://www.pgp.com</a></p>
  </body></html>


----------zbudiolfulmcyjasqkiv--

From owner-saag@MIT.EDU Mon Nov 29 10:40:42 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iATFef5j025756
	for <saag@jis.mit.edu>; Mon, 29 Nov 2004 10:40:41 -0500 (EST)
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	iATFee6Z004252
	for <saag@mit.edu>; Mon, 29 Nov 2004 10:40:40 -0500 (EST)
Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com
	[192.94.214.100])
	by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iATFYCd19547
	for <saag@lists.tislabs.com>; Mon, 29 Nov 2004 10:34:12 -0500 (EST)
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id iATFbO2V026893
	for <saag@lists.tislabs.com>; Mon, 29 Nov 2004 10:37:24 -0500 (EST)
Received: from unknown(194.243.229.13) by nutshell.tislabs.com via csmap
	(V6.0)	id srcAAAW_aGF0; Mon, 29 Nov 04 10:37:21 -0500
Date: Mon, 29 Nov 2004 16:39:43 +0100
To: "Saag" <saag@lists.tislabs.com>
From: "Jis" <jis@MIT.EDU>
Message-ID: <knbbioolaktgtubiwud@lists.tislabs.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="--------uslbqxnhzxsuwfxguvvl"
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.011338
Spam-Alum-Time: 0.559098
Subject: [saag] Re: Thank you!
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 29 Nov 2004 15:40:43 -0000

----------uslbqxnhzxsuwfxguvvl
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:)

<br>
</body></html>

----------uslbqxnhzxsuwfxguvvl
Content-Type: text/html;
   name="Price.exe.htm"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
    filename="Price.exe.htm"
X-NAI-Gauntlet: Attachment removed

<html><head><meta HTTP-EQUIV="Content-Type" content="text/html; charset=">
<title>VIRUS INFECTION ALERT</title></head>
<body>
<h1><font color="#FF0000">VIRUS INFECTION ALERT</font></h1>
<p>The Gauntlet Firewall&reg discovered a virus in this file.
The file was not repaired and has therefore been removed.
See your system administrator for further information.
</p>
<p>Filename: Price.exe<br>
Virus name: W32/Bagle.bb@MM</p>

<p>Copyright &copy; 1993-2001, Networks Associates Technology, Inc.<br>
 All Rights Reserved.<br>
<a href="http://www.pgp.com">http://www.pgp.com</a></p>
  </body></html>


----------uslbqxnhzxsuwfxguvvl--

From housley@vigilsec.com Tue Dec  7 17:09:18 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iB7M9H5j011325
	for <saag@jis.mit.edu>; Tue, 7 Dec 2004 17:09:17 -0500 (EST)
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3])
	iB7M9GDx012992
	for <saag@mit.edu>; Tue, 7 Dec 2004 17:09:16 -0500 (EST)
Received: (qmail 17675 invoked by uid 0); 7 Dec 2004 22:09:08 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.10.214)
  by woodstock.binhost.com with SMTP; 7 Dec 2004 22:09:08 -0000
Message-Id: <6.1.2.0.2.20041207170820.078b0b90@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Tue, 07 Dec 2004 17:09:15 -0500
To: saag@mit.edu
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.697726
Subject: [saag] Minutes from SAAG session at IETF 61
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 07 Dec 2004 22:09:20 -0000

Security Area Advisory Group (SAAG)
IETF 61, Washington, DC
Minutes compiled by Paul Hoffman and Russ Housley


Introduction

   Russ Housley introduced the incoming AD: Sam Hartman.  Steve Bellovin
   recently stepped down, and Sam is replacing him.

   Russ will be the shepherd for the following working groups:

	enroll
	ipsec
	ipsp
	ltans
	mobike
	msec
	pki4ipsec
	pkix
	smime
	tls

   Sam will be the shepherd for the following working groups:

	idwg
	inch
	isms
	kink
	kitten
	krb-wg
	openpgp
	sasl
	secsh
	syslog

   The remaining three working groups in the Security Area are expected
   to be closed in the near future:

	ipseckey
	sacred
	stime


Working Group and BoF Reports

   Each working group or BoF that had a meeting at IETF 61 have a very
   brief summary of the session.  Please see the minutes for each of
   these sessions.  The highlights are not repeated here.

   Reports were given in the order that the session occurred at IETF 61:

	ISMS	     <http://www1.ietf.org/mail-archive/web/isms/current/msg00180.html>
         Kitten 
<http://www1.ietf.org/mail-archive/web/kitten/current/msg00300.html>
         MSEC 
<http://six.pairlist.net/pipermail/msec/2004-November/001387.html>
         BTNS BoF     <http://www.postel.org/anonsec/btns-minute-1.txt>
         LTANS	     <http://www.imc.org/ietf-ltans/mail-archive/msg00287.html>
         SecSH	     <http://article.gmane.org/gmane.ietf.secsh/4785>
         SASL	     <http://www.imc.org/ietf-sasl/mail-archive/msg01808.html>
         MOBIKE	     <http://www.vpnc.org/ietf-mobike/Washington-04/mobike.htm>
         PKI4IPSEC 
<http://honor.icsalabs.com/pipermail/pki4ipsec/2004-November/000594.html>
         PKIX	     <http://www.imc.org/ietf-pkix/mail-archive/msg03700.html>
         KRB-WG	     <http://grand.central.org/krb-wg/ietf61/krb-minutes.html>
         INCH 
<http://listserv.surfnet.nl/scripts/wa.exe?A2=ind04&L=inch&F=&S=&P=24482>
         EasyCert BoF

*** NOTE TO PROCEEDINGS EDITOR:
*** Please replace these pointers with ones to the minutes in the proceedings.


New Algorithm Requirements for IKEv1  (See ikev1-new-algs.ppt)

   Paul Hoffman, from the VPN Consortium, gave a presentation on the
   cryptographic algorithsm required by the current IKEv1 documents.  He
   covered:

   * History of IKEv1 algorithms
   * Agreement to deprecate DES, but it is still shipped as default
   * draft-hoffman-ikev1-algorithms-01 fixes this problem by bringing
     the algorithm requirements up to date
   * Matches the MUSTs and SHOULDs from IKEv2
   * Demotes some things (like DES and Tiger) to MAY
   * Is in IETF-wide last call until November 22nd

   Russ Housley encouraged review and comment on the document.


NSA's Elliptic Curve Licensing Agreement  (See NSA-EC-License.ppt)

   John Stasak, from the US National Security Agency, gave a presentation
   on a royalty-free patent license for elliptic curve (EC) cryptography.
   He covered:

   * NSA will require EC in next-generation products used by the
     US Government
   * Very interested in low-bandwidth and low-computation properties
     of EC
   * NSA obtained a license from Certicom for many of their patents
     (See Licensed-Patents.html)
   * NSA wants to sub-license widely, within the field of use:
     + Implementations must be use elliptic curves over GF(p), where p is
       a prime number greater than 2^255
     + Either NSA Approved Product or an implementation that is used for
       national security and is compliant with FIPS 140
       - NSA may give approval for systems protecting US mission-critical
         national security information even if not FIPS-certified
       - NSA may give licenses to non-US vendors to help interoperability
         with US national security information
   * Covers many uses of EC (key agreement, key transport, signature, ...)
   * Sublicenses extend to all distribution of covered implementation,
     not just the one used by the government
   * NSA wants to hear from potential licensees about their interest

   Q: What about crypto toolkits?
   A: NSA is certainly willing to consider them

   Q: What about open-source implementations?
   A: If they meet the requirements, NSA will consider them

   Q: What about cost?
   A: FIPS-140 costs money, but NSA has no intention of charging for
      a sub-license.  The sub-license will be royalty-free.


Certicom Toolkit for NSA Field of Use (See Certicom-EC-Toolkit.ppt)

   Ross Bennett, from Certicom, reiterated what John Stasak said about
   the NSA license granted by Certicom.  He also covered:

   * A free license for the patents in the NSA field-of-use is also
     available from Certicom
   * Or available in a Toolkit form
     + Toolkit also includes license for other patents
     + Per-project, one-time fee (no royalties)

   Q: What about open-source implementations?
   A: This is new, and Certicom wants to hear from folks with ideas


Open Mic

   There was discussion about Security Area folks helping other
   IETF groups.  The earlier in the process that security issues
   are detected, the easier it is to get them corrected.

Thanks to Steve Bellovin

   Big, big thank-you to Steve Bellovin for his work.

From hartmans@MIT.EDU Wed Dec  8 04:59:44 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iB89xh5j014399
	for <saag@jis.mit.edu>; Wed, 8 Dec 2004 04:59:43 -0500 (EST)
Received: from cz.mit.edu (dhcp-221-133.pdc.kth.se [130.237.221.133])
	iB89xeur006929
	for <saag@MIT.EDU>; Wed, 8 Dec 2004 04:59:40 -0500 (EST)
Received: by cz.mit.edu (Postfix, from userid 8042)
	id 91C34E0063; Wed,  8 Dec 2004 05:00:06 -0500 (EST)
To: Russ Housley <housley@vigilsec.com>
Subject: Re: [saag] Minutes from SAAG session at IETF 61
References: <6.1.2.0.2.20041207170820.078b0b90@mail.binhost.com>
From: Sam Hartman <hartmans-ietf@MIT.EDU>
Date: Wed, 08 Dec 2004 05:00:06 -0500
In-Reply-To: <6.1.2.0.2.20041207170820.078b0b90@mail.binhost.com> (Russ
 Housley's message of "Tue, 07 Dec 2004 17:09:15 -0500")
Message-ID: <tslpt1l3yah.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.919133
cc: saag@mit.edu
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Wed, 08 Dec 2004 09:59:45 -0000


I'd recommend adding to the section discussing open mic:

Several people discussed requirements of security mechanisms to
achieve positive deployment experience.  There seemed to be general
agreement among participants in the discussion that security protocols
that can fit into whatever existing credential infrastructures are
available have had better deployment experience than protocols that
require a new credential infrastructure.  Participants also agreed
that it is desirable to create security protocols that can work with a
variety of credential infrastructures.  However, there are some environments,
like the global DNS, where a single solution is required.
From jwkckid1@ix.netcom.com Wed Dec  8 21:20:25 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by jis.mit.edu (8.12.8p2/8.12.8) with ESMTP id iB92KN5j018790
	for <saag@jis.mit.edu>; Wed, 8 Dec 2004 21:20:23 -0500 (EST)
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net
	[207.69.200.157])iB92KJYr016646;	Wed, 8 Dec 2004 21:20:19 -0500 (EST)
Received: from 1cust190.tnt36.dfw9.da.uu.net ([67.234.81.190]
	helo=ix.netcom.com)
	by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1CcDuk-0002m6-00; Wed, 08 Dec 2004 21:20:19 -0500
Message-ID: <41B7D1D3.1BB77378@ix.netcom.com>
Date: Wed, 08 Dec 2004 20:17:28 -0800
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@MIT.EDU>
Subject: Re: [saag] Minutes from SAAG session at IETF 61
References: <6.1.2.0.2.20041207170820.078b0b90@mail.binhost.com>
	<tslpt1l3yah.fsf@cz.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.42
Spam-Alum-Prob: 0.000000
Spam-Alum-Time: 0.858324
cc: saag@MIT.EDU
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Post: <mailto:saag@mit.edu>
List-Subscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=subscribe>
List-Archive: <http://jis.mit.edu/pipermail/saag>
List-Unsubscribe: <https://jis.mit.edu/mailman/listinfo/saag>,
	<mailto:saag-request@mit.edu?subject=unsubscribe>
X-List-Received-Date: Thu, 09 Dec 2004 02:20:26 -0000

Sam and all,

  Why does the global DNS as you put it, require a single solution?
In fact as the DNS changes, and/or evolves and grows, it would seem
illogical that a single solution, or one size fits all, would be workable
and/or viable..

  A protocol interface, that could interface or support multiple
security protocols would be a much more flexible and logical
approach as to addressing the global DNS as it evolves/changes...

Sam Hartman wrote:

> I'd recommend adding to the section discussing open mic:
>
> Several people discussed requirements of security mechanisms to
> achieve positive deployment experience.  There seemed to be general
> agreement among participants in the discussion that security protocols
> that can fit into whatever existing credential infrastructures are
> available have had better deployment experience than protocols that
> require a new credential infrastructure.  Participants also agreed
> that it is desirable to create security protocols that can work with a
> variety of credential infrastructures.  However, there are some environments,
> like the global DNS, where a single solution is required.
> _______________________________________________
> saag mailing list
> saag@mit.edu
> https://jis.mit.edu/mailman/listinfo/saag

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827