I'm not seeing a lot of enthusiasm for this option either. Do any of the people who were in favor of #1 or #2 want to say they prefer some variant of this proposal?
-Ekr On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla <e...@rtfm.com> 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. > > -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 <h...@ee.technion.ac.il> > 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 >> 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 <j...@salowey.net> 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&S >>> >>> >>> [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 >> >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls