Re: [TLS] Consensus call for keys used in handshake and data messages

[Ilari Liusvaara]

On Mon, Jun 20, 2016 at 11:43:41PM -0400, Dave Garrett wrote:
> 
> An idea for an option 4: Keep typing and keying as it currently is
> (as of draft 13), but mandate a KeyUpdate immediately following
> (and/or before) non-application traffic. We already have a mechanism
> to use different keys in series, which sounds like it might be
> simpler than trying to figure out a good way to do so in parallel.
>
> Is this a viable thought to pursue, or does this still not help
>enough with our key separation worries? An additional thought
> might be adding a random to KeyUpdate to make the new key not
> based entirely on the old entropy.

I don't think that would work. AFAIK, Basically using the appdata keys
for anything else (and you do in the idea) breaks generic security.

Of course, that generic security breaks does NOT imply that actual
protocol security breaks, since for that one must actually make the
actual protocol misuse the keys (and no reasonable way to do so is
known for draft-13).

And devising one seems very hard, since the operations you can try to
misuse (and all are outside normal message space) are:
- Rekey one direction of connection with a fresh key (key_update).
- Request a certificate, send a certificate and proof of key holding
  (certificate_request, certificate, certificate_verify, finished)
- Send a handle into separate dynamic PSK (new_session_ticket).

And none of those seems to lend itself to misusing the key (the
second has other known problems, but even fully separating the
keys would not fix that).


-Ilari

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Dave Garrett]

On Monday, June 20, 2016 08:39:11 pm Eric Rescorla wrote:
> Nobody seems super-excited about either Option 1 or Option 2, so it's
> at least worth noting that there's one of the options I claimed was
> rejected earlier, namely separately encrypting the content type in
> roughly the manner suggested by DKG, Ilari, and Kenny. Thanks for
> Doug/Felix for prompting me on this.
> 
> 
> NOTE: I don't promise any of the below is secure, though it probably
> can be made so with enough work. Actually doing so is an exercise
> for the reader.
> 
> 
> The basic idea is as follows:
> 
> 1. In each direction generate a separate "content_type_key"
> 2. Separately encrypt the content type from the rest of the record
>using the content_type_key.
> 3. On the receiving side, first decrypt the content type and then use
>that to determine what key to decrypt the record.
> 
> The trivial version of this is just to AEAD encrypt the content type
> separately, but this has unacceptable bandwidth and CPU properties, so
> is probably not viable. However, there are more efficient designs,
> which can get the overhead down to modest levels (<= 1 byte of
> expansion and <=1/16 of a block computation/record).
> 
> The obvious construction is to use the content_type_key to compute a
> per-record masking value (effectively an ad hoc stream cipher) and
> then use that to encrypt the content type (or potentially just a key
> type bit) without integrity (though you might later protect it in the
> additional data block under the main key). This gives you an
> encryption function without expansion. If you have a mask function
> which outputs one block at a time, you can use pieces of the block for
> each record (e.g., for record N you use byte N/16) [1]
> 
> 
> Obvious objections to this:
> 1. This isn't integrity protected. This is probably the most serious
> complaint and has the potential to actually leak information about
> the content type unless you're careful [2], even if you eventually
> integrity protect this information.
> 
> 2. It's odd to just use a piece of the AEAD cipher (the encryption
> function), especially if we ever had a really non-composite cipher.
> This can be alleviated by using HKDF-Expand to produce the stream
> of bits.
> 
> 3. Maybe it doesn't get the whole job done, especially wrt the fact
> that we're not rekeying the app data after client auth.
> 
> 4. It's gross. Yes, yes it is.
> 
> 
> I'm not really in love with this idea, but I did want people to know
> that maybe we don't *have* to choose between option 1 and option 2
> in case that changes people's opinions.

All this complexity for encrypting a single bit seems like way too much of a 
risk.

An idea for an option 4: Keep typing and keying as it currently is (as of draft 
13), but mandate a KeyUpdate immediately following (and/or before) 
non-application traffic. We already have a mechanism to use different keys in 
series, which sounds like it might be simpler than trying to figure out a good 
way to do so in parallel. Is this a viable thought to pursue, or does this 
still not help enough with our key separation worries? An additional thought 
might be adding a random to KeyUpdate to make the new key not based entirely on 
the old entropy.


Dave

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Colm MacCárthaigh]

On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla  wrote:
>
> 2. It's odd to just use a piece of the AEAD cipher (the encryption
> function), especially if we ever had a really non-composite cipher.
> This can be alleviated by using HKDF-Expand to produce the stream
> of bits.
>


If we're going to use a non-standard construction, would it make more sense
to "lose"
the authentication on the inner layer?

E.g.,

1. Encrypt the content type with the "outer" key,
2. Encrypt the with the "inner" key using the same explicit IV.
3. Concatenate the cipher-texts  of 1 and 2.
4. Compute an AAD tag/MAC across all of the data, using the "outer" key.

In that scheme the content type or "outer" key authenticates all of the
data, so you know it's tamper free. Still gross.


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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Eric Rescorla]

Nobody seems super-excited about either Option 1 or Option 2, so it's
at least worth noting that there's one of the options I claimed was
rejected earlier, namely separately encrypting the content type in
roughly the manner suggested by DKG, Ilari, and Kenny. Thanks for
Doug/Felix for prompting me on this.


NOTE: I don't promise any of the below is secure, though it probably
can be made so with enough work. Actually doing so is an exercise
for the reader.


The basic idea is as follows:

1. In each direction generate a separate "content_type_key"
2. Separately encrypt the content type from the rest of the record
   using the content_type_key.
3. On the receiving side, first decrypt the content type and then use
   that to determine what key to decrypt the record.

The trivial version of this is just to AEAD encrypt the content type
separately, but this has unacceptable bandwidth and CPU properties, so
is probably not viable. However, there are more efficient designs,
which can get the overhead down to modest levels (<= 1 byte of
expansion and <=1/16 of a block computation/record).

The obvious construction is to use the content_type_key to compute a
per-record masking value (effectively an ad hoc stream cipher) and
then use that to encrypt the content type (or potentially just a key
type bit) without integrity (though you might later protect it in the
additional data block under the main key). This gives you an
encryption function without expansion. If you have a mask function
which outputs one block at a time, you can use pieces of the block for
each record (e.g., for record N you use byte N/16) [1]


Obvious objections to this:
1. This isn't integrity protected. This is probably the most serious
complaint and has the potential to actually leak information about
the content type unless you're careful [2], even if you eventually
integrity protect this information.

2. It's odd to just use a piece of the AEAD cipher (the encryption
function), especially if we ever had a really non-composite cipher.
This can be alleviated by using HKDF-Expand to produce the stream
of bits.

3. Maybe it doesn't get the whole job done, especially wrt the fact
that we're not rekeying the app data after client auth.

4. It's gross. Yes, yes it is.


I'm not really in love with this idea, but I did want people to know
that maybe we don't *have* to choose between option 1 and option 2
in case that changes people's opinions.

-Ekr


[0] Note, I'm specifically not trying to protect length here. That
might be attractive, but my sense is that for the reasons Kenny
indicates it's harder to get right and I'm generally pretty skeptical
of length hiding in TLS given that we already have added padding.

[1] There are some subtleties about not breaking the record format.
If we don't care, then we can strip the first three bytes and then
steal a bit from the length to use for "key type" (the length will
never hage the high bit set). If we do care, then we could use the
key bit to toggle between "app data" and "handshake" in the dummy
record type byte.

[2] Naively, if you try encrypting the whole content type, some
transformations on the encrypted value will produce invalid types,
which leaks information if the receiver sends an alert.


On Fri, Jun 17, 2016 at 1:18 PM, Hugo Krawczyk 
wrote:

> I am abstaining on the choice of alternative 1 and 2 since I do not
> understand
> enough the engineering considerations and ramifications of the different
> choices. Also, I have not put any thought into the privacy issues related
> to
> hiding content type and I certainly did not do any formal analysis of these
> aspects.
>
> I do want to say that from a cryptographic design and analysis point of
> view,
> key separation is of great importance. It allows to have more modular
> analysis
> and design, and prove composability properties of protocols and
> applications.
> I believe it has significant practical advantages particularly with
> respect to
> "maintaining" a protocol, namely, making sure that changes and extensions
> to a
> protocol are secure and do not jeopardize its security. The more modular
> the
> design the easier it is to reason about changes and additions to the
> protocol
> (and for a protocol like TLS, future changes and adaptations to different
> settings are unavoidable).
>
> As for the specific cryptographic considerations in TLS 1.3, I would have
> "fought" greatly to preserve key separation at the level of the basic
> handshake
> protocol (three first flights). It guarantees that the application key is
> *fresh* at its first use for protecting application data. Freshness means
> that
> the key can serve any purpose for which a shared random secret key can be
> used.
> (In contrast, a non-fresh key, e.g. one used during the handshake itself,
> can
> only be used with applications that are aware of how exactly the key was
> used
> in the handshake.) Since my understanding is that the current
> 

Re: [TLS] Consensus call for keys used in handshake and data messages

[Hugo Krawczyk]

I am abstaining on the choice of alternative 1 and 2 since I do not
understand
enough the engineering considerations and ramifications of the different
choices. Also, I have not put any thought into the privacy issues related to
hiding content type and I certainly did not do any formal analysis of these
aspects.

I do want to say that from a cryptographic design and analysis point of
view,
key separation is of great importance. It allows to have more modular
analysis
and design, and prove composability properties of protocols and
applications.
I believe it has significant practical advantages particularly with respect
to
"maintaining" a protocol, namely, making sure that changes and extensions
to a
protocol are secure and do not jeopardize its security. The more modular the
design the easier it is to reason about changes and additions to the
protocol
(and for a protocol like TLS, future changes and adaptations to different
settings are unavoidable).

As for the specific cryptographic considerations in TLS 1.3, I would have
"fought" greatly to preserve key separation at the level of the basic
handshake
protocol (three first flights). It guarantees that the application key is
*fresh* at its first use for protecting application data. Freshness means
that
the key can serve any purpose for which a shared random secret key can be
used.
(In contrast, a non-fresh key, e.g. one used during the handshake itself,
can
only be used with applications that are aware of how exactly the key was
used
in the handshake.) Since my understanding is that the current base-handshake
specification does preserve the freshness of the application key, I am happy
with that design.

The issue of using the application key to protect post-handshake messages is
more involved. First, post-handshake client authentication authenticates ("a
posteriori") the application key but only after this key has already been
used.
In this sense this mechanism cannot possibly achieve key freshness for the
application key. The best one can hope for is that this post-authentication
authenticates the key without jeopardizing its use in the particular
application
it is intended for, namely, protecting TLS record layer data. Luckily, this
can
be proved. So now the question is whether using the application key to
encrypt
the very messages that provide post-handshake authentication (e.g., client's
signature) may lower the security of this key. The answer is that it does
not.
That is, the security of the key for protecting record layer data is not
jeopardized by using it to encrypt post-handshake messages.

I feel moderately confident about the above paragraph as I have been
working on
the analysis of client authentication, including (encrypted) post-handshake
authentication. On the other hand, I have not studied the effects of
encrypting
other post-handshake messages such as New Ticket or re-keying messages so I
don't have an "educated conclusion" here. I do expect that there are
analytical
advantages for not using the application key for encrypting these messages
but I
cannot say for sure.

In all, it is good and prudent practice (not just theory) to enforce key
separation wherever possible, and I would be happier if there was no
instance
where the application key is applied to non-application data. But I also
know
that one has to weigh other engineering considerations and in this case the
trade-off does not seem obvious to me. Hence, as said, I abstain.

Hugo


On Mon, Jun 13, 2016 at 3:00 PM, Joseph Salowey  wrote:

> For background please see [1].
>
> Please respond to this message indicating which of the following options
> you prefer by Monday June, 20, 2016
>
> 1. Use the same key for handshake and application traffic (as in the
> current draft-13)
>
> or
>
> 2. Restore a public content type and different keys
>
> Thanks,
>
> J
>
>
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg20241.html
>
> ___
> 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] Consensus call for keys used in handshake and data messages

[Martin Rex]

Daniel Kahn Gillmor wrote:
> On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote:
>> wasn't that rejected because it breaks boxes that do passive monitoring 
>> of connections? (and so expect TLS packets on specific ports, killing 
>> connection if they don't look like TLS packets)
> 
> We're talking about the possibility of changing the TLS record framing
> anyway, which would kill the simplest of those boxes.  One theory is if
> you're going to make such a break, you might as well pull the band aid
> off in one fell swoop.

While I dislike monitoring boxes and hate intercepting proxies,
changing of the TLS record framing (and hiding the ContentType)
is going to break _the_endpoints_.  If TLSv1.3 does that, its
adoption curve will make IPv6 adoption appear fast by comparison.

Please stop messing with the TLS record format.

-Martin

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Paterson, Kenny]

Hi Ilari,

On 14/06/2016 20:01, "TLS on behalf of Ilari Liusvaara"
 wrote:

>I too haven't seen an argument (or am I able to construct one
>myself) on why using the same key causes more issues than
>"more difficult for cryptographers" (without assumptions known
>to be false or cause severe problems no matter what).
>
>
>Such arguments could include e.g. crypto screw (no proof of
>exploitability needed), implementability, narrowing works-vs-
>correct gap, etc...
>
>
>About every other issue I could come up with, it seems to be just
>as bad with separate keys and public content types (except those
>ones that are just worse with public content types of course).
>

Since no-one else replied: it's a detailed technical issue about
constructing proofs of security. At a very high level, and at the risk of
over-simplifying, the more "key separation" you have, the easier it is to
get them to go through.

Maybe someone else who is more into the details than me can chime in with
the next-level explanation.

Cheers

Kenny 

>
>
>-Ilari
>
>___
>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] Consensus call for keys used in handshake and data messages

[Paterson, Kenny]

Hi Ilari,

On 15/06/2016 17:23, "TLS on behalf of Ilari Liusvaara"
 wrote:

>On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote:
>> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote:
>> 
>> To be clear, we're being asked to trade these things off against each
>> other here, but there are other options which were ruled out in the
>> prior framing of the question which don't rule either of them out.
>> 
>> In particular, if we're willing to pay the cost of a slightly more
>> complex key schedule (and an increased TLS record size), we could have
>> "packet header" keys which protect the content-type itself for all
>> non-cleartext TLS records.  If we do that, these keys might as well also
>> be used to protect the TLS record size itself.  This would result in an
>> opaque data stream (though obviously record size would still leak in
>> DTLS, and timing and framing is still likely to leak the record size in
>> the lowest-latency TLS applications).
>
>Does this need to enlarge TLS record size? Why doesn't encrypting the
>content-type/length and then authenticating those off main MAC work
>(that's how SSH with CHACHA20-POLY1305 does things)? I presume
>problems from header-flipping (tho in TLS that will kill the
>connection if you try...)

Yes, this can be made to work in the style adopted for ChaCha20-Poly1305
in SSH. 

However, because the record length is now determined by data that is
encrypted, and you need to know its value in order to "receive" enough
bytes to have obtained the record MAC which comes at the end of the
record, and because the record MAC can't now be checked before you make
use of the length field  you need to be a bit careful.

But it can be proved secure when using certain AEAD schemes as the basis,
and in a suitable security model that allows for decryption in part
depending on data that was acted on before it was unauthenticated and for
delivery of records in a fragmented fashion. Just don't use CBC mode for
the encryption :-)  (A more serious point: this kind of thing would not be
secure using a generic EtM-style AEAD scheme as the building block.)

In fact, if you're careful enough with the analysis, you can improve a bit
on the ChaCha20-Poly1305 construction in SSH: it currently uses a 64-byte
key, with 32 bytes being used to create one ChaCha20 context for
encrypting the length field and another 32 bytes being used to create a
second ChaCha20 context for encrypting the rest. This is not necessary if
you construct the ChaCha20 nonces/IVs in a slightly different way - a
single ChaCha20 context suffices. The same ought to be true in the
slightly different TLS setting, and also for an AES-GCM-based construction.

Happy to follow-up with discussion of more details if people seriously
want to consider this kind of construction for TLS 1.3. It's not what's
currently on the table, but maybe it should be...

Cheers

Kenny 

>
>Also, in DTLS, there could be issues switching the encryption on
>(but then, looks like DTLS 1.3 has other unsolved problems
>currently..)
>
>
>-Ilari
>
>
>___
>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] Consensus call for keys used in handshake and data messages

[Ilari Liusvaara]

On Thu, Jun 16, 2016 at 12:13:28PM -0400, Daniel Kahn Gillmor wrote:
> On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote:
> > wasn't that rejected because it breaks boxes that do passive monitoring 
> > of connections? (and so expect TLS packets on specific ports, killing 
> > connection if they don't look like TLS packets)
> 
> We're talking about the possibility of changing the TLS record framing
> anyway, which would kill the simplest of those boxes.  One theory is if
> you're going to make such a break, you might as well pull the band aid
> off in one fell swoop.

One scheme with minimum overhead (3 bytes + crypto tag + padding) to that
doesn't do record hiding, is not compatible with multiple keys nor SRTP
mux:

- Bit 7 of first byte:
  0 => normal TLS 1.0-style 5 byte header.
  1 => 2 bytes, low 15 bits are length of encrypted record.

And then do draft-13-style padding inside encrypted envelope.


If one wants to do record hiding and MAC the headers, one would
presumably want 64-bit tags due to space usage. Unfortunately, algebraic
MACs tend to be rather weak at 64-bits (forgeries tend to give up lots
of information about the key) and non-algebraic ones (based on hashes)
tend to be a bit slow.


-Ilari

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Daniel Kahn Gillmor]

On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote:
> wasn't that rejected because it breaks boxes that do passive monitoring 
> of connections? (and so expect TLS packets on specific ports, killing 
> connection if they don't look like TLS packets)

We're talking about the possibility of changing the TLS record framing
anyway, which would kill the simplest of those boxes.  One theory is if
you're going to make such a break, you might as well pull the band aid
off in one fell swoop.

--dkg

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Hubert Kario]

