On Mon, Sep 05, 2016 at 10:17:58AM +0200, Nikos Mavrogiannopoulos wrote:
> On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla wrote:
>
> > > > I also am not following why we need to do this now. The reason we
> > > defined SHA-2 in
> > > > a new RFC was because (a) SHA-1 was looking weak and (b) we
> On 5 Sep 2016, at 11:17 AM, Nikos Mavrogiannopoulos wrote:
>
> On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla wrote:
>
I also am not following why we need to do this now. The reason we
>>> defined SHA-2 in
a new RFC was because (a) SHA-1 was looking weak and (b)
On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote:
> I've finally gotten to uploading
> https://tools.ietf.org/html/draft-davidben-tls-grease-01 which hopefully
> resolves the procedural issues (thanks again!). I've also revised the text
> slightly after some off-list feedback about
> On 31 August 2016 at 20:48, Hilarie Orman wrote:
> > > From: Brian Sniffen
> >
> > > >> From: Derek Atkins
> > > >> Date: Wed, 31 Aug 2016 10:17:25 -0400
> > > >
> > > >> "Steven M. Bellovin"
On Monday, 5 September 2016 15:55:49 CEST David Benjamin wrote:
> On Mon, Sep 5, 2016 at 10:59 AM Hubert Kario wrote:
> > On the other hand, the implementation I work on keeps the sent Client
> > Hello on
> > hand and checks the server response against the exact values it sent.
On Mon, Sep 5, 2016 at 10:59 AM Hubert Kario wrote:
> On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote:
> > On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario wrote:
> > > On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote:
> > > > I've
On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote:
> On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario wrote:
> > On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote:
> > > I've finally gotten to uploading
> > >
On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario wrote:
> On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote:
> > I've finally gotten to uploading
> > https://tools.ietf.org/html/draft-davidben-tls-grease-01 which hopefully
> > resolves the procedural issues (thanks
Ø And how is the value encoded? Using the same encoding as
extnValue payload of respective extension in X.509 certifcates?
The same encoding as the respective extension in X.509 certificates (please
feel free to suggest the language to make this clearer).
Ø A CertificateExtension is a hint
On Mon, Sep 5, 2016 at 5:46 PM Andrei Popov
wrote:
> Ø A CertificateExtension is a hint to the client about what kind of
> certificates are acceptable. We have a registry of u16s for them. Clients
> ignore extensions they don't understand, so it is ultimately on the
On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla wrote:
> > > I also am not following why we need to do this now. The reason we
> > defined SHA-2 in
> > > a new RFC was because (a) SHA-1 was looking weak and (b) we had
> > to make significant
> > > changes to TLS to allow the use of SHA-2. This
11 matches
Mail list logo