Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

From: <[email-masked]>
Date: Sun, 10 Jul 2016 07:36:59 +0000 (UTC)

Hi,
I'm curious as to the relationship between this TLS WG draft and the DICE profile for IoT (currently in Auth48):https://tools.ietf.org/html/draft-ietf-dice-profile

The dice profile uses two TLS ciphershuites
TLS_PSK_WITH_AES_128_CCM_8             (defined in https://tools.ietf.org/html/rfc6655)
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8     (defined in https://tools.ietf.org/html/rfc7251)

Notice that the DICE profile defines nothing (it has no IANA considerations). Instead, it reuses definitions established previously per the references above.
This draft-ietf-tls-ecdhe-psk-aeak  claims to also define IoT-friendly ciphersuites, for example, TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 
However, it does not reference the DICE profile draft. 
What is the difference between these?
thanks,
Gabriel  

    On Friday, May 27, 2016 10:19 AM, "[email-masked]" <[email-masked]> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

        Title          : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)
        Authors        : John Mattsson
                          Daniel Migault
    Filename        : draft-ietf-tls-ecdhe-psk-aead-00.txt
    Pages          : 7
    Date            : 2016-05-27

Abstract:
  This document defines several new cipher suites for the Transport
  Layer Security (TLS) protocol.  The cipher suites are all based on
  the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
  (ECDHE_PSK) key exchange together with the Authenticated Encryption
  with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
  provides light and efficient authentication, ECDHE provides perfect
  forward secrecy, and AES-GCM and AES-CCM provides encryption and
  integrity protection.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Peter Dettman <[email-masked]>
Date: Sun, 10 Jul 2016 17:51:06 +0700

Hi,
I've just implemented these ciphersuites in BouncyCastle TLS, and have a
couple of questions:

In Section 3., should

   TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 = {0xTBD,0xTBD};

end with ...SHA384 instead?

   For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash
   function SHALL be used and Clients and Servers MUST NOT negotiate
   curves of less than 384 bits.

requires SHA384 as the PRF, and I don't know what else SHA256 could
refer to for an AEAD ciphersuite.

I'm also curious whether there is a precedent in other RFCs for an
explicit minimum curve bits, or perhaps a de facto implementer's rule?

Regards,
Pete Dettman

---

From: Sean Turner <[email-masked]>
Date: Mon, 11 Jul 2016 10:35:18 -0400

> On Jul 10, 2016, at 03:36, [email-masked] wrote:
> 
> Hi,
> 
> I'm curious as to the relationship between this TLS WG draft and the DICE profile for IoT (currently in Auth48):
> https://tools.ietf.org/html/draft-ietf-dice-profile
> 

There’s might be a relationship between the DICE profile and this draft in the future.

The DICE draft profiles the existing set of cipher suites that are already defined for IoT; the complete list can be found here:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

draft-ietf-tls-ecdhe-psk-aead is adding more algorithms to that list.  The DICE profile can be updated later to include these newly defined cipher suites if that’s what the WG wants to do.

Make sense?

spt

---

From: Sean Turner <[email-masked]>
Date: Mon, 11 Jul 2016 10:40:31 -0400

I think I can take this bit:

> explicit minimum curve bits, or perhaps a de facto implementer's rule?

I’d be happy to be wrong here. but to my knowledge no there’s not been an explicit minimum for curve bits.  There have however been similar (at least in my non-cryptographer mind) for RSA key sizes so if we wanted to define an explicit minimum curve bits then we could.

spt

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 11 Jul 2016 13:26:42 -0700 (PDT)

I'm glad I have to opportunity to make you happy Sean :-)

On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
> I'd be happy to be wrong here. but to my knowledge no there's not been
> an explicit minimum for curve bits.  There have however been similar (at
> least in my non-cryptographer mind) for RSA key sizes so if we wanted to
> define an explicit minimum curve bits then we could.

  draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring
the curves used provide commensurate strength with the ciphersuite
negotiated. Section 10, "Implementation Considerations", says:

   It is RECOMMENDED that implementations take note of the strength
   estimates of particular groups and to select a ciphersuite providing
   commensurate security with its hash and encryption algorithms.  A
   ciphersuite whose encryption algorithm has a keylength less than the
   strength estimate, or whose hash algorithm has a blocksize that is
   less than twice the strength estimate SHOULD NOT be used.

  And I would like to take this opportunity to remind everyone that
the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant
to dictionary attack and the former is not.

  regards,

  Dan.

---

From: <[email-masked]>
Date: Tue, 12 Jul 2016 06:04:17 +0000 (UTC)

Hi Sean,
That might be a good thing, yes. If so, it would be best to make that relationship explicit with an "Updates: " header note, referencing DICE in this document, and explaining how it is extending it. 
thanks,
Gabriel 

    On Monday, July 11, 2016 7:35 AM, Sean Turner <[email-masked]> wrote:

Make sense?

spt