<div dir="ltr">Hi,<div>Thank you for the clarifications.</div><div><br></div><div>Regards,<br>Sanjaya</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 8, 2018 at 4:30 PM, Jakob Bohm <span dir="ltr"><<a href="mailto:jb-openssl@wisemo.com" target="_blank">jb-openssl@wisemo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Top posting for consistency).<br>
<br>
Once the client receives the TLS1.2 servers choice of DH group,<br>
it can either accept it or abort the connection.<br>
<br>
However if both client and server support the "supported_groups"<br>
extension (RFC4492) with the additional DH group identifiers in<br>
RFC7919, they can negotiate a common accepted group of desired<br>
strength, though the mechanism (like TLS1.3) is artificially<br>
limited to a fixed set of groups listed in the RFC.<span class=""><br>
<br>
<br>
On 08/06/2018 12:15, Sanjaya Joshi wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Hello,<br>
Thank you Matt and Jordan. So, it seems that it's possible to modify my client to accept/reject the DH group key length. But i have one more issue to be clarified.<br>
<br>
Is it possible that if a client does not accept the DH group key length used by the server, then, a different possible cipher (for e.g., RSA) is tried to be negotiated. It seems that the connection is rejected, instead of falling back to a different possible cipher. At least, i tested this quickly using s_client and s_server, and the behavior is as stated above, i.e., no fallback and connection was terminated. Is this the default OpenSSL behavior or this behaviour could be modified somehow by applications ?<br>
<br>
Regards,<br>
Sanjaya<br>
<br></span><span class="">
On Thu, Jun 7, 2018 at 8:43 PM, Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>>> wrote:<br>
<br>
<br>
<br>
    On 07/06/18 16:02, Jordan Brown wrote:<br>
    > I do not understand, however, how the 80 relates to a 1024-bit<br>
    limit.<br>
<br>
    It's a measure of the "security bits" of an algorithm according to<br>
    table<br>
    2 in this doc:<br>
    <a href="https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf" rel="noreferrer" target="_blank">https://nvlpubs.nist.gov/nistp<wbr>ubs/specialpublications/nist.<wbr>sp.800-57pt1r4.pdf</a><br></span>
    <<a href="https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf" rel="noreferrer" target="_blank">https://nvlpubs.nist.gov/nist<wbr>pubs/specialpublications/nist.<wbr>sp.800-57pt1r4.pdf</a>><br>
<br>
</blockquote>
<br>
Enjoy<span class="HOEnZb"><font color="#888888"><br>
<br>
Jakob<br>
-- <br>
Jakob Bohm, CIO, Partner, WiseMo A/S.  <a href="https://www.wisemo.com" rel="noreferrer" target="_blank">https://www.wisemo.com</a><br>
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10<br>
This public discussion message is non-binding and may contain errors.<br>
WiseMo - Remote Service Management for PCs, Phones and Embedded</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailma<wbr>n/listinfo/openssl-users</a><br>
</div></div></blockquote></div><br></div>