On Fri, Jul 27, 2018 at 6:43 AM, Karthikeyan Bhargavan <
karthik.bharga...@gmail.com> wrote:
>
> As with Universal PSKs (UPSKs), each input key is a triplet of
> (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity
> as used today. To use a UPSK, an implementation takes the set of
> As with Universal PSKs (UPSKs), each input key is a triplet of
> (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity
> as used today. To use a UPSK, an implementation takes the set of KDF
> hashes it knows about H_i and derives a set of PSKs
To be clear, you’re suggesting that
On Fri, Jul 27, 2018 at 05:00:52AM -0700, Eric Rescorla wrote:
> On Fri, Jul 27, 2018 at 12:18 AM, Ilari Liusvaara
> wrote:
>
> > On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
> >
> > > Here’s a specific construction, but we’re flexible about the details:
> > >
> > >struct {
On Fri, Jul 27, 2018 at 12:18 AM, Ilari Liusvaara
wrote:
> On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
>
> > Here’s a specific construction, but we’re flexible about the details:
> >
> >struct {
> >opaque base_identity<1...2^16-1>;
> >HashAlgorithm hash;
> >
On Thu, 2018-07-26 at 10:58 -0700, Eric Rescorla wrote:
> Ben,
>
> Thanks for focusing on this issue.
>
> Chris and I have been discussing an alternative design which we think
> is more consistent with the existing structure, which we call PSK
> Importers. As with your design, we have an input u
On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
> Here’s a specific construction, but we’re flexible about the details:
>
>struct {
>opaque base_identity<1...2^16-1>;
>HashAlgorithm hash;
>} imported_psk_identity;
>
>UPSKx = HKDF-Extract(0, UPSK) // UP
On Thu, Jul 26, 2018 at 11:38 AM, Benjamin Kaduk wrote:
> On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
> > Ben,
> >
> > Thanks for focusing on this issue.
>
> Just trying to make sure loose ends get wrapped up before TLS 1.3 goes
> final...
>
> > Chris and I have been discussing
On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
> Ben,
>
> Thanks for focusing on this issue.
Just trying to make sure loose ends get wrapped up before TLS 1.3 goes final...
> Chris and I have been discussing an alternative design which we think
> is more consistent with the exist
Ben,
Thanks for focusing on this issue.
Chris and I have been discussing an alternative design which we think
is more consistent with the existing structure, which we call PSK
Importers. As with your design, we have an input universal PSK, but
instead of using explicitly as part of the connection
I can speak a little to how the reuse of keys will affect existing TLS 1.3
proofs and analyses.
First it is worth noting that most TLS 1.3 proofs do not consider hash function
agility, and say nothing about deploying TLS 1.3 in parallel to TLS 1.2 (with
some exceptions like [1], [2])
So, the go
On Fri, 2018-07-20 at 08:42 -0400, David Benjamin wrote:
>
> > I understand, but as I have already mentioned that argument also
> > applies for RSA keys which can be used e.g., for RSA encryption
> > under
> > TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be
> > used
> > with mult
On 20/07/18 13:42, David Benjamin wrote:
> I think that's the point of deciding this immediate question now, so we
> can get some text in the specification. If we decide to fix this, we'd
> instruct implementations to (temporary!) turn off TLS 1.3 if 1.2 PSKs
> are configured and then, once the
Hi all,
Couldn't make it to the second TLS session, but I did suggest on the
mailing list a tweak to the universal PSK draft that achieves
compatibility, unambiguity, and is straight-forward to prove secure
formally. (By which I mean prove independent of the security of TLS 1.2,
and thus any hash
On Fri, Jul 20, 2018 at 08:42:47AM -0400, David Benjamin wrote:
>
> (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is
> probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't
> think we actually believe SHA256 and SHA384 give related output. It's just
> nice t
On Fri, Jul 20, 2018 at 7:39 AM Nikos Mavrogiannopoulos
wrote:
> On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote:
> > >
> > > > This is somewhat timely, as if we do want to introduce a
> > > restriction,
> > > > it
> > > > would ideally be in the form of some text in the TLS 1.3
> > > > sp
On Fri, Jul 20, 2018 at 4:39 AM, Nikos Mavrogiannopoulos
wrote:
> On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote:
> > >
> > > > This is somewhat timely, as if we do want to introduce a
> > > restriction,
> > > > it
> > > > would ideally be in the form of some text in the TLS 1.3
> > > > s
On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote:
> >
> > > This is somewhat timely, as if we do want to introduce a
> > restriction,
> > > it
> > > would ideally be in the form of some text in the TLS 1.3
> > > specification,
> > > which is very nearly done.
> > >
> > > It would be good to
On Fri, Jul 20, 2018 at 3:43 AM, Ilari Liusvaara
wrote:
> On Fri, Jul 20, 2018 at 10:43:48AM +0100, Matt Caswell wrote:
> >
> >
> > On 20/07/18 10:38, Eric Rescorla wrote:
> > > The issue is not cross-protocol attacks; it's the reuse of PSKs with
> > > different KDFs, which we don't have any anal
On Fri, Jul 20, 2018 at 10:43:48AM +0100, Matt Caswell wrote:
>
>
> On 20/07/18 10:38, Eric Rescorla wrote:
> > The issue is not cross-protocol attacks; it's the reuse of PSKs with
> > different KDFs, which we don't have any analysis for and which the TLS
> > 1.3 document prohibits.
>
> Can you
On 20/07/18 10:38, Eric Rescorla wrote:
> The issue is not cross-protocol attacks; it's the reuse of PSKs with
> different KDFs, which we don't have any analysis for and which the TLS
> 1.3 document prohibits.
Can you supply the reference for that prohibition?
Thanks
Matt
___
On Fri, Jul 20, 2018 at 12:29 AM, Nikos Mavrogiannopoulos
wrote:
> On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote:
> > Hi all,
> >
> > As I mentioned at the mic today, there is a question that has been
> > raised about whether it's wise to reuse an existing (TLS 1.2) PSK
> > directly in
On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote:
> Hi all,
>
> As I mentioned at the mic today, there is a question that has been
> raised about whether it's wise to reuse an existing (TLS 1.2) PSK
> directly in the TLS 1.3 key ladder. At a high level, the reason why
> one
> might want to
22 matches
Mail list logo
