Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Thank you for the clarifying text. I have added it on my local copy.
Yours,
Daniel

On Mon, May 22, 2017 at 1:35 PM, Benjamin Kaduk  wrote:

> Sorry for the slow reply.
>
> On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote:
> > Thank you,
> >
> > Your comments have all been addressed. I have one remaining
> clarification.
> > In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and
> not
> > only for the cipher suites of the draft. In your opinion do we clarify
> > this, and should we use something else than SHOULD NOT ?
>
> It's somewhat awkward, as what we really want to do is Update RFC
> 5489 to add this prohibition there.  But, that's more process to
> jump through and this document is already at a late stage, so I do
> not actually propose doing that.  I would be okay saying
>
>   As such, all ECDHE_PSK ciphers, including those defined outside
>   this document, SHOULD NOT be negotiated in TLS versions prior to
>   1.2.
>
> to match up with the MUST NOT text we have for these new ciphers.
> (Taking into account Martin's text that the prohibition is on
> negotiating them, but offering them in a ClientHello that also
> offers the old version is okay.)
>
> -Ben
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Benjamin Kaduk]

Sorry for the slow reply.

On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote:
> Thank you,
> 
> Your comments have all been addressed. I have one remaining clarification.
> In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and not
> only for the cipher suites of the draft. In your opinion do we clarify
> this, and should we use something else than SHOULD NOT ?

It's somewhat awkward, as what we really want to do is Update RFC
5489 to add this prohibition there.  But, that's more process to
jump through and this document is already at a late stage, so I do
not actually propose doing that.  I would be okay saying

  As such, all ECDHE_PSK ciphers, including those defined outside
  this document, SHOULD NOT be negotiated in TLS versions prior to
  1.2.

to match up with the MUST NOT text we have for these new ciphers.
(Taking into account Martin's text that the prohibition is on
negotiating them, but offering them in a ClientHello that also
offers the old version is okay.)

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Thank you,

Your comments have all been addressed. I have one remaining clarification.
In my text the SHOULD NOT was intended to the ECDHE_PSK in general, and not
only for the cipher suites of the draft. In your opinion do we clarify
this, and should we use something else than SHOULD NOT ?

Thanks for the reviews!

Yours,
Daniel

> (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK
> authentication, the PSK and pre-master are treated by distinct hash
> function with distinct properties. This may introduce vulnerabilities over
> the expected security provided by the constructed pre-master. As such
> TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.

The general tenor of this text addresses my concern, yes, but feel
free to use editorial discretion and not bother putting it in, if
you don't think it's useful.  (BTW, I think we are still TLS1.0 and
TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD
NOT in the last sentence is not quite what is intended.)

On Fri, May 19, 2017 at 12:27 PM, Benjamin Kaduk  wrote:

> On Fri, May 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote:
> > Hi Benjamin,
> >
> > Thank you for the review. Please find my comments inline and let me know
> if
> > you agree with the proposed text. I believe the only point not addressed
> > concerns the addition of CCM-256 which has been remove after discussion
> > during the WGLC.
> >
> > Thanks you for the review,
> >
> > Yours,
> > Daniel
> >
> > On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk  wrote:
> >
> > > Hi all,
> > >
> > > I have reviewed this document as part of the security directorate's
> > > ongoing effort to review all IETF documents being processed by the
> > > IESG.  These comments were written primarily for the benefit of the
> > > security area directors.  Document editors and WG chairs should
> > > treat these comments just like any other last call comments.
> > >
> > > This document is ready with nits.
> > >
> > > Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
> > > space, thought of as a cross product of key exchange and
> > > cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
> > > but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
> > > not quite this one.
> > >
> > > That said, it seems a little silly to only partially fill the gap
> > > (by omitting the AES_256_CCM* cipher suites), even though there is
> > > not currently demand for them.
> > >
> > > MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and
> > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384  were mentioned in the 01 and
> removed
> > after  the WGLC. [0] The issue was whether or not introducing new ciphers
> > not supported by TLS1.3. In 01, we though of adding the code point for
> > TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of
> > the cipher suites proposed.In case of needs these could still be
> supported
> > later by TLS1.3. The consensus seems to not introduce ciphers that would
> > not be handled by TLS1.3. If the WG decides otherwise, these could still
> be
> > added.
> >
> > [0]
> > https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/?
> qid=6e4713be1d71bae6718c6e6e6c4b8007
>
> That seems like a reasonable position for the WG to take, given how
> close TLS 1.3 is to publication.  (It would also be reasonable to
> define the full cross-product for TLS 1.2 only and have TLS 1.3 just
> use a subset, but I have no real preference.)
>
> >
> > > This document is just assembling pieces that were already specified
> > > elsewhere, so it need not contain much detail itself, which is fine.
> > > That said, I think section 3 should probably state explicitly which
> > > pieces it uses, instead of a vague reference of being "based on RFC
> > > 4279".  So, "The ServerKeyExchange and ClientKeyExchange messages
> > > from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
> > > computed in the same manner as for ECDHE_PSK key exchange in RFC
> > > 5489."  (I am not sure why RFC 4279 is cited in the current text; it
> > > does not cover ECDHE_PSK.)
> > >
> >
> > MGLT: I agree we coudl be more explicit, here are the changes I propose.
> I
> > believe it address your purpose.
> >
> > OLD:
> >
> > Messages and pre-master secret construction in this
> > document are based on [RFC4279 ].
> >
> > NEW:
> >
> > Messages and pre-master secret construction in this
> > document are defined in [RFC5489]. The ServerKeyExchange
> > and ClientKeyExchange messages and premaster secret is
> > computed as for  the ECDHE_PSK key exchange.
>
> That basically works for me, though I'd tweak the phrasing slightly
> for clarity/grammar:
>
> NEW2:
>
> Messages and pre-master secret construction in this
> document are defined in [RFC5489]. The ServerKeyExchange
> and ClientKeyExchange messages are used and the premaster secret is
> computed as for the ECDHE_PSK key exchange.
>
>
> >
> > > The premaster_secret st

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Benjamin Kaduk]

On Fri, May 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote:
> Hi Benjamin,
> 
> Thank you for the review. Please find my comments inline and let me know if
> you agree with the proposed text. I believe the only point not addressed
> concerns the addition of CCM-256 which has been remove after discussion
> during the WGLC.
> 
> Thanks you for the review,
> 
> Yours,
> Daniel
> 
> On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk  wrote:
> 
> > Hi all,
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should
> > treat these comments just like any other last call comments.
> >
> > This document is ready with nits.
> >
> > Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
> > space, thought of as a cross product of key exchange and
> > cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
> > but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
> > not quite this one.
> >
> > That said, it seems a little silly to only partially fill the gap
> > (by omitting the AES_256_CCM* cipher suites), even though there is
> > not currently demand for them.
> >
> > MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384  were mentioned in the 01 and removed
> after  the WGLC. [0] The issue was whether or not introducing new ciphers
> not supported by TLS1.3. In 01, we though of adding the code point for
> TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of
> the cipher suites proposed.In case of needs these could still be supported
> later by TLS1.3. The consensus seems to not introduce ciphers that would
> not be handled by TLS1.3. If the WG decides otherwise, these could still be
> added.
> 
> [0]
> https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/?qid=6e4713be1d71bae6718c6e6e6c4b8007

That seems like a reasonable position for the WG to take, given how
close TLS 1.3 is to publication.  (It would also be reasonable to
define the full cross-product for TLS 1.2 only and have TLS 1.3 just
use a subset, but I have no real preference.)

> 
> > This document is just assembling pieces that were already specified
> > elsewhere, so it need not contain much detail itself, which is fine.
> > That said, I think section 3 should probably state explicitly which
> > pieces it uses, instead of a vague reference of being "based on RFC
> > 4279".  So, "The ServerKeyExchange and ClientKeyExchange messages
> > from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
> > computed in the same manner as for ECDHE_PSK key exchange in RFC
> > 5489."  (I am not sure why RFC 4279 is cited in the current text; it
> > does not cover ECDHE_PSK.)
> >
> 
> MGLT: I agree we coudl be more explicit, here are the changes I propose. I
> believe it address your purpose.
> 
> OLD:
> 
> Messages and pre-master secret construction in this
> document are based on [RFC4279 ].
> 
> NEW:
> 
> Messages and pre-master secret construction in this
> document are defined in [RFC5489]. The ServerKeyExchange
> and ClientKeyExchange messages and premaster secret is
> computed as for  the ECDHE_PSK key exchange.

That basically works for me, though I'd tweak the phrasing slightly
for clarity/grammar:

NEW2:

Messages and pre-master secret construction in this
document are defined in [RFC5489]. The ServerKeyExchange
and ClientKeyExchange messages are used and the premaster secret is
computed as for the ECDHE_PSK key exchange.


> 
> > The premaster_secret structure so used basically ends up putting the
> > ECDH output first followed by the static PSK; with the pre-TLS 1.2
> > PRF, that would give the ECDH shared secret to md5 and the PSK to
> > sha1, which is perhaps another reason to not use these with pre-1.2
> > worth mentioning (in addition to the AEAD availability).
> >
> 
> MGLT: I believe the following text address your concern, however I am
> wondering if we are not going beyond the scope of expected considerations.

It perhaps is and perhaps is not worth mentioning, yes.

> In addition, it is worth noting that TLS1.0  and
> TL1.2  splits the premaster in two parts. The PRF
> results of mixing the two pseudorandom streams with distinct hash functions

"results of" is an unusual phrasing; "results from" might be more
familiar.

> (MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK
> authentication, the PSK and pre-master are treated by distinct hash
> function with distinct properties. This may introduce vulnerabilities over
> the expected security provided by the constructed pre-master. As such
> TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.

The general tenor of this text addresses my concern, yes, but feel
free to use editorial discretion and 

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Hi Martin,

Thank you for the proposed text. It was very clear and I took it entirely,
just changing s/TLSv1/TLS 1/.

Yours,
Daniel


The current text is as follows:



 The cipher suites defined in this document MUST NOT be negotiated
for any version of (D)TLS other than TLS 1.2.

 TLS version 1.3 and later negotiate these features in a different
manner. Unlike TLS 1.2, TLS 1.3 separates authentication and cipher suite
negotiation  Section 1.2. TLS 1.3
supports PSK with ECDHE key exchange and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256
and  TLS_AES_128_CCM_SHA256 are part of the specification. As a result,
TLS 1.3 and higher versions, negotiate and support these cipher suites
in a different way. 

The cipher suites defined in this document make use of the
authenticated encryption with additional data (AEAD) defined in TLS 1.2
 and DTLS 1.2 .
Earlier versions of TLS do not have support for AEAD and consequently,
the cipher suites defined in this document MUST NOT be negotiated in TLS
versions prior to 1.2.  In addition, it is worth noting that TLS 1.0
 and TL1.2  splits the
pre-master in two parts. The PRF results of mixing the two pseudorandom
streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing
them together. In the case of ECDHE_PSK authentication, the PSK and
pre-master are treated by distinct hash function with distinct
properties. This may introduce vulnerabilities over the expected
security provided by the constructed pre-master. As such TLS 1.0 and
TLS 1.1 SHOULD NOT be used with ECDHE_PSK.

A client that offers the cipher suites from this document in
ClientHello.cipher_suites in combination with (3,1) "TLS 1.0" or (3,2)
"TLS 1.1" in ClientHello.client_version MUST support TLS 1.2 and MUST
accept the server to negotiate TLS 1.2 for the current session.  If the
client does not support TLS 1.2 or is not willing to negotiate TLS 1.2,
then this client MUST NOT offer any of these cipher suites with a lower
protocol version than (3,3) "TLS 1.2" in ClientHello.client_version.

A server receiving a ClientHello and a client_version indicating
(3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
this document in ClientHello.cipher_suites can safely assume that the
client supports TLS 1.2 and is willing to use it. The server MUST NOT
negotiate these cipher suites with TLS protocol versions earlier than
TLS 1.2. Not requiring clients to indicate their support for TLS 1.2
cipher suites exclusively through ClientHello.client_hello improves the
interoperability in the installed base and use of TLS 1.2 AEAD cipher
suites without upsetting the installed base of version-intolerant TLS
servers, results in more TLS handshakes succeeding and obviates fallback
mechanisms.


On Fri, May 19, 2017 at 10:17 AM, Martin Rex  wrote:

> Benjamin Kaduk wrote:
> >
> > Some other editorial nits follow.
> >
> > In section 4, "these cipher suites MUST NOT be negotiated in TLS
> > versions prior to 1.2" should probably clarify that "these" cipher
> > suites are the new ones specified by this document.
>
>
> This reminds me of the specification goofs in several TLSv1.2-related
> documents about AEAD cipher suites which are responsible for the viability
> of the POODLE attack and other exploitable fallback hacks.
>
> It would be much preferable to avoid/fix those problems and facilitate
> the migration to and use of TLSv1.2 without failing TLS handshakes and
> band aids such as TLS_FALLBACK_SCSV
>
>
> Suggested improvement:
>
>The cipher suites defined in this document make use of the
>authenticated encryption with additional data (AEAD) defined in TLS
>1.2 [RFC5246] and DTLS 1.2 [RFC6347].  Earlier versions of TLS do not
>have support for AEAD and consequently, these cipher suites MUST NOT
> -  be negotiated in TLS versions prior to 1.2.  Clients MUST NOT offer
> -  these cipher suites if they do not offer TLS 1.2 or later.  Servers,
> -  which select an earlier version of TLS MUST NOT select one of these
> -  cipher suites.  A client MUST treat the selection of these cipher
> -  suites in combination with a version of TLS that does not support
> -  AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
> -  'illegal_parameter' TLS alert.
> +   A client that offers
> +  the cipher suites from this document in ClientHello.cipher_suites
> +  in combination with (3,1) "TLSv1.0" or (3,2) "TLSv1.1" in
> +  ClientHello.client_version MUST support TLSv1.2 and MUST accept
> +  the server to negotiate TLSv1.2 for the current session.  If the
> +  client does not support TLSv1.2 or is not willing to negotiate TLSv1.2,
> +  then this client MUST NOT offer any of these cipher suites with a
> +  lower protocol version than (3,3) "TLSv1.2" in
> ClientHello.client_version.
> +  A server receiving a ClientHello and a client_version indicating
> +  (3,1) "TLSv1.0" or (3,2) "TLSv1.1" and any of the ciph

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Hi Benjamin and Dave,

Thanks for the clarification. Considering also Roman' s and Ben' s comments
the section is built as follow. 1) Limit cipher suites to TLS1.2, 2)
explain how TLS1.3 and higher version negotiate them 3) bring all
explanation foe the previous versions.

Yours,
Daniel

The text is as follows:

 The cipher suites defined in this document MUST NOT be negotiated
for any version of (D)TLS other than TLS1.2.

 TLS version 1.3 and later negotiate these features in a different
manner. Unlike TLS1.2, TLS1.3 separates authentication and cipher suite
negotiation  Section 1.2. TLS1.3
supports PSK with ECDHE key exchange and the cipher suites
TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256
and  TLS_AES_128_CCM_SHA256 are part of the specification. As a result,
TLS 1.3 and higher versions, negotiate and support these cipher suites
in a different way. 

The cipher suites defined in this document make use of the
authenticated encryption with additional data (AEAD) defined in TLS 1.2
 and DTLS 1.2 .
Earlier versions of TLS do not have support for AEAD and consequently,
the cipher suites defined in this document MUST NOT be negotiated in TLS
versions prior to 1.2.  In addition, it is worth noting that TLS1.0
 and TL1.2  splits teh
pre-master in two parts. The PRF results of mixing the two pseudorandom
streams with distinct hash functions (MD5 and SHA-1) by exclusive-ORing
them together. In the case of ECDHE_PSK authentication, the PSK and
pre-master are treated by distinct hash function with distinct
properties. This may introduce vulnerabilities over the expected
security provided by the constructed pre-master. As such TLS1.0 and
TLS1.1 SHOULD NOT be used with ECDHE_PSK.  Clients MUST NOT offer these
cipher suites defined in this document if they do not offer TLS 1.2 or
later. Servers that select an earlier version of TLS MUST NOT select one
of these cipher suites. A client MUST treat the selection of these
cipher suites in combination with a version of TLS that does not support
AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
'illegal_parameter' TLS alert.




On Fri, May 19, 2017 at 10:39 AM, Benjamin Kaduk  wrote:

> On 05/19/2017 02:16 AM, Dave Garrett wrote:
>
> On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:
>
> In section 4, "these cipher suites MUST NOT be negotiated in TLS
> versions prior to 1.2" should probably clarify that "these" cipher
> suites are the new ones specified by this document.
>
> Probably should be: "the cipher suites defined in this document
> MUST NOT be negotiated for any version of TLS other than 1.2."
>
> The sentence mentioning TLS 1.3+ could be moved up to right after
> and just say: "TLS version 1.3 and later negotiate these features in
> a different manner."
>
>
>
>
> That's probably best, yes.  The interaction between this document and TLS
> 1.3 is a little weird, and it's not entirely clear to me that this one
> needs to say much of anything about TLS 1.3, given that TLS 1.3 changes all
> the relevant messages and key hierarchy and such.
>
> -Ben
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault]

Hi Benjamin,

Thank you for the review. Please find my comments inline and let me know if
you agree with the proposed text. I believe the only point not addressed
concerns the addition of CCM-256 which has been remove after discussion
during the WGLC.

Thanks you for the review,

Yours,
Daniel

On Fri, May 19, 2017 at 12:38 AM, Benjamin Kaduk  wrote:

> Hi all,
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should
> treat these comments just like any other last call comments.
>
> This document is ready with nits.
>
> Essentially, we are filling in a gap in the TLS (< 1.3) ciphersuite
> space, thought of as a cross product of key exchange and
> cipher+mac/AEAD -- we have some of the combinations (PSK with ECDHE
> but no AES-[GC]CM, PSK with AES-GCM but only non-EC DH, etc.) but
> not quite this one.
>
> That said, it seems a little silly to only partially fill the gap
> (by omitting the AES_256_CCM* cipher suites), even though there is
> not currently demand for them.
>
> MGLT: TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 and
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384  were mentioned in the 01 and removed
after  the WGLC. [0] The issue was whether or not introducing new ciphers
not supported by TLS1.3. In 01, we though of adding the code point for
TLS1.2 and then specify that TLS1.3 was only implementing a **subset** of
the cipher suites proposed.In case of needs these could still be supported
later by TLS1.3. The consensus seems to not introduce ciphers that would
not be handled by TLS1.3. If the WG decides otherwise, these could still be
added.

[0]
https://mailarchive.ietf.org/arch/msg/tls/M442CwmUMxrYJR8FjCh3h-a69o4/?qid=6e4713be1d71bae6718c6e6e6c4b8007




> This document is just assembling pieces that were already specified
> elsewhere, so it need not contain much detail itself, which is fine.
> That said, I think section 3 should probably state explicitly which
> pieces it uses, instead of a vague reference of being "based on RFC
> 4279".  So, "The ServerKeyExchange and ClientKeyExchange messages
> from RFC 5489 for ECDHE_PSK are used, and the premaster secret is
> computed in the same manner as for ECDHE_PSK key exchange in RFC
> 5489."  (I am not sure why RFC 4279 is cited in the current text; it
> does not cover ECDHE_PSK.)
>

MGLT: I agree we coudl be more explicit, here are the changes I propose. I
believe it address your purpose.

OLD:

Messages and pre-master secret construction in this
document are based on [RFC4279 ].

NEW:

Messages and pre-master secret construction in this
document are defined in [RFC5489]. The ServerKeyExchange
and ClientKeyExchange messages and premaster secret is
computed as for  the ECDHE_PSK key exchange.


> The premaster_secret structure so used basically ends up putting the
> ECDH output first followed by the static PSK; with the pre-TLS 1.2
> PRF, that would give the ECDH shared secret to md5 and the PSK to
> sha1, which is perhaps another reason to not use these with pre-1.2
> worth mentioning (in addition to the AEAD availability).
>

MGLT: I believe the following text address your concern, however I am
wondering if we are not going beyond the scope of expected considerations.

In addition, it is worth noting that TLS1.0  and
TL1.2  splits the premaster in two parts. The PRF
results of mixing the two pseudorandom streams with distinct hash functions
(MD5 and SHA-1) by exclusive-ORing them together. In the case of ECDHE_PSK
authentication, the PSK and pre-master are treated by distinct hash
function with distinct properties. This may introduce vulnerabilities over
the expected security provided by the constructed pre-master. As such
TLS1.0 and TLS1.1 SHOULD NOT be used with ECDHE_PSK.


> The security considerations largely refer to those of the other
> documents providing the pieces that are combined together here;
> those referenced security considerations sections are more than
> adequate here, as this document itself does not really do anything
> particularly novel.  That said, if we are going to reiterate the
> entropy requirement for PSKs inline, we probably ought to also
> reiterate the nonce-reuse considerations for GCM and CCM.  The
> relevant constructions help, but there are still ways to mess up and
> reuse a nonce when doing crypto in parallel, if I remember the
> GCM/TLS document's security considerations correctly.
>

MGLT: I believe the following text address your comments.

 GCM or CCM encryption - even of different clear text - re-using a
nonce with a same key undermines the security of GCM and CCM. As a
result, GCM and CCM MUST only be used with system guaranteeing nonce
uniqueness .


>
> Some other editorial nits follow.
>
> I see we're already discussing "perfect forward secrecy" vs.
> "forward 

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Benjamin Kaduk]

On 05/19/2017 02:16 AM, Dave Garrett wrote:
> On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:
>> In section 4, "these cipher suites MUST NOT be negotiated in TLS
>> versions prior to 1.2" should probably clarify that "these" cipher
>> suites are the new ones specified by this document.
> Probably should be: "the cipher suites defined in this document
> MUST NOT be negotiated for any version of TLS other than 1.2."
>
> The sentence mentioning TLS 1.3+ could be moved up to right after
> and just say: "TLS version 1.3 and later negotiate these features in
> a different manner."
>
>

That's probably best, yes.  The interaction between this document and
TLS 1.3 is a little weird, and it's not entirely clear to me that this
one needs to say much of anything about TLS 1.3, given that TLS 1.3
changes all the relevant messages and key hierarchy and such.

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Martin Rex]

Benjamin Kaduk wrote:
> 
> Some other editorial nits follow.
> 
> In section 4, "these cipher suites MUST NOT be negotiated in TLS
> versions prior to 1.2" should probably clarify that "these" cipher
> suites are the new ones specified by this document.


This reminds me of the specification goofs in several TLSv1.2-related
documents about AEAD cipher suites which are responsible for the viability
of the POODLE attack and other exploitable fallback hacks.

It would be much preferable to avoid/fix those problems and facilitate
the migration to and use of TLSv1.2 without failing TLS handshakes and
band aids such as TLS_FALLBACK_SCSV


Suggested improvement:

   The cipher suites defined in this document make use of the
   authenticated encryption with additional data (AEAD) defined in TLS
   1.2 [RFC5246] and DTLS 1.2 [RFC6347].  Earlier versions of TLS do not
   have support for AEAD and consequently, these cipher suites MUST NOT
-  be negotiated in TLS versions prior to 1.2.  Clients MUST NOT offer
-  these cipher suites if they do not offer TLS 1.2 or later.  Servers,
-  which select an earlier version of TLS MUST NOT select one of these
-  cipher suites.  A client MUST treat the selection of these cipher
-  suites in combination with a version of TLS that does not support
-  AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
-  'illegal_parameter' TLS alert.
+   A client that offers
+  the cipher suites from this document in ClientHello.cipher_suites
+  in combination with (3,1) "TLSv1.0" or (3,2) "TLSv1.1" in
+  ClientHello.client_version MUST support TLSv1.2 and MUST accept
+  the server to negotiate TLSv1.2 for the current session.  If the
+  client does not support TLSv1.2 or is not willing to negotiate TLSv1.2,
+  then this client MUST NOT offer any of these cipher suites with a
+  lower protocol version than (3,3) "TLSv1.2" in ClientHello.client_version.
+  A server receiving a ClientHello and a client_version indicating
+  (3,1) "TLSv1.0" or (3,2) "TLSv1.1" and any of the cipher suites from
+  this document in ClientHello.cipher_suites can safely assume that the
+  client supports TLSv1.2 and is willing to use it.  The server MUST
+  NOT negotiate these cipher suites with TLS protocol versions earlier
+  than TLSv1.2.
+
+  Not requiring clients to indicate their support for TLSv1.2 cipher
+  suites exclusively through ClientHello.client_hello improves the
+  interoperability in the installed base and use of TLSv1.2 AEAD
+  cipher suites without upsetting the installed base of version-intolerant
+  TLS servers, results in more TLS handshakes succeeding and obviates
+  fallback mechanisms.


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Dave Garrett]

On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:
> In section 4, "these cipher suites MUST NOT be negotiated in TLS
> versions prior to 1.2" should probably clarify that "these" cipher
> suites are the new ones specified by this document.

Probably should be: "the cipher suites defined in this document
MUST NOT be negotiated for any version of TLS other than 1.2."

The sentence mentioning TLS 1.3+ could be moved up to right after
and just say: "TLS version 1.3 and later negotiate these features in
a different manner."


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls