Hubert Kario writes:
>In my experience, many (12%) servers simply ignore the list of curves
>advertised by client and use the P-256 curve always.
>
>Some (58%) check if it was advertised and fallback to non-ECDHE if P-256 is
>not advertised.
When I checked, which is a year or two back now, I fou
Timothy Jackson:
> I’ve noted that many (most?) TLS implementations choose their ECDHE curves
> seemingly without regard to the cipher suite strength. Thus, they'll select
> an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then
> generate an ECDHE key on the P256 curve. This
>>I’d state secp384r1 (...) as "NOT RECOMMENDED" to bother with,
>> but still permitted
>
>I'd say it is a tad bit too strong of a wording for the strongest curve
>supported by SChannel...
+1 to Hubert.
smime.p7s
Description: S/MIME cryptographic signature
___
On Tuesday 22 March 2016 23:26:22 Dave Garrett wrote:
> X25519, secp256r1, X448, one of ffdhe3072 or ffdhe4096, and then
> lastly, ffdhe8192 and/or secp521r1 only as emergency backup
> (arguably, X448 belongs back here too)
>
> I'd like to specify ffdhe2048 (~103-bit strength) as "MUST NOT" use
>
On Wednesday 23 March 2016 00:38:13 Timothy Jackson wrote:
> I’ve noted that many (most?) TLS implementations choose their ECDHE
> curves seemingly without regard to the cipher suite strength. Thus,
> they'll select an AES256 cipher suite (e.g.
> TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then genera
On Wed, Mar 23, 2016 at 12:38:13AM +, Timothy Jackson wrote:
> I’ve noted that many (most?) TLS implementations choose their ECDHE
> curves seemingly without regard to the cipher suite strength. Thus,
> they'll select an AES256 cipher suite (e.g.
> TLS_ECDHE_ECDSA_WITH_AES256_SHA384),
> but th
On Tuesday, March 22, 2016 08:38:13 pm Timothy Jackson wrote:
> How would this group feel about a proposal to address this by specifying in
> the 1.3 specification that implementations must ensure that the strength of
> the certificate must be >= strength of ECDHE/DHE >= strength of the cipher?
> How would this group feel about a proposal to address this by
> specifying in the 1.3 specification that implementations must ensure
> that the strength of the certificate must be >= strength of ECDHE/DHE >=
> strength of the cipher?
Strongly opposed, for the reasons Martin said. Insisting that
On Tue, Mar 22, 2016 at 5:38 PM, Timothy Jackson
wrote:
> I’ve noted that many (most?) TLS implementations choose their ECDHE curves
> seemingly without regard to the cipher suite strength. Thus, they'll select
> an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then
> generat
On 23 March 2016 at 11:38, Timothy Jackson wrote:
> How would this group feel about a proposal to address this by specifying in
> the 1.3 specification that implementations must ensure that the strength of
> the certificate must be >= strength of ECDHE/DHE >= strength of the cipher?
There are goo
I’ve noted that many (most?) TLS implementations choose their ECDHE curves
seemingly without regard to the cipher suite strength. Thus, they'll select an
AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then
generate an ECDHE key on the P256 curve. This seems odd to me, since t
11 matches
Mail list logo
