Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-ecdhe-psk-aead-05: (with COMMENT)

[Eric Rescorla]

This is just a result of goofy tooling. I.e., I removed my discuss but
didn't edit the rest of my comments
-Ekr


On Fri, Aug 11, 2017 at 11:13 AM, Daniel Migault <
daniel.miga...@ericsson.com> wrote:

> Hi Eric,
>
> Thank you for reviewing the document. Given your second comment, I suspect
> you are reading the version 04 while the current version is version 05 [1].
> I believe your comments have been addressed in the version 05.However let
> me know if you have other concerns.
>
> Regarding TLS1.3. we were asked to position the new code points toward
> TLS1.3, but I guess that was at the time the version was not indicated in
> the title, so in principle we could remove these references.I believe the
> text in version 05 address your comment, but here are the current version
> still cites TLS 1.3 in the following sections:
>
>- introduction: """AEAD algorithms that combine encryption and
>integrity protection are strongly recommended for (D)TLS [RFC7525
>] and non-AEAD algorithms are
>forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13
>
> ].
>""". Would you prefer to remove "and non-AEAD algorithms are forbidden to
>use in TLS 1.3 [I-D.ietf-tls-tls13
>
> 
>]" or it is fine to leave it as it is ?
>- section 3: """ 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 used to support equivalent functionality in TLS 1.3 [
>I-D.ietf-tls-tls13
>
> ].
>""". Would you prefer to have all mentioned text being removed or is it
>fine to leave it as it is ?
>
> Regarding the reference to the PRF of TLS 1.1, I think it concerns the
> text below which has been removed in the version 05.
>
> """
>
>[...]  The PRF results from
>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.   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, 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 [RFC2246 
> ] and TL1.2
>[RFC4346 ] splits the pre-master in 
> two parts.  The PRF results from
>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.
> """
>
> Yours,
>
> Daniel
>
> [1] https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-05
>
> On Thu, Aug 10, 2017 at 10:39 AM, Eric Rescorla  wrote:
>
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-tls-ecdhe-psk-aead-05: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> The citations to TLS 1.3 still seem pretty muddled. I think you
>> should just stop referencing and discussing 1.3.
>>
>
>> S 2.
>> I'm not sure that the discussion of the PRF is helpful here in
>> mandating the non-use of these cipher suites with TLS 1.1 and
>> below.
>>
>>
>
>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>

Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-ecdhe-psk-aead-05: (with COMMENT)

[Daniel Migault]

Hi Eric,

Thank you for reviewing the document. Given your second comment, I suspect
you are reading the version 04 while the current version is version 05 [1].
I believe your comments have been addressed in the version 05.However let
me know if you have other concerns.

Regarding TLS1.3. we were asked to position the new code points toward
TLS1.3, but I guess that was at the time the version was not indicated in
the title, so in principle we could remove these references.I believe the
text in version 05 address your comment, but here are the current version
still cites TLS 1.3 in the following sections:

   - introduction: """AEAD algorithms that combine encryption and integrity
   protection are strongly recommended for (D)TLS [RFC7525
   ] and non-AEAD algorithms are
   forbidden to use in TLS 1.3 [I-D.ietf-tls-tls13
   
].
   """. Would you prefer to remove "and non-AEAD algorithms are forbidden to
   use in TLS 1.3 [I-D.ietf-tls-tls13
   

   ]" or it is fine to leave it as it is ?
   - section 3: """ 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 used to support equivalent functionality in TLS 1.3 [
   I-D.ietf-tls-tls13
   
].
   """. Would you prefer to have all mentioned text being removed or is it
   fine to leave it as it is ?

Regarding the reference to the PRF of TLS 1.1, I think it concerns the text
below which has been removed in the version 05.

"""

   [...]  The PRF results from
   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.   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, 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 [RFC2246
] and TL1.2
   [RFC4346 ] splits the
pre-master in two parts.  The PRF results from
   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.
"""

Yours,

Daniel

[1] https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-05

On Thu, Aug 10, 2017 at 10:39 AM, Eric Rescorla  wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-tls-ecdhe-psk-aead-05: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/
>
>
>
> --
> COMMENT:
> --
>
> The citations to TLS 1.3 still seem pretty muddled. I think you
> should just stop referencing and discussing 1.3.
>

> S 2.
> I'm not sure that the discussion of the PRF is helpful here in
> mandating the non-use of these cipher suites with TLS 1.1 and
> below.
>
>


>
> ___
> 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

[TLS] Eric Rescorla's No Objection on draft-ietf-tls-ecdhe-psk-aead-05: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-tls-ecdhe-psk-aead-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/



--
COMMENT:
--

The citations to TLS 1.3 still seem pretty muddled. I think you
should just stop referencing and discussing 1.3.

S 2.
I'm not sure that the discussion of the PRF is helpful here in
mandating the non-use of these cipher suites with TLS 1.1 and
below.


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