Re: [TLS] SHA-3 in SignatureScheme

2016-09-05 Thread Nikos Mavrogiannopoulos
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 do

Re: [TLS] SHA-3 in SignatureScheme

2016-09-05 Thread Yoav Nir
> 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) we had >>> to make

Re: [TLS] SHA-3 in SignatureScheme

2016-09-05 Thread Ilari Liusvaara
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

[TLS] draft-davidben-tls-grease-01

2016-09-05 Thread Hubert Kario
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 th

Re: [TLS] draft-davidben-tls-grease-01

2016-09-05 Thread David Benjamin
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 again!). I've also revi

Re: [TLS] draft-davidben-tls-grease-01

2016-09-05 Thread Hubert Kario
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 > > > https://tools.ietf.org/html/draft-davidben-tls-grease-01 which hopef

Re: [TLS] draft-davidben-tls-grease-01

2016-09-05 Thread David Benjamin
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 finally gotten to uploading > > > > http

Re: [TLS] draft-davidben-tls-grease-01

2016-09-05 Thread Hubert Kario
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. > > > > So for it,

[TLS] PR#625: Change alert requirements

2016-09-05 Thread Eric Rescorla
PR: https://github.com/tlswg/tls13-spec/pull/625 Currently the TLS spec requires implementations to send alerts under various fatal conditions. However, many stacks actually don't send alerts but instead just terminate the connection. Several people have argued that we should relax the requirement

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-05 Thread Hilarie Orman
> 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" writes: > > > > > > > >> > Yes. To a large extent, the "IoT devices are too pun

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-05 Thread Ben Laurie
On 5 September 2016 at 20:06, Hilarie Orman wrote: > At some time when attribution was hard, I wrote: > > On 31 August 2016 at 20:48, Hilarie Orman wrote: > > > An ARM is far too much hardware to throw at "read sensor/munge data/send > > > data". > > > The question is not "how much hardware?"

Re: [TLS] CertficateRequest extension encoding

2016-09-05 Thread Andrei Popov
Ø 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 to

Re: [TLS] CertficateRequest extension encoding

2016-09-05 Thread David Benjamin
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 server > to check the certifi

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-05 Thread Joachim Strömbergson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Hilarie Orman wrote: >> On 31 August 2016 at 20:48, Hilarie Orman >> wrote: > From: Brian Sniffen > >> The question is not "how much hardware?" but "price?" - with ARMs >> including h/w AES coming in at $2 for a single unit, its ha