Subject: Re: [Capwap] crypto algorithms for DTLS

From: "Abhijit Choudhury (achoudhu)" <[email-masked]>
Date: Wed, 9 Jul 2008 11:38:41 -0700

-----Original Message-----
From: Joseph Salowey (jsalowey) 
Sent: Wednesday, July 09, 2008 11:09 AM
To: Abhijit Choudhury (achoudhu); [email-masked]'; Pat
Calhoun (pacalhou); [email-masked]'
Cc: [email-masked]'
Subject: RE: [Capwap] crypto algorithms for DTLS

> -----Original Message-----
> From: Abhijit Choudhury (achoudhu)
> Sent: Wednesday, July 09, 2008 11:00 AM
> To: [email-masked]; Pat Calhoun (pacalhou); 
> [email-masked]; Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: RE: [Capwap] crypto algorithms for DTLS
> 
> I'm okay with adding AES-GCM support as a MAY.
> However, I'd suggest we add the following ciphers:
> 
> 		TLS_RSA_WITH_AES_128_GCM_SHA256
> 		TLS_RSA_WITH_AES_256_GCM_SHA384
> 
> 		TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> 		TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> 
> 
> Also, in the current spec, shouldn't we be specifying DHE instead of 
> DH in the cipher suite recommendations.
> 
> Scott, Charles, Joe: any thoughts on this ?
>   
[Joe] The DH cipher suites are for certificates containing static
Diffie-Hellman keys which are not commonly used.  I think you probably
mean to specify DHE which are the ephemeral Diffie-hellman variants that
are more commonly used and provide forward secrecy.  

The GCM cipher suites are based on TLS 1.2 which is currently in AUTH48
state in the RFC-editors queue and should be published shortly.  

