Re: [TLS] draft-badra-tls-psk-new-mac-aes-gcm as WG item (was: RE: Re: TLS document status update)

[[e-mail]]

> I have read the draft-badra-tls-psk-new-mac-aes-gcm-02. I think that there
> is no significant issues that need consideration in this phase of the
> draft.
>
> I just have a small comment concerning the 2nd table of section 3.2: the
> following could be added,
>
> CipherSuite MAC PRF
>
> TLS_DHE_PSK_WITH_NULL_SHA256 HMAC-SHA-256 P_SHA-256
>
> TLS_DHE_PSK_WITH_NULL_SHA384 HMAC-SHA-384 P_SHA-384
> Kind regards,
> Hassnaa Moustafa

Dear Hassnaa,

Thank you for your review. I will insert the two ciphersuites in the table.

I have received the same comment from Alfred Hines who revised the initial
and revised versions of the document (two mails below).

Best regards,
Badra

---------- Forwarded message ----------
From: Alfred HÎnes <[e-mail]>
Date: Fri, May 2, 2008 at 3:11 PM
Subject: RE: draft-badra-tls-pdk-new-mac-aes-gcm-02
To: [e-mail]


Hello,
your note has triggered me to look
into the -02, which apparently has been brought in line
with the other related drafts in a much better manner now.

I stumbled over a detail, where (due to lack of time)
it is currently not clear to me whether *I* have missed
something or the draft is missing two lines:

The table at the end of section 3.2 only lists *four*
Ciphersuites, whereas the first table in this section
lists *six*.  Don't we need another two lines for the
TLS_DHE_PSK_WITH_NULL_SHAnnn Ciphersuites, as in Section 3
of RFC 4785 (second item in the list there)?

Please check.  Thanks.

Kind regards.
 Alfred.




---------- Forwarded message ----------
From: Alfred HÎnes <[e-mail]>
Date: Sun, Mar 30, 2008 at 6:04 PM
Subject: draft-badra-tls-psk-new-mac-aes-gcm-01
To: [e-mail]


   draft-badra-tls-psk-new-mac-aes-gcm-01


(1)  Section 1, 2nd paragraph

I suggest to change, for added clarity and precision, ...

  This document also specifies PSK cipher suites for TLS which replace
  SHA-256 and SHA-384 rather than SHA-1.  [...]

to either:

  This document also specifies PSK cipher suites for TLS which replace
|  SHA-1 by SHA-256 or SHA-384.  [...]
  ^^^^^^^^^        ^^        ^
or:

  This document also specifies PSK cipher suites for TLS which
|  substitute SHA-256 or SHA-384 for SHA-1.  [...]
  ^^^^^^^^^^         ^^         ^^^

(2)  Section 2

Below the initial list, the draft says:

  These cipher suites use authenticated encryption with additional
  data algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
  RFC 5116.  [...]

To better visibly group the words, and to tintroduce the abbreviation,
I suggest to add "(AEAD)" as follows:

  These cipher suites use authenticated encryption with additional
|  data (AEAD) algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM
       ^^^^^^^
  described in RFC 5116.  [...]


(3)  Section 3 ff.

There are a couple of arguments to more sparingly use the acronym
"MAC":
  -  acronym overload: also heavily used for "Media Access Control",
     in particular in the context of IEEE 802.* (Ethernet etc.);
     now that EAP-TLS has brought TLS terminology to layer 2,
     that's sometime becoming a nightmare of confusion.
  -  lack of terminological precision:  There are voices in the
     cryptographic literature (I believe to recall that Steve
     Bellovin was one of these) that pointed out that all three
     parts of the term "Message Authentication Code" are misleading;
  -  stylistic aspects in the text (HMAC might suffice), and
  -  uniform use of terminology.

Many parts of the draft already use "hash", in accordance to
many TLS documents.
Therefore, I suggest to change the text in section 3 ...

  The cipher suites described in this section use AES [AES] in CBC
|  [CBC] mode with an HMAC-based MAC.
                                ^^^
to either:

  The cipher suites described in this section use AES [AES] in CBC
|  [CBC] mode with an HMAC-based cryptographic hash.
                                ^^^^^^^^^^^^^^^^^^
or simply:

  The cipher suites described in this section use AES [AES] in CBC
|  [CBC] mode with an HMAC-based hash.
                                ^^^^
... and to replace "MAC" by "Hash" in all table headings in 3.*.


(4)  Section 5.2

I do not want to restart the discussions I had in the past
on details, or the utility of the (inherited) lengthy
elaboration on this specific implementation scenario.
(IMO, that's too much 'noise' in the IETF; the general uniqueness
nonce requirements should in practice suffice, and there are
other valid methods to ensure conformance to it in that scenario.)


Kind regards,
 Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+
_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls