Re: [TLS] Finished stuffing

Hi Folks, The chairs want to make sure this gets some proper review. Please respond with comments by Friday so we can make some progress on this issue. Thanks, J On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin wrote: > I think this is a good idea. It's kind of weird,

Re: [TLS] [Cfrg] 3DES diediedie

OK, so I said I'd get some notes on the environment within which IoT crypto has to function, here's what the peanut gallery came up with. A lot of this isn't my own work and I don't claim it to be, it's a collaboration created by people who for various business/legal reasons can't attach their

Re: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3

I agree that client_authz and server_authz have not enjoyed much implementation. Russ On Sep 3, 2016, at 3:54 PM, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/624 > > We currently have code points assigned for > > user_mapping [RFC4681] >

Re: [TLS] [Cfrg] 3DES diediedie

The market is moving to ARM Cortex Ms, in part because of their clean I/O architecture and good SoC support. An M0 with integrated BLE chipset is easily <1$ today at small scale. Extrapolate a few years and to volume of millions between large companies rather than small startups. Software like

Re: [TLS] [Cfrg] 3DES diediedie

Hi Dave, Might work for lightbulbs. Doesn't work for automotive sensors and ECUs, which already have proprietary security (undisclosed algorithms) and badly need to have standards-based security. Cents in cost really matter here. ARM CPUs are not and will not become the only answer in

Re: [TLS] [Cfrg] 3DES diediedie

On Tuesday, September 06, 2016 04:40:30 pm Derek Atkins wrote: > Ben Laurie writes: > > An ARM is far too much hardware to throw at "read sensor/munge data/send > > data". > > > > The question is not "how much hardware?" but "price?" - with ARMs > > including h > > /w

Re: [TLS] PR#625: Change alert requirements

All, The chairs would like to get some eyes on this PR by this Friday (Sept 9th) so that we can draw it to close. Thanks, J > On Sep 05, 2016, at 14:02, Eric Rescorla wrote: > > PR: https://github.com/tlswg/tls13-spec/pull/625 > > Currently the TLS spec requires

Re: [TLS] [Cfrg] 3DES diediedie

Ben Laurie writes: > An ARM is far too much hardware to throw at "read sensor/munge data/send > data". > > The question is not "how much hardware?" but "price?" - with  ARMs including h > /w AES coming in at $2 for a single unit, its hard to explain why you\d want > to

Re: [TLS] IANA Alert registry does not include ALPN alert

Will do. Might not make the -00 version but we can add it as an issue to fix in -01. spt > On Aug 26, 2016, at 10:41, Eric Rescorla wrote: > > I believe the chairs are preparing an IANA update RFC. We can cram it in > there. > > -Ekr > > > On Fri, Aug 26, 2016 at 7:27 AM,

Re: [TLS] Finished stuffing

I think this is a good idea. It's kind of weird, but it avoids giving the early Finished such a strange relationship with the handshake transcript. Also a fan of doing away with multiple PSK identities if we don't need it. As a bonus, this removes the need to route a "phase" parameter into the

Re: [TLS] CertficateRequest extension encoding

Peter Gutmann writes: > David Benjamin writes: > > >Either way I imagine our stack will just keep on ignoring it, so I don't feel > >about this all too strongly. But the topic came up so I thought I'd suggest > >this. > > I ignore it too.

Re: [TLS] CertficateRequest extension encoding

> The design seems to be based on the idea that each > client has a smorgasbord of certs and the server can specify in > precise detail in advance which one it wants... This is actually a pretty good description of a number of deployments our customers have. On the other hand, a lot of Web

Re: [TLS] CertficateRequest extension encoding

On 2016-09-06 16:15, Peter Gutmann wrote: David Benjamin writes: Either way I imagine our stack will just keep on ignoring it, so I don't feel about this all too strongly. But the topic came up so I thought I'd suggest this. I ignore it too. Client certs are so rare,

Re: [TLS] CertficateRequest extension encoding

David Benjamin writes: >Either way I imagine our stack will just keep on ignoring it, so I don't feel >about this all too strongly. But the topic came up so I thought I'd suggest >this. I ignore it too. Client certs are so rare, and so painful to deploy, that I'm not

Re: [TLS] SHA-3 in SignatureScheme

+1 On 9/6/16, 7:47 , "TLS on behalf of Gilles Van Assche" wrote: Hello, For RSA PSS, I would suggest to consider: rsa_pss_shake128 rsa_pss_shake256 where SHAKE128 (or 256), as an exendable output function (XOF), directly

Re: [TLS] SHA-3 in SignatureScheme

Hello, For RSA PSS, I would suggest to consider: rsa_pss_shake128 rsa_pss_shake256 where SHAKE128 (or 256), as an exendable output function (XOF), directly replaces the mask generating function MGF. This would make RSA PSS simpler and more efficient. Kind regards, Gilles On 01/09/16 19:38,