Kyle Rose writes:
>In that case, we should dispense with any larger key sizes and recommend
>exactly one per algorithm, and vary only on algorithm. Adopting this would
>simplify things even further by reducing the cipher set list by an order of
>magnitude.
Yup.
>Sadly, I'm guessing there are nu
>>Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems
>>like comparing apples, orangles, pears and kumquants.
>>
>>Even if the nominal strengths are the same, the scaling of strengths is going
>>to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH vs.
>>
Ilari Liusvaara writes:
>Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems
>like comparing apples, orangles, pears and kumquants.
>
>Even if the nominal strengths are the same, the scaling of strengths is going
>to be different (e.g. the quadric vs. linear sub-treshold sc
On Wed, Jul 22, 2015 at 02:16:43AM -0700, Martin Thomson wrote:
> On 22 July 2015 at 01:50, Kyle Rose wrote:
> > I'd like to see the bits of the cipher suite associated entirely with
> > ephemeral data tied together roughly by security margin
>
> I've seen this argument several times, but there a
On 22 July 2015 at 01:50, Kyle Rose wrote:
> I'd like to see the bits of the cipher suite associated entirely with
> ephemeral data tied together roughly by security margin
I've seen this argument several times, but there are reasons why you
might want a non-homogenous strength profile.
The argu
I'd like to see the bits of the cipher suite associated entirely with
ephemeral data tied together roughly by security margin, to avoid
combinations that don't make sense (e.g., straw men of RSA384 + AES256
or AES256 + CRC32). This means: the type/size of the (EC)DHE group and
the symmetric cipher
I've updated the a la carte proposal again with some improvements to
readability. I've also added in the ECDHE PSK cipher suites in the current
draft, as they are required for this.
current WIP text:
https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites
di
Since the last time I posted it here, I've made some changes. Everything is
rebased on top of what is now PR #201 (it's not really severable from that).
https://github.com/davegarrett/tls13-spec/compare/alertsandcerts...davegarrett:alacarte
Now that resumption is PSK-based, some of the language
On Sun, Jul 19, 2015 at 8:53 PM, Manuel Pegourie-Gonnard
wrote:
> Hi,
>
> sorry for resurecting an old message on a fairly tangential point.
>
> On 6/12/15 10:31, Ilari Liusvaara wrote:
>
>> AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for
>> both DHE (via ciphersuites) and E
Hi,
sorry for resurecting an old message on a fairly tangential point.
On 6/12/15 10:31, Ilari Liusvaara wrote:
AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for
both DHE (via ciphersuites) and ECDSA (via (possibly implicit default)
signature_algorithms).
(In TLS 1.1 and ea
10 matches
Mail list logo
