Hi,
>Some answers to your questions inline. I'm not sure further changes along the
>lines suggested here are needed, but I'm open to arguments that point in that
>direction.
I am mostly fine with your answers. Just a couple of comments inline still.
---
MIN_2:
Can the mechanism be used
Thanks Christer,
Some answers to your questions inline. I'm not sure further changes along
the lines suggested here are needed, but I'm open to arguments that point
in that direction.
On Thu, Sep 19, 2019 at 1:55 AM Christer Holmberg <
christer.holmb...@ericsson.com> wrote:
> Hi Nick,
>
> Thanks
On Thu, Sep 19, 2019 at 06:03:44PM -0400, Richard Barnes wrote:
> On Thu, Sep 19, 2019 at 5:49 PM Nico Williams wrote:
> > On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> > > I don't think anyone's asking for these cases to be differentiable on the
> > > wire. The question is wh
On Thu, Sep 19, 2019 at 5:49 PM Nico Williams wrote:
> On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> > I don't think anyone's asking for these cases to be differentiable on the
> > wire. The question is whether the *server* can differentiate, in
> > particular, the applicatio
On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> I don't think anyone's asking for these cases to be differentiable on the
> wire. The question is whether the *server* can differentiate, in
> particular, the application running on the server.
And the answer to that one is "yes",
On Thu, 19 Sep 2019 at 21:57, Richard Barnes wrote:
> I don't think anyone's asking for these cases to be differentiable on the
> wire. The question is whether the *server* can differentiate, in
> particular, the application running on the server.
>
> --Richard
>
Exactly. I hope it's not controv
I don't think anyone's asking for these cases to be differentiable on the
wire. The question is whether the *server* can differentiate, in
particular, the application running on the server.
--Richard
On Thu, Sep 19, 2019 at 2:36 PM Nico Williams wrote:
> On Thu, Sep 19, 2019 at 08:06:26AM -100
On Thu, Sep 19, 2019 at 08:06:26AM -1000, Christian Huitema wrote:
> There is also a privacy angle. From a privacy point of view, it is
> very nice that PSK cannot be distinguished from session resumption.
This.
PSK is the right way to, for example, integrate Kerberos into TLS 1.3
now. But it's
There is also a privacy angle. From a privacy point of view, it is very nice
that PSK cannot be distinguished from session resumption.
-- Christian Huitema
> On Sep 19, 2019, at 5:57 AM, Richard Barnes wrote:
>
> As nice as that requirement would be, I'm not sure it's really compatible
> wit
As nice as that requirement would be, I'm not sure it's really compatible
with the way people want to build software. For example, OpenSSL right now
gets external PSKs by calling out to an external callback. Given that
degree of separation, proactively assuring no collisions would be hard.
On Th
Ah yes, Richard is right, the PSK IDs do not have a defined structure.
Having two different PSKs attached to a single PSK_ID should be banned if
it isn't already.
Regards,
Jonathan
On Thu, 19 Sep 2019 at 16:26, Richard Barnes wrote:
> On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland <
> jona
On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland <
jonathan.hoyl...@gmail.com> wrote:
> That's how I would interpret the spec yes.
> You could argue that there's a distinguishing attack where the attacker
> measures the response time on PSKs to determine if it was an OOB PSK or a
> resumption, bu
That's how I would interpret the spec yes.
You could argue that there's a distinguishing attack where the attacker
measures the response time on PSKs to determine if it was an OOB PSK or a
resumption, but I think you could do equally well just by looking at the
PSK lengths, because resumption PSKs
> -Original Message-
> From: Jonathan Hoyland
> Sent: 19 September 2019 14:32
> To: Owen Friel (ofriel)
> Cc: Martin Thomson ; tls@ietf.org
> Subject: Re: [TLS] Distinguishing between external/resumption PSKs
>
> Hi Owen,
>
> If I understand your question correctly the distinguishing
On Wed, Sep 18, 2019, at 4:31 PM, Martin Thomson wrote:
> On Thu, Sep 19, 2019, at 01:41, Christopher Wood wrote:
> > Ah, so, I think this is where the miscommunication is happening! The
> > target KDFs I've been envisioning are not protocol specific.
>
> As HKDF and the TLS 1.2 PRF are not the
Hi Owen,
If I understand your question correctly the distinguishing is done
implicitly (not explicitly) through the key schedule.
If the client and server do not agree on whether the PSK is a resumption or
an OOB PSK then the `binder_key` will not match, and the handshake will
fail.
See pp. 93-94
Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-sni-encryption-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refe
> -Original Message-
> From: TLS On Behalf Of Martin Thomson
> Sent: 04 September 2019 02:46
> To: tls@ietf.org
> Subject: Re: [TLS] Binder key labels for imported PSKs
>
>
> When we built the ext/res distinction, there was a clear problem expressed.
> We had the potential for both to
Hi Nick,
Thanks for your reply! Please see inline.
>>MIN_1:
>>The last sentence of Section 1 says that the mechanism requires TLS version
>>1.2
>>or later. Would it be useful to state that in a dedicated Applicability
>>section?
>
> I'm disinclined to include an applicability section considerin
19 matches
Mail list logo