On Wednesday 15 June 2016 09:44:18 Daniel Kahn Gillmor wrote:
> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote:
> > I disagree that this is a low level crypto decision, or at least
> > that this is mainly so.
> > 
> > There is the question of whether using the same key for application
> > data and handshake is harmful. That question is mainly low level
> > crypto and could be asked of CFRG.
> > 
> > There is the other question of whether exposing the fact that there
> > are handshake messages and when they occur is harmful. That is
> > security-related, but not at all related to crypto.
> > 
> > Weighing these two potential harms against each other and coming to
> > a decision is entirely an engineering issue, and we should not
> > offload that to CFRG.
> To be clear, we're being asked to trade these things off against each
> other here, but there are other options which were ruled out in the
> prior framing of the question which don't rule either of them out.
> 
> In particular, if we're willing to pay the cost of a slightly more
> complex key schedule (and an increased TLS record size), we could have
> "packet header" keys which protect the content-type itself for all
> non-cleartext TLS records.  If we do that, these keys might as well
> also be used to protect the TLS record size itself.  This would
> result in an opaque data stream (though obviously record size would
> still leak in DTLS, and timing and framing is still likely to leak
> the record size in the lowest-latency TLS applications).

wasn't that rejected because it breaks boxes that do passive monitoring 
of connections? (and so expect TLS packets on specific ports, killing 
connection if they don't look like TLS packets)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call for keys used in handshake and data messages

[Daniel Kahn Gillmor]

On Wed 2016-06-15 12:23:38 -0400, Ilari Liusvaara wrote:
> On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote:
>> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote:
>> 
>> To be clear, we're being asked to trade these things off against each
>> other here, but there are other options which were ruled out in the
>> prior framing of the question which don't rule either of them out.
>> 
>> In particular, if we're willing to pay the cost of a slightly more
>> complex key schedule (and an increased TLS record size), we could have
>> "packet header" keys which protect the content-type itself for all
>> non-cleartext TLS records.  If we do that, these keys might as well also
>> be used to protect the TLS record size itself.  This would result in an
>> opaque data stream (though obviously record size would still leak in
>> DTLS, and timing and framing is still likely to leak the record size in
>> the lowest-latency TLS applications).
>
> Does this need to enlarge TLS record size? Why doesn't encrypting the
> content-type/length and then authenticating those off main MAC work

maybe i'm not understanding your proposal, but if we're encrypting the
record length as well, how do you find (and validate) the main MAC
without knowing the record length?

> I presume problems from header-flipping (tho in TLS that will kill the
> connection if you try...)

I'm not sure what header-flipping is...

> Also, in DTLS, there could be issues switching the encryption on
> (but then, looks like DTLS 1.3 has other unsolved problems
> currently..)

yes, i think that might be the case.

 --dkg

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Nick Sullivan]

I prefer (1)

On Wed, Jun 15, 2016 at 5:51 PM Dan Harkins  wrote:

>
>   Hello,
>
> On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote:
> > For background please see [1].
> >
> > Please respond to this message indicating which of the following options
> > you prefer by Monday June, 20, 2016
> >
> > 1. Use the same key for handshake and application traffic (as in the
> > current draft-13)
> >
> > or
> >
> > 2. Restore a public content type and different keys
>
>   I prefer (1).
>
>   Dan.
>
>
> ___
> 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] Consensus call for keys used in handshake and data messages

[Dan Harkins]

  Hello,

On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote:
> For background please see [1].
>
> Please respond to this message indicating which of the following options
> you prefer by Monday June, 20, 2016
>
> 1. Use the same key for handshake and application traffic (as in the
> current draft-13)
>
> or
>
> 2. Restore a public content type and different keys

  I prefer (1).

  Dan.


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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Ilari Liusvaara]

On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote:
> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote:
> 
> To be clear, we're being asked to trade these things off against each
> other here, but there are other options which were ruled out in the
> prior framing of the question which don't rule either of them out.
> 
> In particular, if we're willing to pay the cost of a slightly more
> complex key schedule (and an increased TLS record size), we could have
> "packet header" keys which protect the content-type itself for all
> non-cleartext TLS records.  If we do that, these keys might as well also
> be used to protect the TLS record size itself.  This would result in an
> opaque data stream (though obviously record size would still leak in
> DTLS, and timing and framing is still likely to leak the record size in
> the lowest-latency TLS applications).

Does this need to enlarge TLS record size? Why doesn't encrypting the
content-type/length and then authenticating those off main MAC work
(that's how SSH with CHACHA20-POLY1305 does things)? I presume
problems from header-flipping (tho in TLS that will kill the
connection if you try...)

Also, in DTLS, there could be issues switching the encryption on
(but then, looks like DTLS 1.3 has other unsolved problems
currently..)


-Ilari


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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Yoav Nir]

Hi, Nikos

> On 15 Jun 2016, at 11:00 AM, Nikos Mavrogiannopoulos  wrote:
> 
> On Mon, 2016-06-13 at 12:00 -0700, Joseph Salowey wrote:
>> For background please see [1].
>> 
>> Please respond to this message indicating which of the following
>> options you prefer by Monday June, 20, 2016 
>> 
>> 1. Use the same key for handshake and application traffic (as in the
>> current draft-13)
>> 
>> or
>> 
>> 2. Restore a public content type and different keys
> 
> Unless participants are really expert on what is the issue is and how
> these proofs are constructed, I doubt that people in the TLS WG can
> resolve that in a way that provides assurance. There are good arguments
> presented in the thread by few cryptographers, but since this is mainly
> a low level crypto decision, why not ask the CFRG instead?

I disagree that this is a low level crypto decision, or at least that this is 
mainly so. 

There is the question of whether using the same key for application data and 
handshake is harmful. That question is mainly low level crypto and could be 
asked of CFRG.

There is the other question of whether exposing the fact that there are 
handshake messages and when they occur is harmful. That is security-related, 
but not at all related to crypto.

Weighing these two potential harms against each other and coming to a decision 
is entirely an engineering issue, and we should not offload that to CFRG.

Yoav

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Subodh Iyengar]

With option (2) would the keys end up being independent anyway? I think we 
might need to share the sequence number space between the handshake messages 
and the application data messages to avoid truncation attacks. I might have 
missed this, but was there a proposal to deal with sequence numbers for option 
(2). 

I prefer option (1) since it actually offers some privacy guarantees. 

Subodh

From: TLS [tls-boun...@ietf.org] on behalf of Björn Tackmann 
[btackm...@eng.ucsd.edu]
Sent: Tuesday, June 14, 2016 1:45 PM
To: tls@ietf.org
Subject: Re: [TLS] Consensus call for keys used in handshake and data   messages

Just to be clear: the "+1" I sent earlier meant "I agree with Karthik" -- so it 
means solution (2).

> On Jun 14, 2016, at 1:18 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
>
> Key reuse often ends up causing problems. IMHO a more sound approach is (2). 
> IMHO it isn't prohibitively expensive either.
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
>   Original Message
> From: Björn Tackmann
> Sent: Tuesday, June 14, 2016 05:23
> To: tls@ietf.org
> Subject: Re: [TLS] Consensus call for keys used in handshake and data
> messages
>
> +1
>
>
>> On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan 
>>  wrote:
>>
>> I prefer (2)
>>
>>> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor  
>>> wrote:
>>>
>>> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
 1. Use the same key for handshake and application traffic (as in the
 current draft-13)

 or

 2. Restore a public content type and different keys
>>>
>>> Given this choice, i prefer (1).
>>>
>>> --dkg
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=CwIGaQ=5VD0RTtNlTh3ycd41b3MUw=h3Ju9EBS7mHtwg-wAyN7fQ=51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc=wAkXyaR6H8OBIwkPYvnVJClJb5pdbQKYE9gf6wApqB4=
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=CwIGaQ=5VD0RTtNlTh3ycd41b3MUw=h3Ju9EBS7mHtwg-wAyN7fQ=51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc=wAkXyaR6H8OBIwkPYvnVJClJb5pdbQKYE9gf6wApqB4=
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=CwIGaQ=5VD0RTtNlTh3ycd41b3MUw=h3Ju9EBS7mHtwg-wAyN7fQ=51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc=wAkXyaR6H8OBIwkPYvnVJClJb5pdbQKYE9gf6wApqB4=
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=CwIGaQ=5VD0RTtNlTh3ycd41b3MUw=h3Ju9EBS7mHtwg-wAyN7fQ=51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc=wAkXyaR6H8OBIwkPYvnVJClJb5pdbQKYE9gf6wApqB4=

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=CwIGaQ=5VD0RTtNlTh3ycd41b3MUw=h3Ju9EBS7mHtwg-wAyN7fQ=51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc=wAkXyaR6H8OBIwkPYvnVJClJb5pdbQKYE9gf6wApqB4=

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Björn Tackmann]

