Subject: Re: [TLS] WGLC for draft-ietf-tls-ecdhe-psk-01

From: Alfred Hönes <[email-masked]>
Date: Sat, 17 May 2008 19:38:22 +0200 (MESZ)

I already had reviewed two previous versions of this draft.
The issues I had raised in the past have been resolved
during the iterations up to the current revision.  A few
new editorial nits have already been pointed out off-list.

In the meantime, TLS 1.2 (RFC-to-be 5246) is close to
publication.  draft-ietf-tls-ecdhe-psk-01 ist based
on RFC 4346, and hence the question arises whether
the draft can be simply 'updated' by mechanically
upgrading the Normative Ref from TLS 1.1 to TLS 1.2
(that's what the RFC Editor would be supposed to do).

But that's perhaps not what is most appropriate.

Unlike other proposals on the TLS agenda, this TLS amendment
*is* compatible with, and in fact it has been designed for,
use with TLS 1.1 (plus RFC 4492, 4279, and 4785 (*)).

I see no technical obstacles for its use with TLS 1.2, amended
by the application of these same RFCs (or potential successors),
but it might be necessary to closely reconsider all details.

Clarifying the applicability and updating the Refs should not
be deferred to RFC Editor processing.

To accomodate the expected state of the TLS specifications upon
the desired publication of this draft as an RFC, I recommend to
perform the following additions/changes to this draft before
forwarding it to the IESG:

   - add an applicability statement for TLS revisions

   - demote [RFC4346] to Informative,
   - add new Normative Ref. to RFC 5246, and
   - replace most uses of [RFC4346] by the pointer to the latter
     (keep ref. [RFC4346] for text specific to TLS 1.1)

Further consideration:

Currently, the draft is restricted to SHA-1 as the hash function,
as are the above mentioned RFCs being extended by this draft;
this ensures compatibility with TLS 1.1.  A potential extension
to new MACs, applicable only for TLS 1.2, is deferred to future
document[s] (and will perhaps need update(s) to the above RFCs (*)).
It might be useful to explicitely state this restriction in scope
of the draft.

Best regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 21 May 2008 12:47:34 +0200

Dear Alfred,

Thanks for the feedback. Please find my responses inline...

>    - add an applicability statement for TLS revisions

What about the adding the following "Applicability Statement" 
sub-section to the introduction

"The ciphersuites defined in this document MAY be negotiated, whatever 
the negociated TLS version."

or

"Clients and servers might negotiate TLS 1.0 or later and select one of 
the cipher suites in this document."

>    - demote [RFC4346] to Informative,

RFC4346 is cited only in Security Considerations section.

>    - add new Normative Ref. to RFC 5246, and

OK

>      (keep ref. [RFC4346] for text specific to TLS 1.1)

OK

> It might be useful to explicitely state this restriction in scope

What about adding to the following text to the introduction:

"The cipher suites defined in this document are restricted to SHA-1 as 
the hash function, as defined in [RFC4346]. New cipher suites with 
SHA-256/384 [ref1] and AES Galois Counter Mode [ref2] may be specified 
in a separate document."

Between, I received the same comment from I. Hajjeh. Alfred, Ibrahim and 
I would probably submit a seperate document before the next meeting to 
add the following cipher suites:

    CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256  = { 0xXX, 0xXX };
    CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA384  = { 0xXX, 0xXX };
    CipherSuite TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256  = { 0xXX, 0xXX };
    CipherSuite TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA484  = { 0xXX, 0xXX };
    CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256  = { 0xXX, 0xXX };
    CipherSuite TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384  = { 0xXX, 0xXX };
    CipherSuite TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256  = { 0xXX, 0xXX };
    CipherSuite TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384  = { 0xXX, 0xXX };
    CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA256         = { 0xXX, 0xXX };
    CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA348         = { 0xXX, 0xXX };

>   Alfred.

Best regards,
Badra

---

From: <[email-masked]>
Date: Fri, 23 May 2008 14:43:52 +0300

Mohamad Badra wrote:

> Between, I received the same comment from I. Hajjeh. Alfred, Ibrahim
> and I would probably submit a seperate document before the next
> meeting to add the following cipher suites:
>

<AD hat on>

Please, don't do this! Getting an RFC published requires *lot* of work
from the WG chairs, Area Directors (all of them, not just me), IANA
staff, the RFC editor, and so on. 

Doing that for a document whose technical content is ~160 bits (the
numbers assigned by IANA) is a huge waste of resources, and that's
time away from doing some other work with bettern return on 
investment.

Please get consensus on what you want to specify, and put those numbers 
in a single document. 

Best regards,
Pasi

---

From: [email-masked]
Date: Fri, 23 May 2008 17:46:52 +0200 (CEST)

Dear Pasi,

>> CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA348         = { 0xXX, 0xXX };

Congratulations on the new hat!

> staff, the RFC editor, and so on.

And from the authors and editors too..

> Please get consensus on what you want to specify, and put those numbers

I don't see where is the problem? As a said, I will *probably* submit a
document on these cipher suites, but I will never force the committees to
spend time on unnecessary work. I guess the WG Chairs will not let this
happen :-)

Anuway, I will ask the WG Chairs for an agenda slot to discuss of these
cipher suites during the next TLS session.

I don't agree with you to put them in a single document. There are several
ciphersuites that may only be used with TLS 1.2 or greater. Defining them
in a single document (with ciphersuites that may be used whatever the TLS
version) will create confusion and IMO will not reduce the communities
load.

Best regards,
Badra