On Aug 17, 2015 9:08 AM, "Salz, Rich" wrote:
>
> > I was more interested in the motivation. Same for Apple,
> > why would you implement something that pretty much no-one else (at the
> > time) supported, and for good reason?
>
> Perhaps because this was a year before Snowden and the mindset was
u
On 08/11/2015 02:05 PM, Peter Gutmann wrote:
> Clemens Hlauschek writes:
>
>> I published a paper today on KCI-attacks in TLS. This might be of interest to
>> the TLS WG.
>>
>> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
>
> Some comments on this, it looks
On Mon, Aug 17, 2015 at 03:53:59PM +, Peter Gutmann wrote:
> Viktor Dukhovni writes:
>
> >I can't answer why, but I know what and when:
>
> I was trying to avoid finger-pointing so I didn't go through the changelog to
> see whodunnit, I was more interested in the motivation. Same for Apple,
> I was more interested in the motivation. Same for Apple,
> why would you implement something that pretty much no-one else (at the
> time) supported, and for good reason?
Perhaps because this was a year before Snowden and the mindset was
unquestioning complete RFC implementation?
_
Viktor Dukhovni writes:
>I can't answer why, but I know what and when:
I was trying to avoid finger-pointing so I didn't go through the changelog to
see whodunnit, I was more interested in the motivation. Same for Apple, why
would you implement something that pretty much no-one else (at the tim
On Mon, Aug 17, 2015 at 03:18:14PM +, Viktor Dukhovni wrote:
> The relevant code was added to the 1.0.2 dev branch in Apr of 2012,
> backporting said code from the "master" branch where fixed DH
> support was enabled in January of 2012.
>
> On a related note, for what it's worth ECDSA certs a
On Mon, Aug 17, 2015 at 12:38:54PM +, Peter Gutmann wrote:
> One thing that I'd really like to know is that given the non-PFS (EC)DH suites
> were obviously a dumb idea and barely supported by anything (not just in terms
> of TLS code, no public CA I know of will issue the required X9.42 certs
they were added?
Peter.
From: Clemens Hlauschek [clemens.hlausc...@rise-world.com]
Sent: Wednesday, 12 August 2015 11:15
To: Peter Gutmann; tls@ietf.org
Subject: Re: [TLS] TLS and KCI vulnerable handshakes
On 08/11/2015 02:05 PM, Peter Gutmann wrote:
Ilari Liusvaara writes:
>a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is no
>ECDSA-specific keytype in X.509.
That's always concerned me about ECC certs, all you can say about a key is
"ECC", not "signing key" or "key agreement key" (I'm sure this was seen as a
great featur
On 08/11/2015 02:05 PM, Peter Gutmann wrote:
> Clemens Hlauschek writes:
>
>> I published a paper today on KCI-attacks in TLS. This might be of interest to
>> the TLS WG.
>>
>> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
>
> Some comments on this, it looks
On 08/11/2015 07:59 PM, Martin Thomson wrote:
> On 11 August 2015 at 16:38, Clemens Hlauschek
> wrote:
>>> Maybe I should have been clearer. The certificate might not include a
>>> (strong) signal that allows the client to distinguish between ECDSA
>>> and fixed ECDH, but the client might be conf
On Tue 2015-08-11 19:59:35 -0400, Martin Thomson wrote:
> On 11 August 2015 at 16:38, Clemens Hlauschek
> wrote:
[ MT wrote: ]
>>> NSS (incorrectly) adopts the posture that _ECDH_ suites are
>>> half-static: the server share is in the certificate, but the client
>>> side is fully ephemeral. Thi
On 11 August 2015 at 16:38, Clemens Hlauschek
wrote:
>> Maybe I should have been clearer. The certificate might not include a
>> (strong) signal that allows the client to distinguish between ECDSA
>> and fixed ECDH, but the client might be configured with that
>> knowledge.
>
> There is no differ
On 08/11/2015 05:06 PM, Martin Thomson wrote:
> On 11 August 2015 at 12:05, Ilari Liusvaara
> wrote:
>>> I don't see how that would work. A client that understands the cert
>>> to be ECDSA won't pair the key with the server's ECDH share, they will
>>> sign the session transcript with it.
>>
>>
On 11 August 2015 at 12:05, Ilari Liusvaara wrote:
>> I don't see how that would work. A client that understands the cert
>> to be ECDSA won't pair the key with the server's ECDH share, they will
>> sign the session transcript with it.
>
> a) ECDSA certs are usable for ECDH (modulo KeyUsage) beca
On Tue, Aug 11, 2015 at 11:29:12AM -0700, Martin Thomson wrote:
> On 11 August 2015 at 11:25, Karthikeyan Bhargavan
> wrote:
> > No, a regular ECDSA certificate would do.
> > That is, the attack would work as long as
> > - a client has an ECDSA certificate, and
> > - it enables any static TLS_ECDH
On 11 August 2015 at 11:25, Karthikeyan Bhargavan
wrote:
> No, a regular ECDSA certificate would do.
> That is, the attack would work as long as
> - a client has an ECDSA certificate, and
> - it enables any static TLS_ECDH_* cipher suite, and
> - its ECDSA private key has been stolen (or chosen) b
>> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
>
> Some comments on this, it looks like it requires a "cert with static (EC)DH
> key" in order to work, which would mean an X9.42 cert. Since no (public) CA
> that I know of can handle or issue such certs, this p
Clemens Hlauschek writes:
>I published a paper today on KCI-attacks in TLS. This might be of interest to
>the TLS WG.
>
>https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
Some comments on this, it looks like it requires a "cert with static (EC)DH
key" in order to w
19 matches
Mail list logo
