[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSEC WORKING GROUP LAST CALL

  Ted,

  A 2key 3DES is 112bit while a 3key 3DES is 168 (although I never did
like those numbers since 3 DES keys are 192 bits not 168 bits). And
draft-ietf-ipsec-ciph-3des-00.txt is definately a 3key 3DES. So I think 
Ramesh is talking about a 2key 3DES. But there is no draft which defines 
such a transform so the request to add a magic number for it is premature.
Ditto for 40bit DES. 

  As far as the other drafts are concerned, I'd like to see 3DES get
added to the pile but given the size of the pile already I wouldn't have
a problem with waiting on the rest.

  Dan.

> 40 Bit DES isn't currently defined in a cipher suite algorithm anywhere,
> so I'm not particularly saddened or disturbed by its omission.  ESP_3DES
> is defined (it has the value of 3) and that is a 112 bit (3key) triple
> DES.  See draft-ietf-ipsec-ciph-3des-00.txt.  So, I don't believe either
> of your concerns is a problem.  Your question about triple DES does
> another one, though, which I will put to the working group:
> 
> The triple DES document wasn't one of the documents that I put into IETF
> last call, as one of the "core group" of documents.  Do people believe
> that should get pushed out to the IESG at the same time?
> 
> There is a related question to the other cipher suites for which DOI
> document contains references: ARCFOUR, Blowfish, and RC5.  Since RFC's
> are not allowed to refer to internet-drafts, what do we want to do with
> them in the DOI spec?  There is also a reference in the DOI draft to
> draft-mcdonald-pf-key-v2-03.txt (and the latest version of that I-D is
> -04).
> 
> Our choices for each referenced I-D include (a) deleting the reference
> from the draft, or (b) advancing the I-D along with the main set of
> documents.  Note that if we choose (a), it's no big deal; we would
> simply move the DOI assignment to the (delayed) cipher draft, and when
> the cipher draft advanced, it would get added to the IANA's registry
> list.
> 
> The advantage of (a) is that it might speed up the time that it takes
> the IESG to the IPSEC drafts, since it won't have to deal with the extra
> drafts.  It also means we don't have to take time now vetting these
> "non-core" drafts (which I suspect most people haven't paid much
> attention to at this point).  The advantage of (b) is that for people
> who really want to use these other algorithms, they will be available
> sooner, and the DOI would contain a slightly more comprehensive list.
> 
> My tendency is to lean towards (a) for all of the non-core cipher
> documents (except possibly triple DES), but I'm certainly willing to
> hear arguments to the contrary, or for other alternatives.
> 
> As for the reference to the PFKEY API, we can either (a) remove the
> reference, or (b) suggest that this be advanced to informational,
> assuming that the PFKEY folks believe that the document is stable.  The
> reference doesn't appear to be in a critical part of the text, so it
> probably isn't a big deal to remove the reference if the PFKEY spec is
> still undergoing revisions.
> 
> Comments?
> 
> 							- Ted
Follow-Ups: References: