You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Nikolay Izhikov <ni...@apache.org> on 2020/02/21 12:18:19 UTC
[DISCUSS] KIP-573: Enable TLSv1.3 by default
Hello,
I'd like to start a discussion of KIP [1]
This is follow-up for the KIP-553 [2]
Its goal is to enable TLSv1.3 by default.
Your comments and suggestions are welcome.
[1] https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
[2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Ismael Juma <is...@juma.me.uk>.
It's not ok for things to break for Java 8 users when they upgrade (even if
they can fix it by changing a config). So, I think we need to change the
KIP to offer more dynamic behavior: only enable TLS 1.3 if it's safe.
Ismael
On Mon, May 18, 2020, 8:59 AM Nikolay Izhikov <ni...@apache.org> wrote:
> > 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols`
> is `TLSv1.2, TLSv1.3`. How do these two configs interact
>
> `ssl.protocol` is what will be used, by default, in this KIP is stays
> unchanged (TLSv1.2) Please, see [1]
> `ssl.enabled.protocols` is list of protocols that *can* be used. This
> value is just passed to the `SSLEngine` implementation.
> Please, see DefaultSslEngineFactory#createSslEngine [2]
>
> > 2. My question is not about obsolete protocols, it is about people using
> TLS 1.2 with specified cipher suites. How will that behave when TLS 1.3 is
> enabled by default?
>
> They don’t change anything and all just work as expected on java11.
>
> > 3. An additional question is how does this impact Java 8 users?
>
> Yes.
> If SSLEngine doesn’t support TLSv1.3 then java8 users should explicitly
> modify `ssl.enabled.protocols` and set it to `TLSv1.2`.
>
> [1]
> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L218
> [2]
> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L164
>
> > 18 мая 2020 г., в 17:34, Ismael Juma <is...@juma.me.uk> написал(а):
> >
> > Nikolay,
> >
> > Thanks for the comments. More below:
> >
> > 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols`
> is `TLSv1.2, TLSv1.3`. How do these two configs interact?
> > 2. My question is not about obsolete protocols, it is about people using
> TLS 1.2 with specified cipher suites. How will that behave when TLS 1.3 is
> enabled by default?
> > 3. An additional question is how does this impact Java 8 users? Java 8
> will receive TLS 1.3 support later this year (
> https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently does
> not support it. One way to handle this would be to check if the underlying
> JVM supports TLS 1.3 before enabling it.
> >
> > I hope this clarifies my questions.
> >
> > Ismael
> >
> > On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <ni...@apache.org>
> wrote:
> > Hello, Ismael.
> >
> > Here is answers to your questions:
> >
> > > Quick question, the following is meant to include TLSv1.3 as well,
> right?
> > > Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to
> «TLSv1.2»
> >
> > I propose to have the following value
> SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
> >
> > > 1. `ssl.protocol` would remain TLSv1.2 with this change. It would be
> good to explain why that's OK.
> >
> > I think it covered by the following statements in KIP.
> > If you know more trustworthy sources of this kind of information,
> please, let me know.
> >
> > ```
> > For now, only TLS1.2 and TLS1.3 are recommended for the usage, other
> versions of TLS considered as obsolete:
> > • https://www.rfc-editor.org/info/rfc8446
> > •
> https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
> >
> > ```
> >
> > > 2. What is the behavior for people who have configured
> `ssl.cipher.suites`?
> > > The cipher suite names are different in TLS 1.3. What would be the
> behavior
> > > if the client requests TLS 1.3, but the server only has cipher suites
> for
> > > TLS 1.2? It would be good to explain the expected behavior and add
> tests to verify it.
> >
> > I think those users should update
> `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but
> obsolete) version of TLS they use.
> > After one should migrate to the reliable TLS version.
> > This reflected in the KIP:
> >
> > ```
> > Migration: Users who are using TLSv1.1 and TLSv1 should enable these
> versions of the protocol with the explicit configuration property
> "ssl.enabled.protocols"
> > ```
> >
> > > 25 февр. 2020 г., в 08:57, Nikolay Izhikov <ni...@gmail.com>
> написал(а):
> > >
> > > Hello.
> > >
> > > Any feedback on this?
> > >
> > > This change seems very simple, I can start vote right now if nothing
> to discuss here.
> > >
> > >> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <ni...@gmail.com>
> написал(а):
> > >>
> > >> Hello,
> > >>
> > >> I'd like to start a discussion of KIP [1]
> > >> This is follow-up for the KIP-553 [2]
> > >>
> > >> Its goal is to enable TLSv1.3 by default.
> > >>
> > >> Your comments and suggestions are welcome.
> > >>
> > >> [1]
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
> > >> [2]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
> > >
> >
>
>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Nikolay Izhikov <ni...@apache.org>.
Ismael, thanks for the clarification.
I updated the KIP according to your proposal.
> 21 мая 2020 г., в 17:06, Ismael Juma <is...@juma.me.uk> написал(а):
>
> Given what we've seen in the test, it would be good to mention that TLS 1.3
> will not work for users who have configured ciphers explicitly. If such
> users want to use TLS 1.3, they will have to update the list of ciphers to
> include TLS 1.3 ciphers (which use a different naming convention). TLS 1.2
> will continue to work as usual, so there is no compatibility issue.
>
> Ismael
>
> On Tue, May 19, 2020 at 12:19 PM Nikolay Izhikov <ni...@apache.org>
> wrote:
>
>> PR - https://github.com/apache/kafka/pull/8695
>>
>>> 18 мая 2020 г., в 23:30, Nikolay Izhikov <ni...@gmail.com>
>> написал(а):
>>>
>>> Hello, Colin
>>>
>>> We need hack only because TLSv1.3 not supported in java8.
>>>
>>>> Java 8 will receive TLS 1.3 support later this year (
>> https://java.com/en/jre-jdk-cryptoroadmap.html)
>>>
>>> We can
>>>
>>> 1. Enable TLSv1.3 for java11 for now. And after java8 get TLSv1.3
>> support remove it.
>>> 2. Or we can wait and enable it after java8 update.
>>>
>>> What do you think?
>>>
>>>> 18 мая 2020 г., в 22:51, Ismael Juma <is...@juma.me.uk> написал(а):
>>>>
>>>> Yeah, agreed. One option is to actually only change this in Apache Kafka
>>>> 3.0 and avoid the hack altogether. We could make TLS 1.3 the default and
>>>> have 1.2 as one of the enabled protocols.
>>>>
>>>> Ismael
>>>>
>>>> On Mon, May 18, 2020 at 12:24 PM Colin McCabe <cm...@apache.org>
>> wrote:
>>>>
>>>>> Hmm. It would be good to figure out if we are going to remove this
>>>>> compatibility hack in the next major release of Kafka? In other
>> words, in
>>>>> Kafka 3.0, will we enable TLS 1.3 by default even if the cipher suite
>> is
>>>>> specified?
>>>>>
>>>>> best,
>>>>> Colin
>>>>>
>>>>>
>>>>> On Mon, May 18, 2020, at 09:26, Ismael Juma wrote:
>>>>>> Sounds good.
>>>>>>
>>>>>> Ismael
>>>>>>
>>>>>>
>>>>>> On Mon, May 18, 2020, 9:03 AM Nikolay Izhikov <ni...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>>>> A safer approach may be to only add TLS 1.3 to the list if the
>> cipher
>>>>>>> suite config has not been specified.
>>>>>>>> So, if TLS 1.3 is added to the list by Kafka, it would seem that it
>>>>>>> would not work if the user specified a list of cipher suites for
>>>>> previous
>>>>>>> TLS versions
>>>>>>>
>>>>>>> Let’s just add test for this case?
>>>>>>> I can prepare the preliminary PR for this KIP and add this kind of
>>>>> test to
>>>>>>> it.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>>
>>>>>>>> 18 мая 2020 г., в 18:59, Nikolay Izhikov <NI...@gmail.com>
>>>>>>> написал(а):
>>>>>>>>
>>>>>>>>> 1. I meant that `ssl.protocol` is TLSv1.2 while
>>>>> `ssl.enabled.protocols`
>>>>>>> is `TLSv1.2, TLSv1.3`. How do these two configs interact
>>>>>>>>
>>>>>>>> `ssl.protocol` is what will be used, by default, in this KIP is
>> stays
>>>>>>> unchanged (TLSv1.2) Please, see [1]
>>>>>>>> `ssl.enabled.protocols` is list of protocols that *can* be used.
>>>>> This
>>>>>>> value is just passed to the `SSLEngine` implementation.
>>>>>>>> Please, see DefaultSslEngineFactory#createSslEngine [2]
>>>>>>>>
>>>>>>>>> 2. My question is not about obsolete protocols, it is about people
>>>>>>> using TLS 1.2 with specified cipher suites. How will that behave when
>>>>> TLS
>>>>>>> 1.3 is enabled by default?
>>>>>>>>
>>>>>>>> They don’t change anything and all just work as expected on java11.
>>>>>>>>
>>>>>>>>> 3. An additional question is how does this impact Java 8 users?
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>> If SSLEngine doesn’t support TLSv1.3 then java8 users should
>>>>> explicitly
>>>>>>> modify `ssl.enabled.protocols` and set it to `TLSv1.2`.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>
>>>>>
>> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L218
>>>>>>>> [2]
>>>>>>>
>>>>>
>> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L164
>>>>>>>>
>>>>>>>>> 18 мая 2020 г., в 17:34, Ismael Juma <is...@juma.me.uk>
>>>>> написал(а):
>>>>>>>>>
>>>>>>>>> Nikolay,
>>>>>>>>>
>>>>>>>>> Thanks for the comments. More below:
>>>>>>>>>
>>>>>>>>> 1. I meant that `ssl.protocol` is TLSv1.2 while
>>>>> `ssl.enabled.protocols`
>>>>>>> is `TLSv1.2, TLSv1.3`. How do these two configs interact?
>>>>>>>>> 2. My question is not about obsolete protocols, it is about people
>>>>>>> using TLS 1.2 with specified cipher suites. How will that behave when
>>>>> TLS
>>>>>>> 1.3 is enabled by default?
>>>>>>>>> 3. An additional question is how does this impact Java 8 users?
>>>>> Java 8
>>>>>>> will receive TLS 1.3 support later this year (
>>>>>>> https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently
>> does
>>>>>>> not support it. One way to handle this would be to check if the
>>>>> underlying
>>>>>>> JVM supports TLS 1.3 before enabling it.
>>>>>>>>>
>>>>>>>>> I hope this clarifies my questions.
>>>>>>>>>
>>>>>>>>> Ismael
>>>>>>>>>
>>>>>>>>> On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <
>>>>> nizhikov@apache.org>
>>>>>>> wrote:
>>>>>>>>> Hello, Ismael.
>>>>>>>>>
>>>>>>>>> Here is answers to your questions:
>>>>>>>>>
>>>>>>>>>> Quick question, the following is meant to include TLSv1.3 as well,
>>>>>>> right?
>>>>>>>>>> Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS
>> to
>>>>>>> «TLSv1.2»
>>>>>>>>>
>>>>>>>>> I propose to have the following value
>>>>>>> SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
>>>>>>>>>
>>>>>>>>>> 1. `ssl.protocol` would remain TLSv1.2 with this change. It would
>>>>> be
>>>>>>> good to explain why that's OK.
>>>>>>>>>
>>>>>>>>> I think it covered by the following statements in KIP.
>>>>>>>>> If you know more trustworthy sources of this kind of information,
>>>>>>> please, let me know.
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>> For now, only TLS1.2 and TLS1.3 are recommended for the usage,
>> other
>>>>>>> versions of TLS considered as obsolete:
>>>>>>>>> • https://www.rfc-editor.org/info/rfc8446
>>>>>>>>> •
>>>>>>>
>>>>>
>> https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>>
>>>>>>>>>> 2. What is the behavior for people who have configured
>>>>>>> `ssl.cipher.suites`?
>>>>>>>>>> The cipher suite names are different in TLS 1.3. What would be the
>>>>>>> behavior
>>>>>>>>>> if the client requests TLS 1.3, but the server only has cipher
>>>>> suites
>>>>>>> for
>>>>>>>>>> TLS 1.2? It would be good to explain the expected behavior and add
>>>>>>> tests to verify it.
>>>>>>>>>
>>>>>>>>> I think those users should update
>>>>>>> `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but
>>>>>>> obsolete) version of TLS they use.
>>>>>>>>> After one should migrate to the reliable TLS version.
>>>>>>>>> This reflected in the KIP:
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>> Migration: Users who are using TLSv1.1 and TLSv1 should enable
>> these
>>>>>>> versions of the protocol with the explicit configuration property
>>>>>>> "ssl.enabled.protocols"
>>>>>>>>> ```
>>>>>>>>>
>>>>>>>>>> 25 февр. 2020 г., в 08:57, Nikolay Izhikov <
>> nizhikov.dev@gmail.com
>>>>>>
>>>>>>> написал(а):
>>>>>>>>>>
>>>>>>>>>> Hello.
>>>>>>>>>>
>>>>>>>>>> Any feedback on this?
>>>>>>>>>>
>>>>>>>>>> This change seems very simple, I can start vote right now if
>>>>> nothing
>>>>>>> to discuss here.
>>>>>>>>>>
>>>>>>>>>>> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <
>>>>> nizhikov.dev@gmail.com>
>>>>>>> написал(а):
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> I'd like to start a discussion of KIP [1]
>>>>>>>>>>> This is follow-up for the KIP-553 [2]
>>>>>>>>>>>
>>>>>>>>>>> Its goal is to enable TLSv1.3 by default.
>>>>>>>>>>>
>>>>>>>>>>> Your comments and suggestions are welcome.
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>
>>>>>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
>>>>>>>>>>> [2]
>>>>>>>
>>>>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Ismael Juma <is...@juma.me.uk>.
Given what we've seen in the test, it would be good to mention that TLS 1.3
will not work for users who have configured ciphers explicitly. If such
users want to use TLS 1.3, they will have to update the list of ciphers to
include TLS 1.3 ciphers (which use a different naming convention). TLS 1.2
will continue to work as usual, so there is no compatibility issue.
Ismael
On Tue, May 19, 2020 at 12:19 PM Nikolay Izhikov <ni...@apache.org>
wrote:
> PR - https://github.com/apache/kafka/pull/8695
>
> > 18 мая 2020 г., в 23:30, Nikolay Izhikov <ni...@gmail.com>
> написал(а):
> >
> > Hello, Colin
> >
> > We need hack only because TLSv1.3 not supported in java8.
> >
> >> Java 8 will receive TLS 1.3 support later this year (
> https://java.com/en/jre-jdk-cryptoroadmap.html)
> >
> > We can
> >
> > 1. Enable TLSv1.3 for java11 for now. And after java8 get TLSv1.3
> support remove it.
> > 2. Or we can wait and enable it after java8 update.
> >
> > What do you think?
> >
> >> 18 мая 2020 г., в 22:51, Ismael Juma <is...@juma.me.uk> написал(а):
> >>
> >> Yeah, agreed. One option is to actually only change this in Apache Kafka
> >> 3.0 and avoid the hack altogether. We could make TLS 1.3 the default and
> >> have 1.2 as one of the enabled protocols.
> >>
> >> Ismael
> >>
> >> On Mon, May 18, 2020 at 12:24 PM Colin McCabe <cm...@apache.org>
> wrote:
> >>
> >>> Hmm. It would be good to figure out if we are going to remove this
> >>> compatibility hack in the next major release of Kafka? In other
> words, in
> >>> Kafka 3.0, will we enable TLS 1.3 by default even if the cipher suite
> is
> >>> specified?
> >>>
> >>> best,
> >>> Colin
> >>>
> >>>
> >>> On Mon, May 18, 2020, at 09:26, Ismael Juma wrote:
> >>>> Sounds good.
> >>>>
> >>>> Ismael
> >>>>
> >>>>
> >>>> On Mon, May 18, 2020, 9:03 AM Nikolay Izhikov <ni...@apache.org>
> >>> wrote:
> >>>>
> >>>>>> A safer approach may be to only add TLS 1.3 to the list if the
> cipher
> >>>>> suite config has not been specified.
> >>>>>> So, if TLS 1.3 is added to the list by Kafka, it would seem that it
> >>>>> would not work if the user specified a list of cipher suites for
> >>> previous
> >>>>> TLS versions
> >>>>>
> >>>>> Let’s just add test for this case?
> >>>>> I can prepare the preliminary PR for this KIP and add this kind of
> >>> test to
> >>>>> it.
> >>>>>
> >>>>> What do you think?
> >>>>>
> >>>>>
> >>>>>> 18 мая 2020 г., в 18:59, Nikolay Izhikov <NI...@gmail.com>
> >>>>> написал(а):
> >>>>>>
> >>>>>>> 1. I meant that `ssl.protocol` is TLSv1.2 while
> >>> `ssl.enabled.protocols`
> >>>>> is `TLSv1.2, TLSv1.3`. How do these two configs interact
> >>>>>>
> >>>>>> `ssl.protocol` is what will be used, by default, in this KIP is
> stays
> >>>>> unchanged (TLSv1.2) Please, see [1]
> >>>>>> `ssl.enabled.protocols` is list of protocols that *can* be used.
> >>> This
> >>>>> value is just passed to the `SSLEngine` implementation.
> >>>>>> Please, see DefaultSslEngineFactory#createSslEngine [2]
> >>>>>>
> >>>>>>> 2. My question is not about obsolete protocols, it is about people
> >>>>> using TLS 1.2 with specified cipher suites. How will that behave when
> >>> TLS
> >>>>> 1.3 is enabled by default?
> >>>>>>
> >>>>>> They don’t change anything and all just work as expected on java11.
> >>>>>>
> >>>>>>> 3. An additional question is how does this impact Java 8 users?
> >>>>>>
> >>>>>> Yes.
> >>>>>> If SSLEngine doesn’t support TLSv1.3 then java8 users should
> >>> explicitly
> >>>>> modify `ssl.enabled.protocols` and set it to `TLSv1.2`.
> >>>>>>
> >>>>>> [1]
> >>>>>
> >>>
> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L218
> >>>>>> [2]
> >>>>>
> >>>
> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L164
> >>>>>>
> >>>>>>> 18 мая 2020 г., в 17:34, Ismael Juma <is...@juma.me.uk>
> >>> написал(а):
> >>>>>>>
> >>>>>>> Nikolay,
> >>>>>>>
> >>>>>>> Thanks for the comments. More below:
> >>>>>>>
> >>>>>>> 1. I meant that `ssl.protocol` is TLSv1.2 while
> >>> `ssl.enabled.protocols`
> >>>>> is `TLSv1.2, TLSv1.3`. How do these two configs interact?
> >>>>>>> 2. My question is not about obsolete protocols, it is about people
> >>>>> using TLS 1.2 with specified cipher suites. How will that behave when
> >>> TLS
> >>>>> 1.3 is enabled by default?
> >>>>>>> 3. An additional question is how does this impact Java 8 users?
> >>> Java 8
> >>>>> will receive TLS 1.3 support later this year (
> >>>>> https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently
> does
> >>>>> not support it. One way to handle this would be to check if the
> >>> underlying
> >>>>> JVM supports TLS 1.3 before enabling it.
> >>>>>>>
> >>>>>>> I hope this clarifies my questions.
> >>>>>>>
> >>>>>>> Ismael
> >>>>>>>
> >>>>>>> On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <
> >>> nizhikov@apache.org>
> >>>>> wrote:
> >>>>>>> Hello, Ismael.
> >>>>>>>
> >>>>>>> Here is answers to your questions:
> >>>>>>>
> >>>>>>>> Quick question, the following is meant to include TLSv1.3 as well,
> >>>>> right?
> >>>>>>>> Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS
> to
> >>>>> «TLSv1.2»
> >>>>>>>
> >>>>>>> I propose to have the following value
> >>>>> SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
> >>>>>>>
> >>>>>>>> 1. `ssl.protocol` would remain TLSv1.2 with this change. It would
> >>> be
> >>>>> good to explain why that's OK.
> >>>>>>>
> >>>>>>> I think it covered by the following statements in KIP.
> >>>>>>> If you know more trustworthy sources of this kind of information,
> >>>>> please, let me know.
> >>>>>>>
> >>>>>>> ```
> >>>>>>> For now, only TLS1.2 and TLS1.3 are recommended for the usage,
> other
> >>>>> versions of TLS considered as obsolete:
> >>>>>>> • https://www.rfc-editor.org/info/rfc8446
> >>>>>>> •
> >>>>>
> >>>
> https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
> >>>>>>>
> >>>>>>> ```
> >>>>>>>
> >>>>>>>> 2. What is the behavior for people who have configured
> >>>>> `ssl.cipher.suites`?
> >>>>>>>> The cipher suite names are different in TLS 1.3. What would be the
> >>>>> behavior
> >>>>>>>> if the client requests TLS 1.3, but the server only has cipher
> >>> suites
> >>>>> for
> >>>>>>>> TLS 1.2? It would be good to explain the expected behavior and add
> >>>>> tests to verify it.
> >>>>>>>
> >>>>>>> I think those users should update
> >>>>> `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but
> >>>>> obsolete) version of TLS they use.
> >>>>>>> After one should migrate to the reliable TLS version.
> >>>>>>> This reflected in the KIP:
> >>>>>>>
> >>>>>>> ```
> >>>>>>> Migration: Users who are using TLSv1.1 and TLSv1 should enable
> these
> >>>>> versions of the protocol with the explicit configuration property
> >>>>> "ssl.enabled.protocols"
> >>>>>>> ```
> >>>>>>>
> >>>>>>>> 25 февр. 2020 г., в 08:57, Nikolay Izhikov <
> nizhikov.dev@gmail.com
> >>>>
> >>>>> написал(а):
> >>>>>>>>
> >>>>>>>> Hello.
> >>>>>>>>
> >>>>>>>> Any feedback on this?
> >>>>>>>>
> >>>>>>>> This change seems very simple, I can start vote right now if
> >>> nothing
> >>>>> to discuss here.
> >>>>>>>>
> >>>>>>>>> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <
> >>> nizhikov.dev@gmail.com>
> >>>>> написал(а):
> >>>>>>>>>
> >>>>>>>>> Hello,
> >>>>>>>>>
> >>>>>>>>> I'd like to start a discussion of KIP [1]
> >>>>>>>>> This is follow-up for the KIP-553 [2]
> >>>>>>>>>
> >>>>>>>>> Its goal is to enable TLSv1.3 by default.
> >>>>>>>>>
> >>>>>>>>> Your comments and suggestions are welcome.
> >>>>>>>>>
> >>>>>>>>> [1]
> >>>>>
> >>>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
> >>>>>>>>> [2]
> >>>>>
> >>>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >
>
>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Nikolay Izhikov <ni...@apache.org>.
PR - https://github.com/apache/kafka/pull/8695
> 18 мая 2020 г., в 23:30, Nikolay Izhikov <ni...@gmail.com> написал(а):
>
> Hello, Colin
>
> We need hack only because TLSv1.3 not supported in java8.
>
>> Java 8 will receive TLS 1.3 support later this year (https://java.com/en/jre-jdk-cryptoroadmap.html)
>
> We can
>
> 1. Enable TLSv1.3 for java11 for now. And after java8 get TLSv1.3 support remove it.
> 2. Or we can wait and enable it after java8 update.
>
> What do you think?
>
>> 18 мая 2020 г., в 22:51, Ismael Juma <is...@juma.me.uk> написал(а):
>>
>> Yeah, agreed. One option is to actually only change this in Apache Kafka
>> 3.0 and avoid the hack altogether. We could make TLS 1.3 the default and
>> have 1.2 as one of the enabled protocols.
>>
>> Ismael
>>
>> On Mon, May 18, 2020 at 12:24 PM Colin McCabe <cm...@apache.org> wrote:
>>
>>> Hmm. It would be good to figure out if we are going to remove this
>>> compatibility hack in the next major release of Kafka? In other words, in
>>> Kafka 3.0, will we enable TLS 1.3 by default even if the cipher suite is
>>> specified?
>>>
>>> best,
>>> Colin
>>>
>>>
>>> On Mon, May 18, 2020, at 09:26, Ismael Juma wrote:
>>>> Sounds good.
>>>>
>>>> Ismael
>>>>
>>>>
>>>> On Mon, May 18, 2020, 9:03 AM Nikolay Izhikov <ni...@apache.org>
>>> wrote:
>>>>
>>>>>> A safer approach may be to only add TLS 1.3 to the list if the cipher
>>>>> suite config has not been specified.
>>>>>> So, if TLS 1.3 is added to the list by Kafka, it would seem that it
>>>>> would not work if the user specified a list of cipher suites for
>>> previous
>>>>> TLS versions
>>>>>
>>>>> Let’s just add test for this case?
>>>>> I can prepare the preliminary PR for this KIP and add this kind of
>>> test to
>>>>> it.
>>>>>
>>>>> What do you think?
>>>>>
>>>>>
>>>>>> 18 мая 2020 г., в 18:59, Nikolay Izhikov <NI...@gmail.com>
>>>>> написал(а):
>>>>>>
>>>>>>> 1. I meant that `ssl.protocol` is TLSv1.2 while
>>> `ssl.enabled.protocols`
>>>>> is `TLSv1.2, TLSv1.3`. How do these two configs interact
>>>>>>
>>>>>> `ssl.protocol` is what will be used, by default, in this KIP is stays
>>>>> unchanged (TLSv1.2) Please, see [1]
>>>>>> `ssl.enabled.protocols` is list of protocols that *can* be used.
>>> This
>>>>> value is just passed to the `SSLEngine` implementation.
>>>>>> Please, see DefaultSslEngineFactory#createSslEngine [2]
>>>>>>
>>>>>>> 2. My question is not about obsolete protocols, it is about people
>>>>> using TLS 1.2 with specified cipher suites. How will that behave when
>>> TLS
>>>>> 1.3 is enabled by default?
>>>>>>
>>>>>> They don’t change anything and all just work as expected on java11.
>>>>>>
>>>>>>> 3. An additional question is how does this impact Java 8 users?
>>>>>>
>>>>>> Yes.
>>>>>> If SSLEngine doesn’t support TLSv1.3 then java8 users should
>>> explicitly
>>>>> modify `ssl.enabled.protocols` and set it to `TLSv1.2`.
>>>>>>
>>>>>> [1]
>>>>>
>>> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L218
>>>>>> [2]
>>>>>
>>> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L164
>>>>>>
>>>>>>> 18 мая 2020 г., в 17:34, Ismael Juma <is...@juma.me.uk>
>>> написал(а):
>>>>>>>
>>>>>>> Nikolay,
>>>>>>>
>>>>>>> Thanks for the comments. More below:
>>>>>>>
>>>>>>> 1. I meant that `ssl.protocol` is TLSv1.2 while
>>> `ssl.enabled.protocols`
>>>>> is `TLSv1.2, TLSv1.3`. How do these two configs interact?
>>>>>>> 2. My question is not about obsolete protocols, it is about people
>>>>> using TLS 1.2 with specified cipher suites. How will that behave when
>>> TLS
>>>>> 1.3 is enabled by default?
>>>>>>> 3. An additional question is how does this impact Java 8 users?
>>> Java 8
>>>>> will receive TLS 1.3 support later this year (
>>>>> https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently does
>>>>> not support it. One way to handle this would be to check if the
>>> underlying
>>>>> JVM supports TLS 1.3 before enabling it.
>>>>>>>
>>>>>>> I hope this clarifies my questions.
>>>>>>>
>>>>>>> Ismael
>>>>>>>
>>>>>>> On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <
>>> nizhikov@apache.org>
>>>>> wrote:
>>>>>>> Hello, Ismael.
>>>>>>>
>>>>>>> Here is answers to your questions:
>>>>>>>
>>>>>>>> Quick question, the following is meant to include TLSv1.3 as well,
>>>>> right?
>>>>>>>> Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to
>>>>> «TLSv1.2»
>>>>>>>
>>>>>>> I propose to have the following value
>>>>> SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
>>>>>>>
>>>>>>>> 1. `ssl.protocol` would remain TLSv1.2 with this change. It would
>>> be
>>>>> good to explain why that's OK.
>>>>>>>
>>>>>>> I think it covered by the following statements in KIP.
>>>>>>> If you know more trustworthy sources of this kind of information,
>>>>> please, let me know.
>>>>>>>
>>>>>>> ```
>>>>>>> For now, only TLS1.2 and TLS1.3 are recommended for the usage, other
>>>>> versions of TLS considered as obsolete:
>>>>>>> • https://www.rfc-editor.org/info/rfc8446
>>>>>>> •
>>>>>
>>> https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
>>>>>>>
>>>>>>> ```
>>>>>>>
>>>>>>>> 2. What is the behavior for people who have configured
>>>>> `ssl.cipher.suites`?
>>>>>>>> The cipher suite names are different in TLS 1.3. What would be the
>>>>> behavior
>>>>>>>> if the client requests TLS 1.3, but the server only has cipher
>>> suites
>>>>> for
>>>>>>>> TLS 1.2? It would be good to explain the expected behavior and add
>>>>> tests to verify it.
>>>>>>>
>>>>>>> I think those users should update
>>>>> `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but
>>>>> obsolete) version of TLS they use.
>>>>>>> After one should migrate to the reliable TLS version.
>>>>>>> This reflected in the KIP:
>>>>>>>
>>>>>>> ```
>>>>>>> Migration: Users who are using TLSv1.1 and TLSv1 should enable these
>>>>> versions of the protocol with the explicit configuration property
>>>>> "ssl.enabled.protocols"
>>>>>>> ```
>>>>>>>
>>>>>>>> 25 февр. 2020 г., в 08:57, Nikolay Izhikov <nizhikov.dev@gmail.com
>>>>
>>>>> написал(а):
>>>>>>>>
>>>>>>>> Hello.
>>>>>>>>
>>>>>>>> Any feedback on this?
>>>>>>>>
>>>>>>>> This change seems very simple, I can start vote right now if
>>> nothing
>>>>> to discuss here.
>>>>>>>>
>>>>>>>>> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <
>>> nizhikov.dev@gmail.com>
>>>>> написал(а):
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I'd like to start a discussion of KIP [1]
>>>>>>>>> This is follow-up for the KIP-553 [2]
>>>>>>>>>
>>>>>>>>> Its goal is to enable TLSv1.3 by default.
>>>>>>>>>
>>>>>>>>> Your comments and suggestions are welcome.
>>>>>>>>>
>>>>>>>>> [1]
>>>>>
>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
>>>>>>>>> [2]
>>>>>
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Colin
We need hack only because TLSv1.3 not supported in java8.
> Java 8 will receive TLS 1.3 support later this year (https://java.com/en/jre-jdk-cryptoroadmap.html)
We can
1. Enable TLSv1.3 for java11 for now. And after java8 get TLSv1.3 support remove it.
2. Or we can wait and enable it after java8 update.
What do you think?
> 18 мая 2020 г., в 22:51, Ismael Juma <is...@juma.me.uk> написал(а):
>
> Yeah, agreed. One option is to actually only change this in Apache Kafka
> 3.0 and avoid the hack altogether. We could make TLS 1.3 the default and
> have 1.2 as one of the enabled protocols.
>
> Ismael
>
> On Mon, May 18, 2020 at 12:24 PM Colin McCabe <cm...@apache.org> wrote:
>
>> Hmm. It would be good to figure out if we are going to remove this
>> compatibility hack in the next major release of Kafka? In other words, in
>> Kafka 3.0, will we enable TLS 1.3 by default even if the cipher suite is
>> specified?
>>
>> best,
>> Colin
>>
>>
>> On Mon, May 18, 2020, at 09:26, Ismael Juma wrote:
>>> Sounds good.
>>>
>>> Ismael
>>>
>>>
>>> On Mon, May 18, 2020, 9:03 AM Nikolay Izhikov <ni...@apache.org>
>> wrote:
>>>
>>>>> A safer approach may be to only add TLS 1.3 to the list if the cipher
>>>> suite config has not been specified.
>>>>> So, if TLS 1.3 is added to the list by Kafka, it would seem that it
>>>> would not work if the user specified a list of cipher suites for
>> previous
>>>> TLS versions
>>>>
>>>> Let’s just add test for this case?
>>>> I can prepare the preliminary PR for this KIP and add this kind of
>> test to
>>>> it.
>>>>
>>>> What do you think?
>>>>
>>>>
>>>>> 18 мая 2020 г., в 18:59, Nikolay Izhikov <NI...@gmail.com>
>>>> написал(а):
>>>>>
>>>>>> 1. I meant that `ssl.protocol` is TLSv1.2 while
>> `ssl.enabled.protocols`
>>>> is `TLSv1.2, TLSv1.3`. How do these two configs interact
>>>>>
>>>>> `ssl.protocol` is what will be used, by default, in this KIP is stays
>>>> unchanged (TLSv1.2) Please, see [1]
>>>>> `ssl.enabled.protocols` is list of protocols that *can* be used.
>> This
>>>> value is just passed to the `SSLEngine` implementation.
>>>>> Please, see DefaultSslEngineFactory#createSslEngine [2]
>>>>>
>>>>>> 2. My question is not about obsolete protocols, it is about people
>>>> using TLS 1.2 with specified cipher suites. How will that behave when
>> TLS
>>>> 1.3 is enabled by default?
>>>>>
>>>>> They don’t change anything and all just work as expected on java11.
>>>>>
>>>>>> 3. An additional question is how does this impact Java 8 users?
>>>>>
>>>>> Yes.
>>>>> If SSLEngine doesn’t support TLSv1.3 then java8 users should
>> explicitly
>>>> modify `ssl.enabled.protocols` and set it to `TLSv1.2`.
>>>>>
>>>>> [1]
>>>>
>> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L218
>>>>> [2]
>>>>
>> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L164
>>>>>
>>>>>> 18 мая 2020 г., в 17:34, Ismael Juma <is...@juma.me.uk>
>> написал(а):
>>>>>>
>>>>>> Nikolay,
>>>>>>
>>>>>> Thanks for the comments. More below:
>>>>>>
>>>>>> 1. I meant that `ssl.protocol` is TLSv1.2 while
>> `ssl.enabled.protocols`
>>>> is `TLSv1.2, TLSv1.3`. How do these two configs interact?
>>>>>> 2. My question is not about obsolete protocols, it is about people
>>>> using TLS 1.2 with specified cipher suites. How will that behave when
>> TLS
>>>> 1.3 is enabled by default?
>>>>>> 3. An additional question is how does this impact Java 8 users?
>> Java 8
>>>> will receive TLS 1.3 support later this year (
>>>> https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently does
>>>> not support it. One way to handle this would be to check if the
>> underlying
>>>> JVM supports TLS 1.3 before enabling it.
>>>>>>
>>>>>> I hope this clarifies my questions.
>>>>>>
>>>>>> Ismael
>>>>>>
>>>>>> On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <
>> nizhikov@apache.org>
>>>> wrote:
>>>>>> Hello, Ismael.
>>>>>>
>>>>>> Here is answers to your questions:
>>>>>>
>>>>>>> Quick question, the following is meant to include TLSv1.3 as well,
>>>> right?
>>>>>>> Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to
>>>> «TLSv1.2»
>>>>>>
>>>>>> I propose to have the following value
>>>> SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
>>>>>>
>>>>>>> 1. `ssl.protocol` would remain TLSv1.2 with this change. It would
>> be
>>>> good to explain why that's OK.
>>>>>>
>>>>>> I think it covered by the following statements in KIP.
>>>>>> If you know more trustworthy sources of this kind of information,
>>>> please, let me know.
>>>>>>
>>>>>> ```
>>>>>> For now, only TLS1.2 and TLS1.3 are recommended for the usage, other
>>>> versions of TLS considered as obsolete:
>>>>>> • https://www.rfc-editor.org/info/rfc8446
>>>>>> •
>>>>
>> https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
>>>>>>
>>>>>> ```
>>>>>>
>>>>>>> 2. What is the behavior for people who have configured
>>>> `ssl.cipher.suites`?
>>>>>>> The cipher suite names are different in TLS 1.3. What would be the
>>>> behavior
>>>>>>> if the client requests TLS 1.3, but the server only has cipher
>> suites
>>>> for
>>>>>>> TLS 1.2? It would be good to explain the expected behavior and add
>>>> tests to verify it.
>>>>>>
>>>>>> I think those users should update
>>>> `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but
>>>> obsolete) version of TLS they use.
>>>>>> After one should migrate to the reliable TLS version.
>>>>>> This reflected in the KIP:
>>>>>>
>>>>>> ```
>>>>>> Migration: Users who are using TLSv1.1 and TLSv1 should enable these
>>>> versions of the protocol with the explicit configuration property
>>>> "ssl.enabled.protocols"
>>>>>> ```
>>>>>>
>>>>>>> 25 февр. 2020 г., в 08:57, Nikolay Izhikov <nizhikov.dev@gmail.com
>>>
>>>> написал(а):
>>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> Any feedback on this?
>>>>>>>
>>>>>>> This change seems very simple, I can start vote right now if
>> nothing
>>>> to discuss here.
>>>>>>>
>>>>>>>> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <
>> nizhikov.dev@gmail.com>
>>>> написал(а):
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I'd like to start a discussion of KIP [1]
>>>>>>>> This is follow-up for the KIP-553 [2]
>>>>>>>>
>>>>>>>> Its goal is to enable TLSv1.3 by default.
>>>>>>>>
>>>>>>>> Your comments and suggestions are welcome.
>>>>>>>>
>>>>>>>> [1]
>>>>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
>>>>>>>> [2]
>>>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Ismael Juma <is...@juma.me.uk>.
Yeah, agreed. One option is to actually only change this in Apache Kafka
3.0 and avoid the hack altogether. We could make TLS 1.3 the default and
have 1.2 as one of the enabled protocols.
Ismael
On Mon, May 18, 2020 at 12:24 PM Colin McCabe <cm...@apache.org> wrote:
> Hmm. It would be good to figure out if we are going to remove this
> compatibility hack in the next major release of Kafka? In other words, in
> Kafka 3.0, will we enable TLS 1.3 by default even if the cipher suite is
> specified?
>
> best,
> Colin
>
>
> On Mon, May 18, 2020, at 09:26, Ismael Juma wrote:
> > Sounds good.
> >
> > Ismael
> >
> >
> > On Mon, May 18, 2020, 9:03 AM Nikolay Izhikov <ni...@apache.org>
> wrote:
> >
> > > > A safer approach may be to only add TLS 1.3 to the list if the cipher
> > > suite config has not been specified.
> > > > So, if TLS 1.3 is added to the list by Kafka, it would seem that it
> > > would not work if the user specified a list of cipher suites for
> previous
> > > TLS versions
> > >
> > > Let’s just add test for this case?
> > > I can prepare the preliminary PR for this KIP and add this kind of
> test to
> > > it.
> > >
> > > What do you think?
> > >
> > >
> > > > 18 мая 2020 г., в 18:59, Nikolay Izhikov <NI...@gmail.com>
> > > написал(а):
> > > >
> > > >> 1. I meant that `ssl.protocol` is TLSv1.2 while
> `ssl.enabled.protocols`
> > > is `TLSv1.2, TLSv1.3`. How do these two configs interact
> > > >
> > > > `ssl.protocol` is what will be used, by default, in this KIP is stays
> > > unchanged (TLSv1.2) Please, see [1]
> > > > `ssl.enabled.protocols` is list of protocols that *can* be used.
> This
> > > value is just passed to the `SSLEngine` implementation.
> > > > Please, see DefaultSslEngineFactory#createSslEngine [2]
> > > >
> > > >> 2. My question is not about obsolete protocols, it is about people
> > > using TLS 1.2 with specified cipher suites. How will that behave when
> TLS
> > > 1.3 is enabled by default?
> > > >
> > > > They don’t change anything and all just work as expected on java11.
> > > >
> > > >> 3. An additional question is how does this impact Java 8 users?
> > > >
> > > > Yes.
> > > > If SSLEngine doesn’t support TLSv1.3 then java8 users should
> explicitly
> > > modify `ssl.enabled.protocols` and set it to `TLSv1.2`.
> > > >
> > > > [1]
> > >
> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L218
> > > > [2]
> > >
> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L164
> > > >
> > > >> 18 мая 2020 г., в 17:34, Ismael Juma <is...@juma.me.uk>
> написал(а):
> > > >>
> > > >> Nikolay,
> > > >>
> > > >> Thanks for the comments. More below:
> > > >>
> > > >> 1. I meant that `ssl.protocol` is TLSv1.2 while
> `ssl.enabled.protocols`
> > > is `TLSv1.2, TLSv1.3`. How do these two configs interact?
> > > >> 2. My question is not about obsolete protocols, it is about people
> > > using TLS 1.2 with specified cipher suites. How will that behave when
> TLS
> > > 1.3 is enabled by default?
> > > >> 3. An additional question is how does this impact Java 8 users?
> Java 8
> > > will receive TLS 1.3 support later this year (
> > > https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently does
> > > not support it. One way to handle this would be to check if the
> underlying
> > > JVM supports TLS 1.3 before enabling it.
> > > >>
> > > >> I hope this clarifies my questions.
> > > >>
> > > >> Ismael
> > > >>
> > > >> On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <
> nizhikov@apache.org>
> > > wrote:
> > > >> Hello, Ismael.
> > > >>
> > > >> Here is answers to your questions:
> > > >>
> > > >>> Quick question, the following is meant to include TLSv1.3 as well,
> > > right?
> > > >>> Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to
> > > «TLSv1.2»
> > > >>
> > > >> I propose to have the following value
> > > SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
> > > >>
> > > >>> 1. `ssl.protocol` would remain TLSv1.2 with this change. It would
> be
> > > good to explain why that's OK.
> > > >>
> > > >> I think it covered by the following statements in KIP.
> > > >> If you know more trustworthy sources of this kind of information,
> > > please, let me know.
> > > >>
> > > >> ```
> > > >> For now, only TLS1.2 and TLS1.3 are recommended for the usage, other
> > > versions of TLS considered as obsolete:
> > > >> • https://www.rfc-editor.org/info/rfc8446
> > > >> •
> > >
> https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
> > > >>
> > > >> ```
> > > >>
> > > >>> 2. What is the behavior for people who have configured
> > > `ssl.cipher.suites`?
> > > >>> The cipher suite names are different in TLS 1.3. What would be the
> > > behavior
> > > >>> if the client requests TLS 1.3, but the server only has cipher
> suites
> > > for
> > > >>> TLS 1.2? It would be good to explain the expected behavior and add
> > > tests to verify it.
> > > >>
> > > >> I think those users should update
> > > `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but
> > > obsolete) version of TLS they use.
> > > >> After one should migrate to the reliable TLS version.
> > > >> This reflected in the KIP:
> > > >>
> > > >> ```
> > > >> Migration: Users who are using TLSv1.1 and TLSv1 should enable these
> > > versions of the protocol with the explicit configuration property
> > > "ssl.enabled.protocols"
> > > >> ```
> > > >>
> > > >>> 25 февр. 2020 г., в 08:57, Nikolay Izhikov <nizhikov.dev@gmail.com
> >
> > > написал(а):
> > > >>>
> > > >>> Hello.
> > > >>>
> > > >>> Any feedback on this?
> > > >>>
> > > >>> This change seems very simple, I can start vote right now if
> nothing
> > > to discuss here.
> > > >>>
> > > >>>> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <
> nizhikov.dev@gmail.com>
> > > написал(а):
> > > >>>>
> > > >>>> Hello,
> > > >>>>
> > > >>>> I'd like to start a discussion of KIP [1]
> > > >>>> This is follow-up for the KIP-553 [2]
> > > >>>>
> > > >>>> Its goal is to enable TLSv1.3 by default.
> > > >>>>
> > > >>>> Your comments and suggestions are welcome.
> > > >>>>
> > > >>>> [1]
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
> > > >>>> [2]
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
> > > >>>
> > > >>
> > > >
> > >
> > >
> >
>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Colin McCabe <cm...@apache.org>.
Hmm. It would be good to figure out if we are going to remove this compatibility hack in the next major release of Kafka? In other words, in Kafka 3.0, will we enable TLS 1.3 by default even if the cipher suite is specified?
best,
Colin
On Mon, May 18, 2020, at 09:26, Ismael Juma wrote:
> Sounds good.
>
> Ismael
>
>
> On Mon, May 18, 2020, 9:03 AM Nikolay Izhikov <ni...@apache.org> wrote:
>
> > > A safer approach may be to only add TLS 1.3 to the list if the cipher
> > suite config has not been specified.
> > > So, if TLS 1.3 is added to the list by Kafka, it would seem that it
> > would not work if the user specified a list of cipher suites for previous
> > TLS versions
> >
> > Let’s just add test for this case?
> > I can prepare the preliminary PR for this KIP and add this kind of test to
> > it.
> >
> > What do you think?
> >
> >
> > > 18 мая 2020 г., в 18:59, Nikolay Izhikov <NI...@gmail.com>
> > написал(а):
> > >
> > >> 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols`
> > is `TLSv1.2, TLSv1.3`. How do these two configs interact
> > >
> > > `ssl.protocol` is what will be used, by default, in this KIP is stays
> > unchanged (TLSv1.2) Please, see [1]
> > > `ssl.enabled.protocols` is list of protocols that *can* be used. This
> > value is just passed to the `SSLEngine` implementation.
> > > Please, see DefaultSslEngineFactory#createSslEngine [2]
> > >
> > >> 2. My question is not about obsolete protocols, it is about people
> > using TLS 1.2 with specified cipher suites. How will that behave when TLS
> > 1.3 is enabled by default?
> > >
> > > They don’t change anything and all just work as expected on java11.
> > >
> > >> 3. An additional question is how does this impact Java 8 users?
> > >
> > > Yes.
> > > If SSLEngine doesn’t support TLSv1.3 then java8 users should explicitly
> > modify `ssl.enabled.protocols` and set it to `TLSv1.2`.
> > >
> > > [1]
> > https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L218
> > > [2]
> > https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L164
> > >
> > >> 18 мая 2020 г., в 17:34, Ismael Juma <is...@juma.me.uk> написал(а):
> > >>
> > >> Nikolay,
> > >>
> > >> Thanks for the comments. More below:
> > >>
> > >> 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols`
> > is `TLSv1.2, TLSv1.3`. How do these two configs interact?
> > >> 2. My question is not about obsolete protocols, it is about people
> > using TLS 1.2 with specified cipher suites. How will that behave when TLS
> > 1.3 is enabled by default?
> > >> 3. An additional question is how does this impact Java 8 users? Java 8
> > will receive TLS 1.3 support later this year (
> > https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently does
> > not support it. One way to handle this would be to check if the underlying
> > JVM supports TLS 1.3 before enabling it.
> > >>
> > >> I hope this clarifies my questions.
> > >>
> > >> Ismael
> > >>
> > >> On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <ni...@apache.org>
> > wrote:
> > >> Hello, Ismael.
> > >>
> > >> Here is answers to your questions:
> > >>
> > >>> Quick question, the following is meant to include TLSv1.3 as well,
> > right?
> > >>> Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to
> > «TLSv1.2»
> > >>
> > >> I propose to have the following value
> > SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
> > >>
> > >>> 1. `ssl.protocol` would remain TLSv1.2 with this change. It would be
> > good to explain why that's OK.
> > >>
> > >> I think it covered by the following statements in KIP.
> > >> If you know more trustworthy sources of this kind of information,
> > please, let me know.
> > >>
> > >> ```
> > >> For now, only TLS1.2 and TLS1.3 are recommended for the usage, other
> > versions of TLS considered as obsolete:
> > >> • https://www.rfc-editor.org/info/rfc8446
> > >> •
> > https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
> > >>
> > >> ```
> > >>
> > >>> 2. What is the behavior for people who have configured
> > `ssl.cipher.suites`?
> > >>> The cipher suite names are different in TLS 1.3. What would be the
> > behavior
> > >>> if the client requests TLS 1.3, but the server only has cipher suites
> > for
> > >>> TLS 1.2? It would be good to explain the expected behavior and add
> > tests to verify it.
> > >>
> > >> I think those users should update
> > `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but
> > obsolete) version of TLS they use.
> > >> After one should migrate to the reliable TLS version.
> > >> This reflected in the KIP:
> > >>
> > >> ```
> > >> Migration: Users who are using TLSv1.1 and TLSv1 should enable these
> > versions of the protocol with the explicit configuration property
> > "ssl.enabled.protocols"
> > >> ```
> > >>
> > >>> 25 февр. 2020 г., в 08:57, Nikolay Izhikov <ni...@gmail.com>
> > написал(а):
> > >>>
> > >>> Hello.
> > >>>
> > >>> Any feedback on this?
> > >>>
> > >>> This change seems very simple, I can start vote right now if nothing
> > to discuss here.
> > >>>
> > >>>> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <ni...@gmail.com>
> > написал(а):
> > >>>>
> > >>>> Hello,
> > >>>>
> > >>>> I'd like to start a discussion of KIP [1]
> > >>>> This is follow-up for the KIP-553 [2]
> > >>>>
> > >>>> Its goal is to enable TLSv1.3 by default.
> > >>>>
> > >>>> Your comments and suggestions are welcome.
> > >>>>
> > >>>> [1]
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
> > >>>> [2]
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
> > >>>
> > >>
> > >
> >
> >
>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Ismael Juma <is...@juma.me.uk>.
Sounds good.
Ismael
On Mon, May 18, 2020, 9:03 AM Nikolay Izhikov <ni...@apache.org> wrote:
> > A safer approach may be to only add TLS 1.3 to the list if the cipher
> suite config has not been specified.
> > So, if TLS 1.3 is added to the list by Kafka, it would seem that it
> would not work if the user specified a list of cipher suites for previous
> TLS versions
>
> Let’s just add test for this case?
> I can prepare the preliminary PR for this KIP and add this kind of test to
> it.
>
> What do you think?
>
>
> > 18 мая 2020 г., в 18:59, Nikolay Izhikov <NI...@gmail.com>
> написал(а):
> >
> >> 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols`
> is `TLSv1.2, TLSv1.3`. How do these two configs interact
> >
> > `ssl.protocol` is what will be used, by default, in this KIP is stays
> unchanged (TLSv1.2) Please, see [1]
> > `ssl.enabled.protocols` is list of protocols that *can* be used. This
> value is just passed to the `SSLEngine` implementation.
> > Please, see DefaultSslEngineFactory#createSslEngine [2]
> >
> >> 2. My question is not about obsolete protocols, it is about people
> using TLS 1.2 with specified cipher suites. How will that behave when TLS
> 1.3 is enabled by default?
> >
> > They don’t change anything and all just work as expected on java11.
> >
> >> 3. An additional question is how does this impact Java 8 users?
> >
> > Yes.
> > If SSLEngine doesn’t support TLSv1.3 then java8 users should explicitly
> modify `ssl.enabled.protocols` and set it to `TLSv1.2`.
> >
> > [1]
> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L218
> > [2]
> https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L164
> >
> >> 18 мая 2020 г., в 17:34, Ismael Juma <is...@juma.me.uk> написал(а):
> >>
> >> Nikolay,
> >>
> >> Thanks for the comments. More below:
> >>
> >> 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols`
> is `TLSv1.2, TLSv1.3`. How do these two configs interact?
> >> 2. My question is not about obsolete protocols, it is about people
> using TLS 1.2 with specified cipher suites. How will that behave when TLS
> 1.3 is enabled by default?
> >> 3. An additional question is how does this impact Java 8 users? Java 8
> will receive TLS 1.3 support later this year (
> https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently does
> not support it. One way to handle this would be to check if the underlying
> JVM supports TLS 1.3 before enabling it.
> >>
> >> I hope this clarifies my questions.
> >>
> >> Ismael
> >>
> >> On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <ni...@apache.org>
> wrote:
> >> Hello, Ismael.
> >>
> >> Here is answers to your questions:
> >>
> >>> Quick question, the following is meant to include TLSv1.3 as well,
> right?
> >>> Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to
> «TLSv1.2»
> >>
> >> I propose to have the following value
> SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
> >>
> >>> 1. `ssl.protocol` would remain TLSv1.2 with this change. It would be
> good to explain why that's OK.
> >>
> >> I think it covered by the following statements in KIP.
> >> If you know more trustworthy sources of this kind of information,
> please, let me know.
> >>
> >> ```
> >> For now, only TLS1.2 and TLS1.3 are recommended for the usage, other
> versions of TLS considered as obsolete:
> >> • https://www.rfc-editor.org/info/rfc8446
> >> •
> https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
> >>
> >> ```
> >>
> >>> 2. What is the behavior for people who have configured
> `ssl.cipher.suites`?
> >>> The cipher suite names are different in TLS 1.3. What would be the
> behavior
> >>> if the client requests TLS 1.3, but the server only has cipher suites
> for
> >>> TLS 1.2? It would be good to explain the expected behavior and add
> tests to verify it.
> >>
> >> I think those users should update
> `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but
> obsolete) version of TLS they use.
> >> After one should migrate to the reliable TLS version.
> >> This reflected in the KIP:
> >>
> >> ```
> >> Migration: Users who are using TLSv1.1 and TLSv1 should enable these
> versions of the protocol with the explicit configuration property
> "ssl.enabled.protocols"
> >> ```
> >>
> >>> 25 февр. 2020 г., в 08:57, Nikolay Izhikov <ni...@gmail.com>
> написал(а):
> >>>
> >>> Hello.
> >>>
> >>> Any feedback on this?
> >>>
> >>> This change seems very simple, I can start vote right now if nothing
> to discuss here.
> >>>
> >>>> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <ni...@gmail.com>
> написал(а):
> >>>>
> >>>> Hello,
> >>>>
> >>>> I'd like to start a discussion of KIP [1]
> >>>> This is follow-up for the KIP-553 [2]
> >>>>
> >>>> Its goal is to enable TLSv1.3 by default.
> >>>>
> >>>> Your comments and suggestions are welcome.
> >>>>
> >>>> [1]
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
> >>>> [2]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
> >>>
> >>
> >
>
>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Nikolay Izhikov <ni...@apache.org>.
> A safer approach may be to only add TLS 1.3 to the list if the cipher suite config has not been specified.
> So, if TLS 1.3 is added to the list by Kafka, it would seem that it would not work if the user specified a list of cipher suites for previous TLS versions
Let’s just add test for this case?
I can prepare the preliminary PR for this KIP and add this kind of test to it.
What do you think?
> 18 мая 2020 г., в 18:59, Nikolay Izhikov <NI...@gmail.com> написал(а):
>
>> 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols` is `TLSv1.2, TLSv1.3`. How do these two configs interact
>
> `ssl.protocol` is what will be used, by default, in this KIP is stays unchanged (TLSv1.2) Please, see [1]
> `ssl.enabled.protocols` is list of protocols that *can* be used. This value is just passed to the `SSLEngine` implementation.
> Please, see DefaultSslEngineFactory#createSslEngine [2]
>
>> 2. My question is not about obsolete protocols, it is about people using TLS 1.2 with specified cipher suites. How will that behave when TLS 1.3 is enabled by default?
>
> They don’t change anything and all just work as expected on java11.
>
>> 3. An additional question is how does this impact Java 8 users?
>
> Yes.
> If SSLEngine doesn’t support TLSv1.3 then java8 users should explicitly modify `ssl.enabled.protocols` and set it to `TLSv1.2`.
>
> [1] https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L218
> [2] https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L164
>
>> 18 мая 2020 г., в 17:34, Ismael Juma <is...@juma.me.uk> написал(а):
>>
>> Nikolay,
>>
>> Thanks for the comments. More below:
>>
>> 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols` is `TLSv1.2, TLSv1.3`. How do these two configs interact?
>> 2. My question is not about obsolete protocols, it is about people using TLS 1.2 with specified cipher suites. How will that behave when TLS 1.3 is enabled by default?
>> 3. An additional question is how does this impact Java 8 users? Java 8 will receive TLS 1.3 support later this year (https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently does not support it. One way to handle this would be to check if the underlying JVM supports TLS 1.3 before enabling it.
>>
>> I hope this clarifies my questions.
>>
>> Ismael
>>
>> On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <ni...@apache.org> wrote:
>> Hello, Ismael.
>>
>> Here is answers to your questions:
>>
>>> Quick question, the following is meant to include TLSv1.3 as well, right?
>>> Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to «TLSv1.2»
>>
>> I propose to have the following value SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
>>
>>> 1. `ssl.protocol` would remain TLSv1.2 with this change. It would be good to explain why that's OK.
>>
>> I think it covered by the following statements in KIP.
>> If you know more trustworthy sources of this kind of information, please, let me know.
>>
>> ```
>> For now, only TLS1.2 and TLS1.3 are recommended for the usage, other versions of TLS considered as obsolete:
>> • https://www.rfc-editor.org/info/rfc8446
>> • https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
>>
>> ```
>>
>>> 2. What is the behavior for people who have configured `ssl.cipher.suites`?
>>> The cipher suite names are different in TLS 1.3. What would be the behavior
>>> if the client requests TLS 1.3, but the server only has cipher suites for
>>> TLS 1.2? It would be good to explain the expected behavior and add tests to verify it.
>>
>> I think those users should update `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but obsolete) version of TLS they use.
>> After one should migrate to the reliable TLS version.
>> This reflected in the KIP:
>>
>> ```
>> Migration: Users who are using TLSv1.1 and TLSv1 should enable these versions of the protocol with the explicit configuration property "ssl.enabled.protocols"
>> ```
>>
>>> 25 февр. 2020 г., в 08:57, Nikolay Izhikov <ni...@gmail.com> написал(а):
>>>
>>> Hello.
>>>
>>> Any feedback on this?
>>>
>>> This change seems very simple, I can start vote right now if nothing to discuss here.
>>>
>>>> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <ni...@gmail.com> написал(а):
>>>>
>>>> Hello,
>>>>
>>>> I'd like to start a discussion of KIP [1]
>>>> This is follow-up for the KIP-553 [2]
>>>>
>>>> Its goal is to enable TLSv1.3 by default.
>>>>
>>>> Your comments and suggestions are welcome.
>>>>
>>>> [1] https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
>>>> [2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
>>>
>>
>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Nikolay Izhikov <ni...@apache.org>.
> 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols` is `TLSv1.2, TLSv1.3`. How do these two configs interact
`ssl.protocol` is what will be used, by default, in this KIP is stays unchanged (TLSv1.2) Please, see [1]
`ssl.enabled.protocols` is list of protocols that *can* be used. This value is just passed to the `SSLEngine` implementation.
Please, see DefaultSslEngineFactory#createSslEngine [2]
> 2. My question is not about obsolete protocols, it is about people using TLS 1.2 with specified cipher suites. How will that behave when TLS 1.3 is enabled by default?
They don’t change anything and all just work as expected on java11.
> 3. An additional question is how does this impact Java 8 users?
Yes.
If SSLEngine doesn’t support TLSv1.3 then java8 users should explicitly modify `ssl.enabled.protocols` and set it to `TLSv1.2`.
[1] https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L218
[2] https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L164
> 18 мая 2020 г., в 17:34, Ismael Juma <is...@juma.me.uk> написал(а):
>
> Nikolay,
>
> Thanks for the comments. More below:
>
> 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols` is `TLSv1.2, TLSv1.3`. How do these two configs interact?
> 2. My question is not about obsolete protocols, it is about people using TLS 1.2 with specified cipher suites. How will that behave when TLS 1.3 is enabled by default?
> 3. An additional question is how does this impact Java 8 users? Java 8 will receive TLS 1.3 support later this year (https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently does not support it. One way to handle this would be to check if the underlying JVM supports TLS 1.3 before enabling it.
>
> I hope this clarifies my questions.
>
> Ismael
>
> On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <ni...@apache.org> wrote:
> Hello, Ismael.
>
> Here is answers to your questions:
>
> > Quick question, the following is meant to include TLSv1.3 as well, right?
> > Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to «TLSv1.2»
>
> I propose to have the following value SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
>
> > 1. `ssl.protocol` would remain TLSv1.2 with this change. It would be good to explain why that's OK.
>
> I think it covered by the following statements in KIP.
> If you know more trustworthy sources of this kind of information, please, let me know.
>
> ```
> For now, only TLS1.2 and TLS1.3 are recommended for the usage, other versions of TLS considered as obsolete:
> • https://www.rfc-editor.org/info/rfc8446
> • https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
>
> ```
>
> > 2. What is the behavior for people who have configured `ssl.cipher.suites`?
> > The cipher suite names are different in TLS 1.3. What would be the behavior
> > if the client requests TLS 1.3, but the server only has cipher suites for
> > TLS 1.2? It would be good to explain the expected behavior and add tests to verify it.
>
> I think those users should update `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but obsolete) version of TLS they use.
> After one should migrate to the reliable TLS version.
> This reflected in the KIP:
>
> ```
> Migration: Users who are using TLSv1.1 and TLSv1 should enable these versions of the protocol with the explicit configuration property "ssl.enabled.protocols"
> ```
>
> > 25 февр. 2020 г., в 08:57, Nikolay Izhikov <ni...@gmail.com> написал(а):
> >
> > Hello.
> >
> > Any feedback on this?
> >
> > This change seems very simple, I can start vote right now if nothing to discuss here.
> >
> >> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <ni...@gmail.com> написал(а):
> >>
> >> Hello,
> >>
> >> I'd like to start a discussion of KIP [1]
> >> This is follow-up for the KIP-553 [2]
> >>
> >> Its goal is to enable TLSv1.3 by default.
> >>
> >> Your comments and suggestions are welcome.
> >>
> >> [1] https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
> >> [2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
> >
>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Ismael Juma <is...@juma.me.uk>.
To be more concrete, here are the ciphers supported by TLS 1.3:
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256
Compare with TLS 1.2:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES256-CCM:AES128-GCM-SHA256:AES128-CCM:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-CCM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-CCM:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA
So, if TLS 1.3 is added to the list by Kafka, it would seem that it would
not work if the user specified a list of cipher suites for previous TLS
versions. Will the client do the right thing and always negotiate TLS 1.2
in these cases? A safer approach may be to only add TLS 1.3 to the list if
the cipher suite config has not been specified.
Ismael
On Mon, May 18, 2020 at 7:34 AM Ismael Juma <is...@juma.me.uk> wrote:
> Nikolay,
>
> Thanks for the comments. More below:
>
> 1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols` is
> `TLSv1.2, TLSv1.3`. How do these two configs interact?
> 2. My question is not about obsolete protocols, it is about people using
> TLS 1.2 with specified cipher suites. How will that behave when TLS 1.3 is
> enabled by default?
> 3. An additional question is how does this impact Java 8 users? Java 8
> will receive TLS 1.3 support later this year (
> https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently does
> not support it. One way to handle this would be to check if the underlying
> JVM supports TLS 1.3 before enabling it.
>
> I hope this clarifies my questions.
>
> Ismael
>
> On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <ni...@apache.org>
> wrote:
>
>> Hello, Ismael.
>>
>> Here is answers to your questions:
>>
>> > Quick question, the following is meant to include TLSv1.3 as well,
>> right?
>> > Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to
>> «TLSv1.2»
>>
>> I propose to have the following value
>> SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
>>
>> > 1. `ssl.protocol` would remain TLSv1.2 with this change. It would be
>> good to explain why that's OK.
>>
>> I think it covered by the following statements in KIP.
>> If you know more trustworthy sources of this kind of information, please,
>> let me know.
>>
>> ```
>> For now, only TLS1.2 and TLS1.3 are recommended for the usage, other
>> versions of TLS considered as obsolete:
>> • https://www.rfc-editor.org/info/rfc8446
>> •
>> https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
>>
>> ```
>>
>> > 2. What is the behavior for people who have configured
>> `ssl.cipher.suites`?
>> > The cipher suite names are different in TLS 1.3. What would be the
>> behavior
>> > if the client requests TLS 1.3, but the server only has cipher suites
>> for
>> > TLS 1.2? It would be good to explain the expected behavior and add
>> tests to verify it.
>>
>> I think those users should update
>> `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but
>> obsolete) version of TLS they use.
>> After one should migrate to the reliable TLS version.
>> This reflected in the KIP:
>>
>> ```
>> Migration: Users who are using TLSv1.1 and TLSv1 should enable these
>> versions of the protocol with the explicit configuration property
>> "ssl.enabled.protocols"
>> ```
>>
>> > 25 февр. 2020 г., в 08:57, Nikolay Izhikov <ni...@gmail.com>
>> написал(а):
>> >
>> > Hello.
>> >
>> > Any feedback on this?
>> >
>> > This change seems very simple, I can start vote right now if nothing to
>> discuss here.
>> >
>> >> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <ni...@gmail.com>
>> написал(а):
>> >>
>> >> Hello,
>> >>
>> >> I'd like to start a discussion of KIP [1]
>> >> This is follow-up for the KIP-553 [2]
>> >>
>> >> Its goal is to enable TLSv1.3 by default.
>> >>
>> >> Your comments and suggestions are welcome.
>> >>
>> >> [1]
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
>> >> [2]
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
>> >
>>
>>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Ismael Juma <is...@juma.me.uk>.
Nikolay,
Thanks for the comments. More below:
1. I meant that `ssl.protocol` is TLSv1.2 while `ssl.enabled.protocols` is
`TLSv1.2, TLSv1.3`. How do these two configs interact?
2. My question is not about obsolete protocols, it is about people using
TLS 1.2 with specified cipher suites. How will that behave when TLS 1.3 is
enabled by default?
3. An additional question is how does this impact Java 8 users? Java 8 will
receive TLS 1.3 support later this year (
https://java.com/en/jre-jdk-cryptoroadmap.html), but it currently does not
support it. One way to handle this would be to check if the underlying JVM
supports TLS 1.3 before enabling it.
I hope this clarifies my questions.
Ismael
On Mon, May 18, 2020 at 6:44 AM Nikolay Izhikov <ni...@apache.org> wrote:
> Hello, Ismael.
>
> Here is answers to your questions:
>
> > Quick question, the following is meant to include TLSv1.3 as well, right?
> > Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to
> «TLSv1.2»
>
> I propose to have the following value
> SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
>
> > 1. `ssl.protocol` would remain TLSv1.2 with this change. It would be
> good to explain why that's OK.
>
> I think it covered by the following statements in KIP.
> If you know more trustworthy sources of this kind of information, please,
> let me know.
>
> ```
> For now, only TLS1.2 and TLS1.3 are recommended for the usage, other
> versions of TLS considered as obsolete:
> • https://www.rfc-editor.org/info/rfc8446
> •
> https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
>
> ```
>
> > 2. What is the behavior for people who have configured
> `ssl.cipher.suites`?
> > The cipher suite names are different in TLS 1.3. What would be the
> behavior
> > if the client requests TLS 1.3, but the server only has cipher suites for
> > TLS 1.2? It would be good to explain the expected behavior and add tests
> to verify it.
>
> I think those users should update
> `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but
> obsolete) version of TLS they use.
> After one should migrate to the reliable TLS version.
> This reflected in the KIP:
>
> ```
> Migration: Users who are using TLSv1.1 and TLSv1 should enable these
> versions of the protocol with the explicit configuration property
> "ssl.enabled.protocols"
> ```
>
> > 25 февр. 2020 г., в 08:57, Nikolay Izhikov <ni...@gmail.com>
> написал(а):
> >
> > Hello.
> >
> > Any feedback on this?
> >
> > This change seems very simple, I can start vote right now if nothing to
> discuss here.
> >
> >> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <ni...@gmail.com>
> написал(а):
> >>
> >> Hello,
> >>
> >> I'd like to start a discussion of KIP [1]
> >> This is follow-up for the KIP-553 [2]
> >>
> >> Its goal is to enable TLSv1.3 by default.
> >>
> >> Your comments and suggestions are welcome.
> >>
> >> [1]
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
> >> [2]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
> >
>
>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Ismael.
Here is answers to your questions:
> Quick question, the following is meant to include TLSv1.3 as well, right?
> Change the value of the SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS to «TLSv1.2»
I propose to have the following value SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS = «TLSv1.2,TLSv.1.3»
> 1. `ssl.protocol` would remain TLSv1.2 with this change. It would be good to explain why that's OK.
I think it covered by the following statements in KIP.
If you know more trustworthy sources of this kind of information, please, let me know.
```
For now, only TLS1.2 and TLS1.3 are recommended for the usage, other versions of TLS considered as obsolete:
• https://www.rfc-editor.org/info/rfc8446
• https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
```
> 2. What is the behavior for people who have configured `ssl.cipher.suites`?
> The cipher suite names are different in TLS 1.3. What would be the behavior
> if the client requests TLS 1.3, but the server only has cipher suites for
> TLS 1.2? It would be good to explain the expected behavior and add tests to verify it.
I think those users should update `SslConfigs.DEFAULT_SSL_ENABLED_PROTOCOLS` and enable required(but obsolete) version of TLS they use.
After one should migrate to the reliable TLS version.
This reflected in the KIP:
```
Migration: Users who are using TLSv1.1 and TLSv1 should enable these versions of the protocol with the explicit configuration property "ssl.enabled.protocols"
```
> 25 февр. 2020 г., в 08:57, Nikolay Izhikov <ni...@gmail.com> написал(а):
>
> Hello.
>
> Any feedback on this?
>
> This change seems very simple, I can start vote right now if nothing to discuss here.
>
>> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <ni...@gmail.com> написал(а):
>>
>> Hello,
>>
>> I'd like to start a discussion of KIP [1]
>> This is follow-up for the KIP-553 [2]
>>
>> Its goal is to enable TLSv1.3 by default.
>>
>> Your comments and suggestions are welcome.
>>
>> [1] https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
>> [2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956
>
Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello.
Any feedback on this?
This change seems very simple, I can start vote right now if nothing to discuss here.
> 21 февр. 2020 г., в 15:18, Nikolay Izhikov <ni...@gmail.com> написал(а):
>
> Hello,
>
> I'd like to start a discussion of KIP [1]
> This is follow-up for the KIP-553 [2]
>
> Its goal is to enable TLSv1.3 by default.
>
> Your comments and suggestions are welcome.
>
> [1] https://cwiki.apache.org/confluence/display/KAFKA/KIP-573%3A+Enable+TLSv1.3+by+default
> [2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=142641956