Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 28 Feb 2003 14:33:59 -0500

No, Michael, I did answer your question: the one that went "what problem are
we solving here?" 

This draft promotes interoperability by specifying one encryption algorithm
that all SIP S/MIME implementations must support. The draft is indeed just a
pointer to the specification of AES for S/MIME, yes. You might argue that it
is of no value to use AES rather than 3DES, but I've pointed to a few ways
that this is valuable. It is hardly 'bending over backwards' to amend a
single paragraph of text in RFC3261.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 11:26 AM
> To: Peterson, Jon
> Cc: 'Michael Thomas'; [email-masked]
> Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt
> 
> 
> 
> 3DES is the least of your problems. It's the use
> of CMS and certs that causes the bloat: 3DES is
> only about 10k of code. Also: it's generally
> prudent to have backup algorithms. I don't see why
> we should be trying to bend over backward to chase
> this since there's still a lot of 3DES legacy out
> there making the likelihood of 3DES-free images
> pretty low in the long run.
> 
> In any case, you still haven't answered my
> question: how is this promoting interoperability?
> As far as I can see, it's just a pointer to the
> aes-smime draft and nothing else. Why is this
> needed?
> 
> 		Mike
> 
> Peterson, Jon writes:
>  > 
>  > I was able to grab the draft from the repository now; 
> maybe it wasn't
>  > available immediately after the I-D announcement.
>  > 
>  > The rationale for this draft, as it states itself, is to provide an
>  > encryption algorithm that is easier for lightweight SIP 
> UAs to implement,
>  > and to use the same encryption algorithm that we mandate 
> for TLS. If we
>  > supersede the text in RFC3261 before S/MIME is widely 
> implemented, there
>  > will be no need for dual-algorithm implementations 
> (supporting both 3DES and
>  > AES, which currently would be required for implementing 
> TLS and S/MIME).
>  > Many implementers of lightweight UAs have complained that 
> S/MIME is too
>  > heavy, in part because of the 3DES requirement. I think 
> this is reason
>  > enough to push this draft forward.
>  > 
>  > Jon Peterson
>  > NeuStar, Inc.
>  > 
>  > > -----Original Message-----
>  > > From: Michael Thomas [mailto:[email-masked]]
>  > > Sent: Friday, February 28, 2003 9:15 AM
>  > > To: Peterson, Jon
>  > > Cc: 'Michael Thomas'; [email-masked]
>  > > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt
>  > > 
>  > > 
>  > > 
>  > > First off, it seems that I misread the references
>  > > which negates one of comments about being
>  > > underspecified (I thought it pointed at a NIST
>  > > doc, instead of the smime wg draft). And yes, I
>  > > couldn't find the current draft yet, so I read the
>  > > previous draft...  if it says "comparable", that's
>  > > fine.
>  > > 
>  > > But I guess I'm still sort of mystified as to why
>  > > this even needs a draft for SIP. The current
>  > > wording says that other cipher suites are OK...
>  > > so what are we doing here which causes
>  > > interoperability that otherwise wouldn't have
>  > > happened? AFAIK, there's no negotiation for
>  > > anything in SIP about the cipher suites for SMIME,
>  > > so we're still in the "ready, fire, aim" situation
>  > > as before... what problem is being solved here?
>  > > 
>  > > 	Mike
>  > > 
>  > > Peterson, Jon writes:
>  > >  > 
>  > >  > Well, obviously the use of AES for S/MIME is not 
>  > > SIP-specific; hence the
>  > >  > fact that we reference smime-aes-alg, the S/MIME WG draft 
>  > > defining the use
>  > >  > of AES by S/MIME (currently in IETF LC), in our SIP draft. 
>  > > sip-smime-aes
>  > >  > merely provides text to replace some specific existing 
>  > > language in RFC3261
>  > >  > that recommended 3DES for S/MIME (as well as cleaning up 
>  > > some related S/MIME
>  > >  > details).
>  > >  > 
>  > >  > Adopting AES would not necessarily, as you suggest, render 
>  > > incomprehensible
>  > >  > any SIP message S/MIME body that is relayed to email - the 
>  > > email UA would
>  > >  > merely need to support smime-aes-alg; we aren't inventing 
>  > > something new
>  > >  > here. Futhermore, we are intentionally not necessarily 
>  > > specifying modes for
>  > >  > AES and the like - we're relying on the existing 
>  > > smime-aes-alg mode to
>  > >  > specify how AES should be used with S/MIME. The thrust of 
>  > > this draft is
>  > >  > merely to point the SIP standard to AES rather than 3DES.
>  > >  > 
>  > >  > As for the 'more secure' phrase, are you perhaps reading 
>  > > an older version of
>  > >  > the draft? The current text says "comparably secure" to 
>  > > 3DES. I changed the
>  > >  > text since the last revision in response to a comment to 
>  > > similar effect.
>  > >  > 
>  > >  > Jon Peterson
>  > >  > NeuStar, Inc.
>  > >  > 
>  > >  > > -----Original Message-----
>  > >  > > From: Michael Thomas [mailto:[email-masked]]
>  > >  > > Sent: Thursday, February 27, 2003 10:54 AM
>  > >  > > To: [email-masked]
>  > >  > > Cc: IETF-Announce; [email-masked]
>  > >  > > Subject: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt
>  > >  > > 
>  > >  > > 
>  > >  > > 
>  > >  > > So I don't get it. Why is this SIP specific? It
>  > >  > > seems to me that this should be taken up by the
>  > >  > > SMIME wg. For one thing, this would break any SIP
>  > >  > > message which contains SMIME which is then relayed
>  > >  > > to email, or anything else which uses SMIME.
>  > >  > > 
>  > >  > > Also: I don't think that AES is considered "more
>  > >  > > secure" than 3DES. Faster yes. Lastly, this is
>  > >  > > underspecified as it doesn't say what mode to use,
>  > >  > > text about IV's, etc, etc. Another good reason to
>  > >  > > punt this to a more appropriate wg.
>  > >  > > 
>  > >  > > 	  Mike
>  > >  > > 
>  > >  > > [email-masked] writes:
>  > >  > >  > A New Internet-Draft is available from the on-line 
>  > >  > > Internet-Drafts directories.
>  > >  > >  > This draft is a work item of the Session Initiation 
>  > >  > > Protocol Working Group of the IETF.
>  > >  > >  > 
>  > >  > >  > 	Title		: S/MIME AES Requirement for SIP
>  > >  > >  > 	Author(s)	: J. Peterson
>  > >  > >  > 	Filename	: draft-ietf-sip-smime-aes-00.txt
>  > >  > >  > 	Pages		: 6
>  > >  > >  > 	Date		: 2003-2-26
>  > >  > >  > 	
>  > >  > >  > RFC3261 currently specifies 3DES as the required minimum 
>  > >  > > ciphersuite
>  > >  > >  > for implementations of S/MIME in SIP.  This document 
>  > > updates the
>  > >  > >  > normative guidance of RFC3261 to require the Advanced 
>  > > Encryption
>  > >  > >  > Standard (AES) for S/MIME.
>  > >  > >  > 
>  > >  > >  > A URL for this Internet-Draft is:
>  > >  > >  > 
>  > > 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt
>  > >  > >  > 
>  > >  > >  > To remove yourself from the IETF Announcement 
> list, send a 
>  > >  > > message to 
>  > >  > >  > ietf-announce-request with the word unsubscribe in the 
>  > >  > > body of the message.
>  > >  > >  > 
>  > >  > >  > 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-ietf-sip-smime-aes-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:
>  > >  > >  > 	[email-masked].
>  > >  > >  > In the body type:
>  > >  > >  > 	"FILE /internet-drafts/draft-ietf-sip-smime-aes-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.
>  > >  > >  > Content-Type: text/plain
>  > >  > >  > Content-ID:	<[email-masked]>
>  > >  > >  > 
>  > >  > >  > ENCODING mime
>  > >  > >  > FILE /internet-drafts/draft-ietf-sip-smime-aes-00.txt
>  > >  > >  > Content-Type: text/plain
>  > >  > >  > Content-ID:	<[email-masked]>
>  > >  > > _______________________________________________
>  > >  > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>  > >  > > This list is for NEW development of the core SIP Protocol
>  > >  > > Use [email-masked] for questions 
> on current sip
>  > >  > > Use [email-masked] for new developments on the 
>  > > application of sip
>  > >  > > 
>  > >  > _______________________________________________
>  > >  > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>  > >  > This list is for NEW development of the core SIP Protocol
>  > >  > Use [email-masked] for questions on 
> current sip
>  > >  > Use [email-masked] for new developments on the 
> application of sip
>  > > 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Feb 2003 11:47:13 -0800 (PST)

Peterson, Jon writes:
 > that all SIP S/MIME implementations must support.

   Except if you support S/MIME, then you by definition support
   3DES, or so sez RFC 2633. Are you suggesting that these
   implementations not be RFC 2633 conformant? How else could
   they claim to support for S/MIME?

>  The draft is indeed just a

   I've made no claim about AES vs. 3DES. What does seem
   fairly clear is that the rationale given here is rather
   suspect. SIP-specific profiles of other protocols which
   are contrary to the minimum requirements plainly stated
   in those protocols is a very dangerous path to go down.
   Indeed, that is precicely the kind of thing that would
   cause interoperability to *break*.

	 Mike