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

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

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:25:47 -0800 (PST)

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