Addition of SEED Cipher Suites to Transport Layer Security (TLS)
draft-lee-tls-seed-01

IANA Comments:
IANA has confirmed with Russ that there are no IANA Actions for this document.  Another document will create the registry at a later time.

Review by Suzanne Woolf, Gen-ART

This is pretty brief but I think that means it's doing something that
should be pretty simple-- if the framework is well-defined, it's easy
to add new algorithms and options.

A couple of reservations:

1) A web page is included as a normative reference. I'm not sure
that's legal.

2) Two drafts are included as references. One is now an RFC and should
maybe be normative. (? If I'm reading this correctly, the KISA web
page is the normative reference to the protocol, but the new RFC,
referred to here as a draft, isn't.) The other draft, on SMIME
applicability for SSED, isn't published yet. But that's an RFC-Editor
issue more than a substantive one.

3) "IANA Considerations" asserts there are none because there is no
registry for TLS-related numbers. However, numbering new algorithms is
one of the classic reasons for creating a new registry. Is that
appropriate here?

4) A scarcity of MUSTs and MAYs and SHOULDs for Standards track. Are
there variants on SEED, factor size choices to make, etc. that
implementors should know about? This is probably covered by the SEED
RFCs (protocol and applicability) that were just published but perhaps
should be noted as specifically applicable to TLS.

The last point (more guidance for implementors) seems like the most
substantive one and I suggest someone with more knowledge specifically
of SEED than I have consider the question.

Otherwise, I think this is ready to advance.

[Ballot discuss]
I need some convincing to allow the normative reference to the main point of the specification (the SEED algorithm spec) to be a "title + URL" only.
If it was supplemeneted with a document number in some Korean official publication series, I'd stop whining - I just would hate to see this be unimplementable if the website got redesigned....

I note that draft-park-seed-01 has this reference:

  [TTASSEED]  Telecommunications Technology Association (TTA),
              "128-bit Symmetric Block Cipher (SEED)",
              TTAS.KO-12.0004, September, 1998 (In Korean)
              http://www.tta.or.kr/English/new/main/index.htm

I would have no issue with using that.

[Ballot discuss]
I need some convincing to allow the normative reference to the main point of the specification (the SEED algorithm spec) to be a "title + URL" only.
If it was supplemeneted with a document number in some Korean official publication series, I'd stop whining - I just would hate to see this be unimplementable if the website got redesigned....

[Ballot comment]
The document notes that there are no IANA registries because there is no relevant registry;
would there be any value to defining a registry here?

his draft defines the following ciphersuites (Section 2):

  CipherSuite TLS_RSA_WITH_SEED_CBC_SHA      = { 0x00,0x60};
  CipherSuite TLS_DH_DSS_WITH_SEED_CBC_SHA  = { 0x00,0x61);
  CipherSuite TLS_DH_RSA_WITH_SEED_CBC_SHA  = { 0x00,0x62);
  CipherSuite TLS_DHE_DSS_WITH_SEED_CBC_SHA  = { 0x00,0x63};
  CipherSuite TLS_DHE_RSA_WITH_SEED_CBC_SHA  = { 0x00,0x64};
  CipherSuite TLS_DH_anon_WITH_SEED_CBC_SHA  = { 0x00,0x65}

These numbers (0x00,0x60..0x65) are already used by various
"EXPORT1024" ciphersuites (expired I-D draft-ietf-tls-56-bit-
ciphersuites). Although that draft never became an RFC, these
ciphersuites are quite widely implemented (in e.g. OpenSSL,
Netscape/Mozilla NSS, and some Microsoft and Cisco products),
so reusing the same numbers is probably not a good idea.

The authors have been asked to work with the TLS WG to get
different numbers.