> On Jun 18, 2018, at 3:12 PM, Ben Personick wrote:
>
> So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but
> willl otherwise work as expected?
No, it drops support for *non* (EC)DHE RSA ciphers,
keeping *only* the (EC)DHE RSA ciphers, for specific
FFDHE groups (as befor
Hello Tony,
So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but
willl otherwise work as expected?
Ben
From: Tony Arcieri
Sent: Monday, June 18, 2018 11:36
To: Ben Personick
Cc:
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13
On M
Hello Viktor,
I am only concerned with offereing newer , faster, and more secure cipher
suites on our web application, so that as clients have the ability to use them
they can begin to do so.
Our LB offers a method to present baoth an RSA and ECC cert at thw aame time,
at the cost of buyin
On Mon, Jun 18, 2018 at 12:12 PM Ben Personick
wrote:
> So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but
> willl otherwise work as expected?
>
DH/DHE ciphers are orthogonal to RSA key transport/encipherment. The latter
uses the RSA algorithm for encryption, without any
> On Jun 18, 2018, at 9:10 AM, Ben Personick wrote:
>
> There is a common thread circulating, that all support for RSA
> Certificates/Ciphers are dropped in TLS 1.3.
This is not the case.
> As I wrote in the last email, I am aware we can implemenet ECC certs and
> ciphers in TLS 1.2, along
On Mon, Jun 18, 2018 at 6:30 AM Ben Personick
wrote:
> There is a common thread circulating, that all support for RSA
> Certificates/Ciphers are dropped in TLS 1.3.
>
RSA certificates will continue to work in TLS 1.3+.
What will not be supported in TLS 1.3+ is RSA key transport / key
encipherme
Given that channel bindings are generally the output of a hash transcript
there seems to be minimal risk of PSK enumeration.
If I send a PSK that the server recognises, alongside one it does not,
would a server sometimes pretend to accept the PSK it does not recognise to
avoid enumeration attacks?
Hello Sean
Thanks for the explination. :)
Ben
From: Sean Turner
Sent: Saturday, June 16, 2018 11:04 PM
To: Ben Personick
Cc: tls@ietf.org
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13
> On Jun 12, 2018, at 16:15, Ben Personick wrote:
>
> I have
Hello Viktor,
Thanks for your thoughtful reply.
I haven't read the draft itself, only the articals which point to it.
There is a common thread circulating, that all support for RSA
Certificates/Ciphers are dropped in TLS 1.3.
As I wrote in the last email, I am aware we can implemenet E
On Mon, 2018-06-18 at 13:56 +0200, Jonathan Hoyland wrote:
> The issue with the current draft is that it leaves a single PSK with
> two potential interpretations.
> If the draft also changed the PSK identity value then each PSK would
> have a single interpretation.
> If the draft changes the ident
The issue with the current draft is that it leaves a single PSK with two
potential interpretations.
If the draft also changed the PSK identity value then each PSK would have a
single interpretation.
If the draft changes the identity then it can also change the PSK key
without having to change the m
On Friday, 15 June 2018 16:24:58 CEST Salz, Rich wrote:
> >that's not workable.
>
>
> It's not great, however
>
>
> >the reason why implementations chose to use old API to provision TLS
> >1.3 PSKs
> >was to make the upgrade process as smooth as possible, disabling TLS
> >
On Fri, 2018-06-15 at 13:00 +0100, Matt Caswell wrote:
>
> On 15/06/18 12:37, Nikos Mavrogiannopoulos wrote:
> > It feels that's this is too little too late. Implementations which
> > support PSKs will switch to TLS1.3 irrespective of this proposal.
> > If
> > this proposal takes on, we will have
On Fri, 2018-06-15 at 09:11 -0400, David Benjamin wrote:
> On Fri, Jun 15, 2018 at 7:14 AM Hubert Kario
> wrote:
> > On Thursday, 14 June 2018 21:46:27 CEST David Benjamin wrote:
> > > Thoughts? If the WG likes this design, I would suggest:
> > >
> > > - Most folks who want to use TLS 1.3 with ex
On Fri, 2018-06-15 at 14:24 +, Salz, Rich wrote:
> >that's not workable.
>
>
> It's not great, however
>
> >the reason why implementations chose to use old API to provision
> > TLS 1.3 PSKs
>
> was to make the upgrade process as smooth as possible, disabling
> TLS 1.3 is
>
On Thu, 2018-03-01 at 21:52 +, Paterson, Kenny wrote:
> Hi,
>
> I've been analysing the record protocol spec for TLS 1.3 a bit,
> specifically the new padding mechanism. I think there's a possible
> timing attack on a naïve implementation of de-padding. Maybe this is
> already known to people
16 matches
Mail list logo