Just to be clear: the "+1" I sent earlier meant "I agree with Karthik" -- so it 
means solution (2).

> On Jun 14, 2016, at 1:18 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> Key reuse often ends up causing problems. IMHO a more sound approach is (2). 
> IMHO it isn't prohibitively expensive either.
> 
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
>   Original Message  
> From: Björn Tackmann
> Sent: Tuesday, June 14, 2016 05:23
> To: tls@ietf.org
> Subject: Re: [TLS] Consensus call for keys used in handshake and data
> messages
> 
> +1
> 
> 
>> On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan 
>>  wrote:
>> 
>> I prefer (2)
>> 
>>> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor  
>>> wrote:
>>> 
>>> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
 1. Use the same key for handshake and application traffic (as in the
 current draft-13)
 
 or
 
 2. Restore a public content type and different keys
>>> 
>>> Given this choice, i prefer (1).
>>> 
>>> --dkg
>>> 
>>> ___
>>> 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 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call for keys used in handshake and data messages

[Will Serumgard]

+2

Will Serumgard


> On Jun 14, 2016, at 4:22 AM, Watson Ladd  wrote:
> 
> 
> On Jun 13, 2016 10:08 PM, "Karthikeyan Bhargavan" 
>  wrote:
> >
> > I prefer (2)
> 
> Same. It's clear 1 makes proofs more complicated, making mistakes easier to 
> miss.
> 
> >
> > > On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor  
> > > wrote:
> > >
> > > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
> > >> 1. Use the same key for handshake and application traffic (as in the
> > >> current draft-13)
> > >>
> > >> or
> > >>
> > >> 2. Restore a public content type and different keys
> > >
> > > Given this choice, i prefer (1).
> > >
> > >  --dkg
> > >
> > > ___
> > > 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 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] Consensus call for keys used in handshake and data messages

[Benjamin Dowling]

I am in favour of option (2).

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Ilari Liusvaara]

On Tue, Jun 14, 2016 at 11:33:11AM +0300, Yoav Nir wrote:
> 
> 
> (1)

+1
 
> One important (for me) use case for handshake messages after the
> original handshake is client certificate authentication. Disclosing
> that the user has just touched the magic resource that causes
> certificate authentication reveals actual information about what
> the user is doing. I haven’t seen an argument about why using the
> same key is similarly harmful.

I too haven't seen an argument (or am I able to construct one
myself) on why using the same key causes more issues than
"more difficult for cryptographers" (without assumptions known
to be false or cause severe problems no matter what).


Such arguments could include e.g. crypto screw (no proof of
exploitability needed), implementability, narrowing works-vs-
correct gap, etc...


About every other issue I could come up with, it seems to be just
as bad with separate keys and public content types (except those
ones that are just worse with public content types of course).



-Ilari

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Felix Günther]

I also prefer (2).

Cheers,
Felix

On 14/06/2016 14:45 +0200, Cas Cremers wrote:
> It is not quite as simple as saying "(1) makes proofs more complicated"
> since it depends on what you are trying to prove.
> 
> (1) makes some styles of standard AKE property proofs (key secrecy,
> authentication) harder
> (2) might make some privacy proofs harder
> 
> Given that the proof-effort has mostly focused on secrecy and
> authentication properties, one can argue for (2).
> However, some proof styles can still work out in (1), so it is not such
> a clear choice.
> 
> Over time, I've changed my mind, and I now prefer (2) (since we don't
> have full detail on any privacy proofs) as long as the content-type
> essentially boils down to a single bit of information (which key we are
> using) and nothing else.
> 
> FWIW,
> 
> Cas
> 
> 
> On Tue, Jun 14, 2016 at 1:12 PM, Hannes Mehnert  > wrote:
> 
> On 13/06/2016 21:27, Daniel Kahn Gillmor wrote:
> > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
> >> 1. Use the same key for handshake and application traffic (as in the
> >> current draft-13)
> >>
> >  > or
> >>
> >> 2. Restore a public content type and different keys
> >
> > Given this choice, i prefer (1).
> 
> FWIW, I prefer (1) as well
> 
> 
> hannes
> 
> ___
> 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
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call for keys used in handshake and data messages

[Cas Cremers]

It is not quite as simple as saying "(1) makes proofs more complicated"
since it depends on what you are trying to prove.

(1) makes some styles of standard AKE property proofs (key secrecy,
authentication) harder
(2) might make some privacy proofs harder

Given that the proof-effort has mostly focused on secrecy and
authentication properties, one can argue for (2).
However, some proof styles can still work out in (1), so it is not such a
clear choice.

