Date: Mon, 19 Mar 2018 21:00:21 +0000 (UTC) From: Ning Wei Message-ID: <1783935013.3421880.1521493221569@...2084...> In-Reply-To: References: <20180316164059.9120-1-xiaoningning@...109...> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3421878_981046224.1521493221566" Subject: Re: [Openvpn-devel] [PATCH] Increase TLS Control Channel Buffer Size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Selva Nair Cc: openvpn-devel ------=_Part_3421878_981046224.1521493221566 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry, I did not state the intent clearly in the request. We wanted to use password field to pass authentication string, such as Toke= n string,which can be long, the user auth plug in on the sever side can val= idate the token asthe part authentication step. Acquiring a token, such as JWT, usually involves user interaction with the = token brokerservice provider.=C2=A0 So it is better to do this on the clien= t side. I agreed on the following statement.=C2=A0 To support a long password field= in TLS channels,the Buf size of 4096 is not enough in=C2=A0key_method_2_wr= ite.=C2=A0 Should we propose to increase the buffer size further? "Further, even a TLS_CHANNEL_BUF_SIZE of 4096 does not support a password that long as there are other things like username, key-source, local-options that have to fit into the buffer (see key_method_2_write). So what's the logic behind 4096?" Regards,Ning On Friday, March 16, 2018, 10:30:45 AM PDT, Selva Nair wrote:=20=20 =20 Hi, Apologies in advance if I'm misreading the intent of this patch. On Fri, Mar 16, 2018 at 12:40 PM, Ning Wei via Openvpn-devel wrote: > Increase TLS_CHANNEL_BUF_SIZE to 4096. When the build is enabled with > ENABLE_PKCS11, the password field can be 4096.=C2=A0 The old size of > TLS_CHANNEL_BUF_SIZE was 2048, which is not enough. I do not follow the logic behind this. Sure, ENABLE_PKCS11 increases the password buffer size to 4096, but pkcs11 password is only consumed locally, not sent out to the remote. Now, even if a auth-user-pass password or challenge response gets as large as 4096 bytes, there are other places in the code that need "fixing" to permit such long "passwords" (or response) -- e.g., it can= not be submitted via the management as the parser expects a max line length of 255 and word length of 255. Further, even a TLS_CHANNEL_BUF_SIZE of 4096 does not support a password that long as there are other things like username, key-source, local-options that have to fit into the buffer (see key_method_2_write). So what's the logic behind 4096? Finally, are there any particular challenge-response framework that requires such long responses? Even for U2F, we wouldn't need to send a response that large. U2F registration response could get very long (still mostly und= er 2000 bytes), but doing U2F key registration via the authentication channel = is not a good implementation. Authentication responses are much smaller. In short, it looks premature to increase this value before we start supporting long responses via the management, and a real practical need for long challenge response strings that won't fit in the current 2048 bytes (minus overhead) arise. Selva =20=20= ------=_Part_3421878_981046224.1521493221566 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, I did not state the intent clearly in the request.<= /div>

We wanted to use password field to pass authentica= tion string, such as Token string,
which can be long, the user au= th plug in on the sever side can validate the token as
the part a= uthentication step.

Acquiring a token, such as JWT= , usually involves user interaction with the token broker
service= provider.  So it is better to do this on the client side.
<= br>
I agreed on the following statement.  To support a long = password field in TLS channels,
the Buf size of 4096 is not enoug= h in key_method_2_write.  Should we propose to
incr= ease the buffer size further?

"Further, even a TLS_CHANNEL_BUF_SIZE of 4096 does not support a
password that long as there are other things like = username, key-source,
local-options that ha= ve to fit into the buffer (see key_method_2_write). So
what's the logic behind 4096?"

Regards,
Ning
=20=20=20=20=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
On Friday, March 16, 2018, 10:30:45 AM PDT, Selva N= air <selva.nair@...277...> wrote:


Hi,
Apologies in advance if I'm misreading the intent o= f this patch.

On Fri, = Mar 16, 2018 at 12:40 PM, Ning Wei via Openvpn-devel
> Increase TLS_CHANNEL_BUF_= SIZE to 4096. When the build is enabled with
>= ENABLE_PKCS11, the password field can be 4096.  The old size of
> TLS_CHANNEL_BUF_SIZE was 2048, which is not enoug= h.

I do not follow the= logic behind this. Sure, ENABLE_PKCS11 increases the
password buffer size to 4096, but pkcs11 password is only consumed
=
locally, not sent out to the remote.

Now, even if a auth-user-pass passwor= d or challenge response gets as
large as 4096 byt= es, there are other places in the code that
need = "fixing" to permit such long "passwords" (or response) -- e.g., it cannot
be submitted via the management as the parser expe= cts a max line
length of 255 and word length of 2= 55.

Further, even a TL= S_CHANNEL_BUF_SIZE of 4096 does not support a
pas= sword that long as there are other things like username, key-source,
local-options that have to fit into the buffer (see key= _method_2_write). So
what's the logic behind 4096= ?

Finally, are there a= ny particular challenge-response framework that requires
such long responses? Even for U2F, we wouldn't need to send a resp= onse
that large. U2F registration response could = get very long (still mostly under
2000 bytes), bu= t doing U2F key registration via the authentication channel is
not a good implementation. Authentication responses are much = smaller.

In short, it = looks premature to increase this value before we start
supporting long responses via the management, and a real practical
need for long challenge response strings that won't= fit in the current
2048 bytes (minus overhead) a= rise.

Selva
<= /div>
= ------=_Part_3421878_981046224.1521493221566--