Re: [TLS] Simplifying signature algorithm negotiation

2016-01-19 Thread David Benjamin
On Fri, Jan 15, 2016 at 10:13 PM Brian Smith wrote: > David Benjamin wrote: > >> (Whether such certificates exist on the web is probably answerable via CT >> logs, but I haven't checked.) >> > > Me neither, and I think that's the key thing that would

Re: [TLS] [Technical Errata Reported] RFC5054 (4546)

2016-01-19 Thread Nikos Mavrogiannopoulos
Hi, I find the reported errata reasonable. On Sun, Jan 17, 2016 at 7:53 PM, Rick van Rein wrote: > Hello, > > Could I bring this erratum reported in November to your attention once > more? I think it calls for correction. > > Thanks, > -Rick >> RFC Errata System

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-19 Thread David Benjamin
Sorry, sent from the wrong address. On Tue, Jan 19, 2016 at 5:19 PM David Benjamin wrote: > On Sat, Jan 16, 2016 at 5:00 AM Hanno Böck wrote: > >> Hi, >> >> I generally like the idea of simplifying the different algorithm >> negotiation things, but: >> >>

Re: [TLS] Early code point assignment for ChaCha20-poly1305 cipher suites

2016-01-19 Thread Joseph Salowey
We're asking the IESG for early allocation of these code points. ​ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-19 Thread Ilari Liusvaara
On Tue, Jan 19, 2016 at 06:55:49PM +, David Benjamin wrote: > On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario wrote: > > > > > Problem I am pointing out is that NamedGroup specifies not only what > > curves can be used for signing but also what curves can get signed. > > > >

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

2016-01-19 Thread David Benjamin
BoringSSL has a pair of implementations ready (in C and in our fork of Go's TLS stack for testing). We're using the value in the TLS 1.3 draft, so 29. It's not currently enabled in any Chrome builds, but I'm expecting to change this soon. David On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-19 Thread Hubert Kario
On Tuesday 19 January 2016 16:50:18 David Benjamin wrote: > On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario wrote: > > On Friday 15 January 2016 20:45:34 David Benjamin wrote: > > > Hi folks, > > > > > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. > > > In

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-19 Thread David Benjamin
On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario wrote: > > > If it does not specify the DH share signed, it doesn't really change > > > anything... > > > > Why would it need to specify what [DH group's] DH share gets signed? > > NamedGroup still exists for the key exchange (see

Re: [TLS] chacha/poly for http/2

2016-01-19 Thread Hubert Kario
On Wednesday 13 January 2016 17:48:37 Salz, Rich wrote: > We (OpenSSL) have already tested interop of chacha/poly with other > browsers and TLS stacks, and now it all works. (The official IETF > version, not the QUIC version). I was able to confirm interoperability between tlslite-ng[1] and

Re: [TLS] Simplifying signature algorithm negotiation

2016-01-19 Thread David Benjamin
On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario wrote: > On Friday 15 January 2016 20:45:34 David Benjamin wrote: > > Hi folks, > > > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In > > TLS 1.2, signature algorithms are spread across the handshake. We > >