Re: [TLS] Adding an additional step to exporters

[Martin Thomson]

On 24 February 2017 at 16:01, Sean Turner  wrote:
> So this isn’t entirely novel right I mean we did something similar wrt other 
> key schedules?

I certainly hope it isn't novel.  I'm just applying the same
technique: keep independent keys independent.

On 24 February 2017 at 16:09, Felix Günther  wrote:
> just to clarify: you add an additional HKDF.Expand step, not
> HKDF.Extract, right?

Yes, you are right, I should have said expand.  You need to use expand
to get the label-based separation on type.

I don't know how I got confused about that.  If we need to maintain
extract and expand in pairs (as we have already been burned by), then
I will defer to cryptographers on that.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

[Joseph Salowey]

The difference between what is defined in 1.3 and this document is the 256
bit CCM cipher suites.   The document does not specify cipher suites for
TLS 1.3.

Is it important for TLS 1.3 to have support for these cipher suites?

If it is then we either need to add the cipher suites to this document or
to TLS 1.3.  At this point I would like to minimize the changes to 1.3,  so
I'm advocating that if the AES-256-CCM ciphers are necessary we update the
current document instead of TLS 1.3.  If the cipher suites are not
important then we should remove them from the document.

There is also confusion on what hash function to use with AES-256-CCM (it
seems it should be SHA384).



On Wed, Feb 22, 2017 at 9:11 AM, Ilari Liusvaara 
wrote:

> On Wed, Feb 22, 2017 at 08:04:13AM +, Salz, Rich wrote:
> > Why not just say
> >   The CCM cipher suites are not (currently) defined for TLS 1.3
> >
> > And leave it at that.  We're all quite proud of the fact, and
> > deservedly so, that we only have three ciphers defined for TLS 1.3.
> > Let's try to hold that position as long as possible.
>
> Well, AES-128-CCM with 8 and 16 byte tags does exist in editor's
> copy (0x1304 and 0x1305).
>
> No AES-256-CCM tho.
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adding an additional step to exporters

[Felix Günther]

Hi Martin,

just to clarify: you add an additional HKDF.Expand step, not
HKDF.Extract, right?

You mentioned extract in the email and PR text, but in code it's a
second expand---which makes sense, as only expand allows to add context
(here: label).

Cheers,
Felix

On 23/02/2017 20:30 -0800, Martin Thomson wrote:
> https://github.com/tlswg/tls13-spec/pull/882 contains the longer description.
> 
> In short, the existence of an exporter secret threatens the forward
> secrecy of any exported secret.  This is a problem for QUIC and is
> likely to be a more general problem.
> 
> The proposed fix is small: separate exporters into two steps
> (extract+expand) where the first step allows for separation based on
> exporter type and the second on context.  That allows an endpoint to
> keep separate secrets for each exporter type and discard those that it
> no longer needs, thus gaining forward secrecy if it likes.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adding an additional step to exporters

[Sean Turner]

So this isn’t entirely novel right I mean we did something similar wrt other 
key schedules?

spt

> On Feb 23, 2017, at 23:30, Martin Thomson  wrote:
> 
> https://github.com/tlswg/tls13-spec/pull/882 contains the longer description.
> 
> In short, the existence of an exporter secret threatens the forward
> secrecy of any exported secret.  This is a problem for QUIC and is
> likely to be a more general problem.
> 
> The proposed fix is small: separate exporters into two steps
> (extract+expand) where the first step allows for separation based on
> exporter type and the second on context.  That allows an endpoint to
> keep separate secrets for each exporter type and discard those that it
> no longer needs, thus gaining forward secrecy if it likes.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Adding an additional step to exporters

[Martin Thomson]

https://github.com/tlswg/tls13-spec/pull/882 contains the longer description.

In short, the existence of an exporter secret threatens the forward
secrecy of any exported secret.  This is a problem for QUIC and is
likely to be a more general problem.

The proposed fix is small: separate exporters into two steps
(extract+expand) where the first step allows for separation based on
exporter type and the second on context.  That allows an endpoint to
keep separate secrets for each exporter type and discard those that it
no longer needs, thus gaining forward secrecy if it likes.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] (no subject)

[Eric Rescorla]

On Thu, Feb 23, 2017 at 8:08 AM, Dr Stephen Henson <
li...@drh-consultancy.co.uk> wrote:

> On 09/02/2017 21:17, Eric Rescorla wrote:
> > Hi folks,
> >
> > We need to close on an issue about the size of the
> > state in the HelloRetryRequest. Because we continue the transcript
> > after HRR, if you want a stateless HRR the server needs to incorporate
> > the hash state into the cookie. However, this has two issues:
> >
> > 1. The "API" for conventional hashes isn't designed to be checkpointed
> >at arbitrary points (though PKCS#11 at least does have support
> >for this.)
> > 2. The state is bigger than you would like b/c you need to store both
> >the compression function and the "remainder" of bytes that don't
> >fit in [0]
> >
>
> Does the handling of Post-Handshake authentication pose a similar issue?
> That is
> the need to keep the hash context of the handshake and then append
> additional
> data to generate or check the CertificateVerify message?
>

It's a slight inconvenience, but not a real issue because you don't need to
send the state over the wire. So you just need a forkable hash
implementation, which you needed anyway because of the way the rest of the
hashing works.

-Ekr


> Steve.
> --
> Dr Stephen N. Henson.
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Freelance consultant see: http://www.drh-consultancy.co.uk/
> Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] (no subject)

[Dr Stephen Henson]

On 09/02/2017 21:17, Eric Rescorla wrote:
> Hi folks,
> 
> We need to close on an issue about the size of the
> state in the HelloRetryRequest. Because we continue the transcript
> after HRR, if you want a stateless HRR the server needs to incorporate
> the hash state into the cookie. However, this has two issues:
> 
> 1. The "API" for conventional hashes isn't designed to be checkpointed
>at arbitrary points (though PKCS#11 at least does have support
>for this.)
> 2. The state is bigger than you would like b/c you need to store both
>the compression function and the "remainder" of bytes that don't
>fit in [0]
> 

Does the handling of Post-Handshake authentication pose a similar issue? That is
the need to keep the hash context of the handshake and then append additional
data to generate or check the CertificateVerify message?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls