On Jul 20, 2016 10:31 AM, "Martin Rex" wrote:
>
> Hubert Kario wrote:
> > Martin Rex wrote:
> >>
> >> Forget TLS extensions, forget ClientHello.client_version.
> >> Both in fundamentally broken, and led to Web Browsers coming up
> >> with the "downgrade dance" that is target&victim of the POODLE a
Hubert Kario wrote:
> Martin Rex wrote:
>>
>> Forget TLS extensions, forget ClientHello.client_version.
>> Both in fundamentally broken, and led to Web Browsers coming up
>> with the "downgrade dance" that is target&victim of the POODLE attack.
>>
>> We know fairly reliably what kind of negotiatio
On 07/20/2016 05:01 AM, Hanno Böck wrote:
> On Wed, 20 Jul 2016 11:20:46 +0200
> Hubert Kario wrote:
>
>> so it looks to me like while we may gain a bit of compatibility by
>> using extension based mechanism to indicate TLSv1.3,
> Just quick: This was discussed yesterday, David Benjamin had an
> i
On 07/20/2016 12:42 AM, Hugo Krawczyk wrote:
>
> Actually, I would suggest that for any such value, we add "collision
> resistance" to the label for that derivation - this would apply to
> resumption/PSK context and to Exporter key (and possibly others)
>
Seems reasonable; space in the label is re
Hi Dan,
On your first comment, Yes, J-PAKE requires one more flow, but for the
following benefits
* Unlike EKE and SRP, it has the flexibility to work in any prime-order
subgroup over a finite field (e.g., DSA-like groups).
* Unlike SPAKE2, it doesn't require setting up two generators whose
On Wednesday, 20 July 2016 06:24:50 CEST Watson Ladd wrote:
> On Wed, Jul 20, 2016 at 6:13 AM, Hubert Kario wrote:
> > On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote:
>
>
> > I think that implementing complex binary cryptographic protocols is simply
> > hard.
>
> And what conclusion s
On Wed, Jul 20, 2016 at 6:13 AM, Hubert Kario wrote:
> On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote:
> I think that implementing complex binary cryptographic protocols is simply
> hard.
>
And what conclusion should one draw about TLS 2.0 (*ahem* 1.3) as a
result of this realization?
On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote:
> > it's not IETF's fault that the implementers add unspecified by IETF
> > restrictions and limitations to parsers of Client Hello messages or that
> > they can't handle handshake messages split over multiple record layer
> > messages, desp
> it's not IETF's fault that the implementers add unspecified by IETF
> restrictions and limitations to parsers of Client Hello messages or that
> they can't handle handshake messages split over multiple record layer
> messages, despite the standard being very explicit in that they MUST
> support t
On Wednesday, 20 July 2016 13:57:36 CEST Ilari Liusvaara wrote:
> On Wed, Jul 20, 2016 at 11:20:46AM +0200, Hubert Kario wrote:
> > So I have partial results after scanning around 14 000 domains.
> > The scanner was able to connect to 12 606 hosts that presented unexpired
> > certificates signed by
On Wednesday, 20 July 2016 12:14:01 CEST Martin Rex wrote:
> Hanno Böck wrote:
>
> Checking application/pgp-signature: FAILURE
>
> > Hubert Kario wrote:
> >> so it looks to me like while we may gain a bit of compatibility by
> >> using extension based mechanism to indicate TLSv1.3,
>
> Forget T
So Dan,
If your reasoning is correct, it seems like an individual submission "using TLS
for ECJ-PAKE" seems more appropriate than a TLS WG document or any codepoint
assignment (since as you say they can use the private-use one).
/r$
--
Senior Architect, Akamai Technologies
IM: richs
On Wed, Jul 20, 2016 at 11:20:46AM +0200, Hubert Kario wrote:
>
> So I have partial results after scanning around 14 000 domains.
> The scanner was able to connect to 12 606 hosts that presented unexpired
> certificates signed by CA's in Mozilla root program.
>
> Of those:
> 93% support TLSv1.2 p
Hi Robert,
Sorry for the confusing comments. There are 2 but one follows
because of the other.
The first comment concerns the fact that J-PAKE is a 4 message
handshake. This is different than other PAKES like EKE, SPAKE2,
dragonfly, or SRP which all establish their shared key in a single
2
Hanno Böck wrote:
Checking application/pgp-signature: FAILURE
> Hubert Kario wrote:
>
>> so it looks to me like while we may gain a bit of compatibility by
>> using extension based mechanism to indicate TLSv1.3,
Forget TLS extensions, forget ClientHello.client_version.
Both in fundamentally bro
On Wed, 20 Jul 2016 11:20:46 +0200
Hubert Kario wrote:
> so it looks to me like while we may gain a bit of compatibility by
> using extension based mechanism to indicate TLSv1.3,
Just quick: This was discussed yesterday, David Benjamin had an
interesting proposal, but it was largely met with res
The TLS working group met on Tuesday morning. We are continuing progress on
TLS 1.3. Main discussion points included a change in the cipher suite model
from a monolithic ID approach to a menu based approach. During the
hackathon on Saturday we had 7 different TLS 1.3 implementations achieve
interop
On Monday, 18 July 2016 15:08:03 CEST Hubert Kario wrote:
> On Monday 18 July 2016 13:08:43 Hanno Böck wrote:
> > * We don't have good data on the issue. The latest numbers I could find
> >
> > came from Ivan Ristic in 2013 [4], and from David Benjamin we know he
> > considers the problem to b
Hi Dan,
What you say regarding the NamedCurve/EllipticCurveList is of course right.
Whether this constitutes a fundamental change to TLS is debatable. The aim
was never to propose this as a cipher suite for general inclusion in a
range of supported cipher suites in a browser/server scenario as is
19 matches
Mail list logo
