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