On Sat, 2015-07-18 at 21:22 -0400, Dave Garrett wrote:
> There's two issues (basically duplicates) for this topic, as well as
> an inline TODO.
> https://github.com/tlswg/tls13-spec/issues/66
> https://github.com/tlswg/tls13-spec/issues/72
> https://tlswg.github.io/tls13-spec/#server-hello
>
> Th
On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote:
> I think perhaps you have misunderstood the forward secrecy properties of the
> current draft. Unlike TLS 1.2 and previous, the current draft has a separate
> resumption master secret which is independently derived from the master
> secret
On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett
wrote:
> On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote:
> > I think perhaps you have misunderstood the forward secrecy properties of
> the
> > current draft. Unlike TLS 1.2 and previous, the current draft has a
> separate
> > resumption mas
On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote:
> Hubert Kario writes:
> > On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote:
> >> Hubert Kario writes:
> >> > As is described in secion 5.1. of RFC 4492, and then reiterated in
> >> > section 2.2. of this draft - the elliptic_curves (a.
On Mon, Jul 20, 2015 at 12:55:37PM +0200, Hubert Kario wrote:
> On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote:
> >
> > Compare how we "reuse" the ECDHE ciphersuite values to refer to
> > Curve25519 (instead of defining new ciphersuites for Curve25519), and
> > how we are "reusing" the "unc
On Monday 20 July 2015 14:39:03 Ilari Liusvaara wrote:
> On Mon, Jul 20, 2015 at 12:55:37PM +0200, Hubert Kario wrote:
> > On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote:
> > > Compare how we "reuse" the ECDHE ciphersuite values to refer to
> > > Curve25519 (instead of defining new ciphersu
>> TLS-pwd already supports both of these. It also supports ECC too,
>> which is problematic with the current SRP protocol.
>In the language of the CFRG draft, TLS-pwd is “balanced” where SRP is
“augmented”,
>so they’re not really equivalent, correct?
Correct.
>This is possible, but you’d need
>>This is possible, but you’d need to have the client and server negotiate
> based on
>>what they have. For example, if the server has a SRP verifier from the
> current
>>protocol, but the client has a stored PBKDF2 hash of the password for that
> server,
>>they cannot communicate and would need t
On Mon, Jul 20, 2015 at 01:42:01PM +0200, Hubert Kario wrote:
> On Monday 20 July 2015 14:39:03 Ilari Liusvaara wrote:
> > On Mon, Jul 20, 2015 at 12:55:37PM +0200, Hubert Kario wrote:
> >
> > There are other shortcomings tho:
> > - If Ed25519 is supported, one also needs to support Curve25519.
>
On Wednesday 15 July 2015 22:42:54 Dave Garrett wrote:
> On Wednesday, July 15, 2015 09:42:51 pm Dan Brown wrote:
> > What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the way
> > it has no unexplained constants...). Has it been removed already, or does
> > the question also refer K-
Some commentary on client authentication slides (there is no linked draft
nor other material yet).
- Mechanism like proposed looks dangerous when combined with HTTP/2.
Multiplexed protocols are in general not safe to authenticate without
application-layer signaling (which can be implicit via s
On Mon, Jul 20, 2015 at 12:10 AM, Eric Rescorla wrote:
>
>
> On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett
> wrote:
>
>> On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote:
>> > I think perhaps you have misunderstood the forward secrecy properties
>> of the
>> > current draft. Unlike
On Monday, July 20, 2015 01:31:15 pm Hugo Krawczyk wrote:
> Your question boils down to: Why is finished_secret derived from SS only
> and not from ES?
>
> First note that the issue only arises in the known_configuration case since
> in other cases ES and SS are the same.
> For the known_configura
On Thu 2015-07-09 15:43:16 +0200, Nikos Mavrogiannopoulos wrote:
> This draft uses the rfc6091 cert_type extension. If that is not
> intentional, rfc6091 was made obsolete by rfc7250 which uses the
> server_certificate_type and client_certificate_type extensions (even
> though the text doesn't men
14 matches
Mail list logo