> Thanks,
> Abhijit
>  
>  
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 08, 2008 4:17 PM
> To: Pat Calhoun (pacalhou); [email-masked]; Abhijit 
> Choudhury (achoudhu)
> Cc: [email-masked]
> Subject: RE: [Capwap] crypto algorithms for DTLS
> 
> Hi All,
> 
> Are there any objections in the WG to adding the following cipher
> suites:
> TLS_RSA_WITH_AES_128_GCM_SHA256
> TLS_DH_RSA_WITH_AES_256_GCM_SHA384  to the base spec as a MAY?   
> 
> If not, based on the list discussion and approved draft status of 
> draft-ietf-tls-rsa-aes-gcm-03.txt, I support including these cipher 
> suites as a MAY in the next(last) WGLC.
> 
> Best Regards,
> Dorothy
> 
> 
> > -----Original Message-----
> > From: ext Pat Calhoun (pacalhou) [mailto:[email-masked]]
> > Sent: Tuesday, July 08, 2008 4:06 PM
> > To: Scott Kelly; Abhijit Choudhury (achoudhu)
> > Cc: capwap
> > Subject: Re: [Capwap] crypto algorithms for DTLS
> > 
> > Oh, and just to make sure, if we were to go ahead with this, the 
> > following cipher suites would be added:
> > 
> > TLS_RSA_WITH_AES_128_GCM_SHA256
> > TLS_DH_RSA_WITH_AES_256_GCM_SHA384
> > 
> > Right?
> > 
> > PatC
> > 
> > -----Original Message-----
> > From: Pat Calhoun (pacalhou)
> > Sent: Tuesday, July 08, 2008 3:57 PM
> > To: Scott Kelly; Abhijit Choudhury (achoudhu)
> > Cc: capwap
> > Subject: Re: [Capwap] crypto algorithms for DTLS
> > 
> > CAPWAP Chairs,
> > 
> > I am done with the edits, and ready to submit the spec for
> the WG Last
> > Call. This is a new feature, and we had agreed to defer to the next 
> > version of the protocol. However, the IETF has completed the long 
> > pole, and the change, as a MAY, is fairly minor. What would you 
> > recommend?
> > 
> > PatC
> > 
> > -----Original Message-----
> > From: Scott Kelly [mailto:[email-masked]]
> > Sent: Tuesday, July 08, 2008 3:42 PM
> > To: Abhijit Choudhury (achoudhu)
> > Cc: capwap
> > Subject: Re: [Capwap] crypto algorithms for DTLS
> > 
> > Hi Abhijit,
> >  
> > > 
> > > Folks,
> > > 
> > > The issue of using AES-GCM as a cipher-suite for CAPWAP/DTLS was 
> > > discussed in the list about a year ago.  (Please refer to
> > CAPWAP issue
> > 
> > > 7
> > > (http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue7)
> > > 
> > > Due to the use of DTLS, we were stuck with TLS ciphersuites.  
> > > To use GCM we would require a TLS GCM ciphersuite.  We
> > discussed this
> > > at an ad-hoc meeting, and decided to defer this feature,
> as GCM was
> > > not a TLS ciphersuite, and there was no document to reference.
> > > 
> > > However, since that time, use of AES-GCM has been approved
> > in the TLS
> > > working group, and we have an approved draft 
> > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-rsa-aes-gcm/
> > > 
> > > As noted in the original email, there is a lot of momentum
> > behind this
> > 
> > > crypto algorithm, and it results in significant improvements in 
> > > throughput in either HW or SW implementations.
> > > 
> > > Could we address this issue in the current spec and make
> AES-GCM an
> > > ciphersuite that can be used with CAPWAP/DTLS ?
> > 
> > I have no objections to adding support for AES-GCM as a MAY. 
> > The original proposal suggested making it mandatory to
> implement, but
> > given the current lack of support in commodity crypto HW, I don't 
> > think this would be appropriate at this time.
> > 
> > --Scott
> > 
> > 
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> > 
> > Archives: http://lists.frascone.com/pipermail/capwap
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> > 
> > Archives: http://lists.frascone.com/pipermail/capwap
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> > 
> > Archives: http://lists.frascone.com/pipermail/capwap
> > 
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 11 Jul 2008 09:29:58 -0700

Unfortunately, the spec has been released for publication already. I will deal with this as part of the IETF Last Call process.

PatC

 -----Original Message-----
From: 	Scott Kelly [mailto:[email-masked]]
Sent:	Friday, July 11, 2008 09:27 AM Pacific Standard Time
To:	Joseph Salowey (jsalowey); Pat Calhoun (pacalhou); Abhijit Choudhury (achoudhu); [email-masked]
Cc:	[email-masked]
Subject:	RE: [Capwap] crypto algorithms for DTLS

I agree with Joe. 

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
> Sent: Thursday, July 10, 2008 5:37 PM
> To: Scott Kelly; Pat Calhoun (pacalhou); Abhijit Choudhury 
> (achoudhu); [email-masked]
> Cc: [email-masked]
> I think it would be best to reference the DTLS specification (RFC4347)
> for recommendations on cipher suites for use with DTLS.  
> 
> Cheers,
> 
> Joe 
> 
> > Sent: Thursday, July 10, 2008 11:45 AM
> > To: Pat Calhoun (pacalhou); Abhijit Choudhury (achoudhu); 
> > [email-masked]; Joseph Salowey (jsalowey)
> > Cc: [email-masked]
> > I think this is probably a safe statement.
> > 
> > > From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
> > > Sent: Thursday, July 10, 2008 11:30 AM
> > > To: Abhijit Choudhury (achoudhu); Scott Kelly; 
> > > [email-masked]; Joseph Salowey (jsalowey)
> > > Cc: [email-masked]
> > > Scott - Are you OK with this proposal?
> > > 
> > > PatC
> > > 
> > > Sent: Thursday, July 10, 2008 11:26 AM
> > > To: Pat Calhoun (pacalhou); 'Scott Kelly'; 
> > > [email-masked]'; Joseph Salowey (jsalowey)
> > > Yes, CAPWAP doesn't need to constrain the ciphers to 
> block ciphers.
> > > The real reason is that CAPWAP tracks DTLS1.0 which 
> tracks TLS1.1, 
> > > which uses block ciphers.
> > > So, it'd be better to say explicitly that we only use ciphers 
> > > recommended for DTLS. This way, it'll be easier to 
> upgrade later to 
> > > DTLS1.2, without having to change text in this spec.
> > > 
> > > We could include the reference... That's fine.
> > > 
> > > So, how about this:
> > > 
> > >  
> > > Replace the text in section 2.4.4.1 from
> > > 
> > > 	"Note that only block ciphers are currently recommended 
> > for use with 
> > > DTLS.
> > > 	To understand the reasoning behind this, see [DTLS-DESIGN]."
> > > 
> > > To
> > > 
> > > 	"CAPWAP implementations only use cipher suites that are 
> > recommended 
> > > for
> > >        use with DTLS [DTLS-DESIGN]." 
> > > 
> > > Thanks,
> > > Abhijit
> > >  
> > >  
> > > 
> > > Sent: Thursday, July 10, 2008 10:18 AM
> > > To: Abhijit Choudhury (achoudhu); 'Scott Kelly'; 
> > > [email-masked]'; Joseph Salowey (jsalowey)
> > > Out of curiosity, what is different in your text, other 
> > than removing 
> > > the reference to a document that, I guess, provides more 
> clarity on 
> > > why this statement is made? Is it the explicit removal of block 
> > > ciphers that is what's desired here?
> > > 
> > > PatC
> > > 
> > > Sent: Thursday, July 10, 2008 9:52 AM
> > > To: Pat Calhoun (pacalhou); 'Scott Kelly'; 
> > > [email-masked]'; Joseph Salowey (jsalowey)
> > > Okay. I'm fine with defering this. Let's not delay the 
> current spec.
> > > 
> > > 
> > > I'd suggest the following changes:
> > > 
> > > 1. In order to ensure that CAPWAP track DTLS better, we should 
> > >     change the text in section 2.4.4.1 from
> > > 
> > > "Note that only block ciphers are currently recommended for 
> > use with 
> > > DTLS.
> > > To understand the reasoning behind this, see [DTLS-DESIGN]."
> > > 
> > > To
> > > 
> > > "CAPWAP implementations only use cipher suites that are 
> recommended 
> > > for use with DTLS."
> > > 
> > > 2. Change the existing ciphers using DH to DHE.
> > > 
> > > 
> > > Thanks,
> > > Abhijit
> > >  
> > >  
> > > 
> > > Sent: Thursday, July 10, 2008 9:28 AM
> > > To: Scott Kelly; Abhijit Choudhury (achoudhu); 
> > > [email-masked]; Joseph Salowey (jsalowey)
> > > Cc: [email-masked]
> > > Ok, given this debate, and being short on time, I will submit the 
> > > documents without the GCM ciphers, and therefore will not 
> be making 
> > > changes from TLS/DTLS1.1 to TLS/DTLS1.2. We can deal with 
> this in a 
> > > separate document. I would recommend adding the following 
> sentence 
> > > after the list of supported ciphers in both the certificate and 
> > > pre-shared
> > > key:
> > > 
> > >    Additional ciphers MAY be defined in follow on CAPWAP 
> > > specifications.
> > > 
> > > Ok?
> > > 
> > > PatC
> > > 
> > > Sent: Thursday, July 10, 2008 9:14 AM
> > > To: Abhijit Choudhury (achoudhu); Pat Calhoun (pacalhou); 
> > > [email-masked]; Joseph Salowey (jsalowey)
> > > Cc: [email-masked]
> > > > My understanding is that DTLS1.2 will use the ciphers 
> > specified in 
> > > > TLS1.2, which has already been approved.
> > > > The DTLS1.2 spec will not have new ciphers, but will 
> > possibly have 
> > > > details on how to use these ciphers in DTLS.
> > > > Please correct me if I'm wrong here.
> > > > 
> > > > So, we should be okay adding these approved TLS ciphers to the 
> > > > OPTIONAL list, although it's true that they will not be 
> used until
> > > > DTLS1.2 is finalized. But the list is only OPTIONAL and 
> there are 
> > > > other optional ciphers as well.
> > > > If we take this path, we don't have to touch this spec 
> > later to add 
> > > > these ciphers.
> > > 
> > > I think there's a flaw in this logic. The currently 
> > optional ciphers 
> > > are supported in DTLS1.0 -- you are asking to add ciphers 
> which are 
> > > not supported in DTLS1.0, meaning a compliant CAPWAP 
> implementation 
> > > (i.e.
> > > one implementing DTLS1.0) will not be able to 
> interoperate with one 
> > > using these ciphers.
> > > 
> > > > If we go the other route, how do we see it being done ?
> > > > Will we need a draft to specify just the deltas in using
> > > DTLS1.2 for
> > > > CAPWAP ?  The concern I have is that it's not clear if the
> > > CAPWAP WG
> > > > will be active at that point to take up this new work item.
> > > > 
> > > > Thoughts ?
> > > 
> > > Yes, I think a new, brief document specifying the deltas 
> is exactly 
> > > what will be required. I also think speculation on the potential 
> > > (non)existence of the capwap working group should not be 
> the driver 
> > > here. It isn't very relevant one way or the other. For 
> > example, we've 
> > > published a number of ammendments to IPsec since the wg 
> > dissolved, and 
> > > the ADs willingly sponsored/shepherded these documents 
> > through. If for 
> > > some odd reason (despite the fact that we've just started mib
> > > work) the
> > > capwap wg dissolves, this should present no impediment to 
> > publishing 
> > > an updated DTLS binding document.
> > > 
> > > It's rarely a good idea to rush such initiatives. 
> > > 
> > > --Scott
> > > 
> > 
>