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, Hub
+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
replaces the mask generating function MGF.
This would mak
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 going to make things harder
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, and so painful to deplo
> 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 clien
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. Client certs are so rare, and so painful to deploy, th
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
tra
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, Xiaoyin Liu wro
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 use a less powerful
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&S
> On Sep 05, 2016, at 14:02, Eric Rescorla wrote:
>
> PR: https://github.com/tlswg/tls13-spec/pull/625
>
> Currently the TLS spec requires implementations to send al
On Tue, Sep 6, 2016 at 2:33 PM, Sean Turner wrote:
> 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.
So I'd like to know if there are places this PR weakens the
requirement beyond what common practice is. Why is the unexpect
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 AES coming in at $2
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 automotive
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
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]
> client_authz [RFC5878]
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 nam
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&S
On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin
wrote:
> I think this is a good idea. It's kind of weird, but it avoids giving
17 matches
Mail list logo
