If I recall, TLS 1.2 was ambiguous on this point, so it's unclear what the
sender is expected to do.

I believe there were some implementations that expected a fixed-width
public key (which would have been the better option to pick, but we don't
have a time machine), so zero-padding on send is prudent. But since the
spec doesn't say, the receiver probably is stuck accepting both. Not all
senders zero pad, so that you've observed some doesn't surprise me too much.

But keep in mind that TLS 1.2 DHE ciphers use a flawed construction in many
other ways too.
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/

I'd recommend moving to ECDHE and, better yet, TLS 1.3.


On Wed, Oct 18, 2023, 10:15 M K Saravanan <mksa...@gmail.com> wrote:

> one correction:
>
> > cipher suite used: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
>
> It is actually TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
>
>
> On Tue, 17 Oct 2023 at 13:55, M K Saravanan <mksa...@gmail.com> wrote:
>
>> Hi,
>>
>> I found a weird packet capture of DHE key exchange.
>>
>> C --> S
>> TLSv1.2
>> cipher suite used: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
>>
>> ServerKeyExchange message is sending:
>>
>> p length: 257 whereas pubkey length is: 256
>>
>> 256 means 256*8 = 2048 bit DHE key size.
>>
>> I am assuming, generally when using DHE, the p length and pubkey length
>> should match.
>>
>> Here p length = 257*8 = 2056 bits whereas pubkey len is 2048 bits, which
>> is unusual.
>>
>> Since SKE msg advertised a p len of 257, the client promptly responded
>> with a client public key size of 257 in its CKE msg to match the p len
>> advertised by SKE. Thus I feel the client behaviour is correct here.
>>
>> Can I know whether using diff p len and pubkey len allowed in DHE key
>> exchange?
>>
>> with regards,
>> Saravanan
>>
>> _______________________________________________
> 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

Reply via email to