On Mon, Jun 18, 2018 at 11:47:25AM +0200, Nikos Mavrogiannopoulos wrote:
> 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
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?
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
>
Channel bindings are generally just horribly named.
The `channel` in that case would consist solely of the agreed key, and
agreement on it would prove that not only was that the key, but also that
nothing else was established.
Therefore you wouldn't be able to convince one side that it was just a
On Fri, Jun 15, 2018 at 05:26:33PM +0200, Jonathan Hoyland wrote:
> Agreement on a channel binding in the identity would prove, amongst other
> things, agreement on the KDF used to derive the PSK, whereas the TLS
> handshake proves agreement on the PSK itself, but says nothing about the
> derivatio
Agreement on a channel binding in the identity would prove, amongst other
things, agreement on the KDF used to derive the PSK, whereas the TLS
handshake proves agreement on the PSK itself, but says nothing about the
derivation of it.
This way means you don't have to worry about collisions between h
On Fri, Jun 15, 2018 at 10:56:48AM -0400, David Benjamin wrote:
> On Fri, Jun 15, 2018 at 7:37 AM Nikos Mavrogiannopoulos
> wrote:
>
> I think it's a little more complex than that. Keys used in multiple ways
> are affected by interactions between those uses, so formal analysis tends
> to want to
On Fri, Jun 15, 2018 at 7:37 AM Nikos Mavrogiannopoulos
wrote:
> On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote:
> > Hey all,
> >
> > So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS
> > 1.3 via the external PSK mechanism, repurposing the resumption flow.
> > But the
Is it not possible to construct a channel binding for whatever underlying
protocol was used to agree the PSK and use that as the PSK identity.
If the PSK was created in TLS 1.2 then that would be something derived from
`tls-unique`.
The security of a channel binding is not dependent on it being se
>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
quite antithetical to that
Disabling TLS 1.3 for those using 1.2 P
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 external PSKs should probably
> > design their protocols to provision u
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 some implementations which support
> universal PSKs and others whic
On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote:
> Hey all,
>
> So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS
> 1.3 via the external PSK mechanism, repurposing the resumption flow.
> But the security proof requires PSKs be associated with a specific
> hash for key s
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 external PSKs should probably
> design their protocols to provision universal PSKs instead, after it
> stabilizes.
>
> - Folks who
19 matches
Mail list logo
