Thanks Jonathan. You have binding votes from me and Gwen. One more binding vote is required for this KIP to be approved.
On Thu, May 10, 2018 at 1:14 PM, Skrzypek, Jonathan < jonathan.skrzy...@gs.com> wrote: > Hi, > > Have implemented the changes discussed. > bootstrap.reverse.dns.lookup is disabled by default. > When enabled, the client will perform reverse dns lookup regardless of the > security protocol used. > > https://github.com/apache/kafka/pull/4485 > > > Jonathan Skrzypek > > > -----Original Message----- > From: Skrzypek, Jonathan [Tech] > Sent: 01 May 2018 17:17 > To: dev > Subject: RE: [VOTE] KIP-235 Add DNS alias support for secured connection > > Oops, yes indeed that makes sense, got confused between SASL_SSL and SSL. > > Updated the KIP. > > > > Jonathan Skrzypek > > > -----Original Message----- > From: Rajini Sivaram [mailto:rajinisiva...@gmail.com] > Sent: 01 May 2018 11:08 > To: dev > Subject: Re: [VOTE] KIP-235 Add DNS alias support for secured connection > > Jonathan, > > Not doing the reverse lookup for SASL_SSL limits the usability of this KIP > since it can no longer be used in a secure environment where Kerberos is > used with TLS. Perhaps the best option is to do the lookup if the option is > explicitly enabled regardless of what the security protocol is. If there is > a SSL handshake failure with this option enabled, the error message can be > updated to indicate that it could be because a reverse lookup was used. Can > you state in the KIP that the default value of > bootstrap.reverse.dns.lookup will > be false and hence there is no backwards compatibility issue. > > On Mon, Apr 30, 2018 at 1:41 PM, Skrzypek, Jonathan < > jonathan.skrzy...@gs.com> wrote: > > > Thanks for your comments. > > Have updated the KIP. > > > > I agree SSL and SASL_SSL will face similar issues and should behave the > > same. > > Thinking about this further, I'm wondering whether setting > > bootstrap.reverse.dns.lookup to true whilst using any of those protocols > > should throw a critical error and stop, or at least log a warning stating > > that the lookup won't be performed. > > This sounds better than silently ignoring and leave users with the > > impression they can use SSL and bootstrap server aliases. > > Abruptly stopping the client sounds a bit extreme so I'm leaning towards > a > > warning. > > > > Thoughts ? > > > > I'm not sure about checking whether the list has IP addresses. > > There could be cases where the list has a mix of FQDNs and IPs, so I > would > > rather perform the lookup regardless of the case when the parameter is > > enabled. > > > > On the security aspects, I am by no means a security or SASL expert so > > commented the KIP with what I believe to be the case. > > > > Jonathan Skrzypek > > > > -----Original Message----- > > From: Rajini Sivaram [mailto:rajinisiva...@gmail.com] > > Sent: 29 April 2018 15:38 > > To: dev > > Subject: Re: [VOTE] KIP-235 Add DNS alias support for secured connection > > > > Hi Jonathan, > > > > Thanks for the KIP. > > > > +1 (binding) with a couple comments below to add more detail to the KIP. > > > > 1. Make it clearer when the new option `bootstrap.reverse.dns.lookup` > > should or shouldn't be used. Document security considerations as well > as > > other system configurations that may have an impact. > > 2. The PR currently disables the new code path for security protocol > > SSL. But this doesn't address SASL_SSL which could also do hostname > > verification. Do we even want to do reverse lookup if bootstrap list > > contains IP addresses? If we do, we should handle SSL and SASL_SSL in > > the > > same way (which basically means handling all protocols in the same > way). > > > > > > On Thu, Apr 26, 2018 at 2:16 PM, Stephane Maarek < > > steph...@simplemachines.com.au> wrote: > > > > > +1 as a user > > > BUT > > > > > > I am no security expert. I have experienced that issue while setting > up a > > > cluster and while I would have liked a feature like that (I opened a > JIRA > > > at the time), I always guessed that the reason was because of some > > security > > > protection. > > > > > > Now from a setup point of view this helps a ton, but I really want to > > make > > > sure this doesn't introduce any security risk by relaxing a constraint. > > > > > > Is there a security assessment possible by someone accredited ? > > > > > > Sorry for raising these questions just want to make sure it's addressed > > > > > > On Thu., 26 Apr. 2018, 5:32 pm Gwen Shapira, <g...@confluent.io> > wrote: > > > > > > > +1 (binding) > > > > > > > > This KIP is quite vital to running secured clusters in > cloud/container > > > > environment. Would love to see more support from the community to > this > > > (or > > > > feedback...) > > > > > > > > Gwen > > > > > > > > On Mon, Apr 16, 2018 at 4:52 PM, Skrzypek, Jonathan < > > > > jonathan.skrzy...@gs.com> wrote: > > > > > > > > > Hi, > > > > > > > > > > Could anyone take a look ? > > > > > Does the proposal sound reasonable ? > > > > > > > > > > Jonathan Skrzypek > > > > > > > > > > > > > > > From: Skrzypek, Jonathan [Tech] > > > > > Sent: 23 March 2018 19:05 > > > > > To: dev@kafka.apache.org > > > > > Subject: [VOTE] KIP-235 Add DNS alias support for secured > connection > > > > > > > > > > Hi, > > > > > > > > > > I would like to start a vote for KIP-235 > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki. > > apache.org_confluence_display_KAFKA_KIP-2D&d=DwIBaQ&c= > > 7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZlX4&r=nNmJlu1rR_QFAPdxGlafmDu9_ > > r6eaCbPOM0NM1EHo-E&m=2JuW6J_xPCRzueIjC4B6j1v6T9aXMR5k9Nh8oMBVLd0&s= > > SJsuC6ROGH5VTVxQktBbB7xKK4zFDVRkQSUtZbLMfZ4&e= > > > > > 235%3A+Add+DNS+alias+support+for+secured+connection > > > > > > > > > > This is a proposition to add an option for reverse dns lookup of > > > > > bootstrap.servers hosts, allowing the use of dns aliases on > clusters > > > > using > > > > > SASL authentication. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > *Gwen Shapira* > > > > Product Manager | Confluent > > > > 650.450.2760 | @gwenshap > > > > Follow us: Twitter <https://urldefense. > proofpoint.com/v2/url?u=https- > > 3A__twitter.com_ConfluentInc&d=DwIBaQ&c=7563p3e2zaQw0AB1wrFVgyagb2IE5r > > TZOYPxLxfZlX4&r=nNmJlu1rR_QFAPdxGlafmDu9_r6eaCbPOM0NM1EHo-E&m=2JuW6J_ > > xPCRzueIjC4B6j1v6T9aXMR5k9Nh8oMBVLd0&s=hWdKCJsOe7LyDCcoJqmjOkgepGk776 > > 2xXxOZgQwHAm0&e= > | blog > > > > <https://urldefense.proofpoint.com/v2/url?u=http- > > 3A__www.confluent.io_blog&d=DwIBaQ&c=7563p3e2zaQw0AB1wrFVgyagb2IE5r > > TZOYPxLxfZlX4&r=nNmJlu1rR_QFAPdxGlafmDu9_r6eaCbPOM0NM1EHo-E&m=2JuW6J_ > > xPCRzueIjC4B6j1v6T9aXMR5k9Nh8oMBVLd0&s=Y_WMfuQJKoXlE3I25NKs8d4TefgB8Olv > > O8lDGAhEr7Q&e= > > > > > > > > > > >