Over time, I've changed my mind, and I now prefer (2) (since we don't have
full detail on any privacy proofs) as long as the content-type essentially
boils down to a single bit of information (which key we are using) and
nothing else.

FWIW,

Cas


On Tue, Jun 14, 2016 at 1:12 PM, Hannes Mehnert  wrote:

> On 13/06/2016 21:27, Daniel Kahn Gillmor wrote:
> > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
> >> 1. Use the same key for handshake and application traffic (as in the
> >> current draft-13)
> >>
> >  > or
> >>
> >> 2. Restore a public content type and different keys
> >
> > Given this choice, i prefer (1).
>
> FWIW, I prefer (1) as well
>
>
> hannes
>
> ___
> 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] Consensus call for keys used in handshake and data messages

[Blumenthal, Uri - 0553 - MITLL]

Key reuse often ends up causing problems. IMHO a more sound approach is (2). 
IMHO it isn't prohibitively expensive either.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Björn Tackmann
Sent: Tuesday, June 14, 2016 05:23
To: tls@ietf.org
Subject: Re: [TLS] Consensus call for keys used in handshake and data   messages

+1


> On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan 
>  wrote:
> 
> I prefer (2)
> 
>> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor  wrote:
>> 
>> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
>>> 1. Use the same key for handshake and application traffic (as in the
>>> current draft-13)
>>> 
>>> or
>>> 
>>> 2. Restore a public content type and different keys
>> 
>> Given this choice, i prefer (1).
>> 
>> --dkg
>> 
>> ___
>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call for keys used in handshake and data messages

[Björn Tackmann]

+1


> On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan 
>  wrote:
> 
> I prefer (2)
> 
>> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor  wrote:
>> 
>> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
>>> 1. Use the same key for handshake and application traffic (as in the
>>> current draft-13)
>>> 
>>> or
>>> 
>>> 2. Restore a public content type and different keys
>> 
>> Given this choice, i prefer (1).
>> 
>> --dkg
>> 
>> ___
>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call for keys used in handshake and data messages

[Martin Thomson]

On 13 June 2016 at 21:27, Daniel Kahn Gillmor  wrote:
> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
>> 1. Use the same key for handshake and application traffic (as in the
>> current draft-13)
>>
>  > or
>>
>> 2. Restore a public content type and different keys
>
> Given this choice, i prefer (1).

+1

However...

I confess that I still haven't properly internalized the objection
from the cryptographers, and that means that I could probably live
with a public content type if more convincing evidence for the value
of 2 could be produced.

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Yoav Nir]

> On 13 Jun 2016, at 10:00 PM, Joseph Salowey  wrote:
> 
> For background please see [1].
> 
> Please respond to this message indicating which of the following options you 
> prefer by Monday June, 20, 2016 
> 
> 1. Use the same key for handshake and application traffic (as in the current 
> draft-13)
> 
> or
> 
> 2. Restore a public content type and different keys
> 
> Thanks,
> 
> J

(1)

One important (for me) use case for handshake messages after the original 
handshake is client certificate authentication. Disclosing that the user has 
just touched the magic resource that causes certificate authentication reveals 
actual information about what the user is doing. I haven’t seen an argument 
about why using the same key is similarly harmful.

Yoav


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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Andrei Popov]

I prefer option 1.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Joseph Salowey
Sent: Monday, June 13, 2016 12:00 PM
To: tls@ietf.org
Subject: [TLS] Consensus call for keys used in handshake and data messages

For background please see [1].

Please respond to this message indicating which of the following options you 
prefer by Monday June, 20, 2016

1. Use the same key for handshake and application traffic (as in the current 
draft-13)

or

2. Restore a public content type and different keys

Thanks,

J


[1] https://www.ietf.org/mail-archive/web/tls/current/msg20241.html
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call for keys used in handshake and data messages

[Karthikeyan Bhargavan]

I prefer (2)

> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor  wrote:
> 
> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
>> 1. Use the same key for handshake and application traffic (as in the
>> current draft-13)
>> 
>> or
>> 
>> 2. Restore a public content type and different keys
> 
> Given this choice, i prefer (1).
> 
>  --dkg
> 
> ___
> 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] Consensus call for keys used in handshake and data messages

[Eric Rescorla]

+1

On Mon, Jun 13, 2016 at 9:27 PM, Daniel Kahn Gillmor 
wrote:

> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
> > 1. Use the same key for handshake and application traffic (as in the
> > current draft-13)
> >
>  > or
> >
> > 2. Restore a public content type and different keys
>
> Given this choice, i prefer (1).
>
>   --dkg
>
> ___
> 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