Re: [TLS] Data volume limits
On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote: > So we have to trade off the risks of too much data vs. the risks > of a complex rekey protocol vs. the risks having the big data > applications build new connections every 2**36 or so bytes. > > If we don't have rekeying, then the big data applications are > the only ones at risk. If we do, it may be a wedge which can > compromise all users. if the rekey doesn't allow the application to change authentication tokens (as it now stands), then rekey is much more secure than renegotiation was in TLS <= 1.2 so if we include rekeying in TLS, I'd suggest to set its limit to something fairly low for dig data transfers, that is gigabytes, not terabytes, otherwise we'll be introducing code that is simply not tested for interoperability (with AES-NI you can easily transfer gigabytes in just few minutes) -- 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] AD review of /draft-ietf-tls-cached-info-20
Hi Stephen, thanks for your review comments. On 11/20/2015 03:16 PM, Stephen Farrell wrote: > > Hiya, > > I've requested IETF LC for this one. (Sorry for being slow > getting to it.) Please treat my comments below along with > any other last call comments. > > - You probably thought about this but I forget the argument. > Wouldn't it have been better to include the cached info that is not > sent within the transcript? I can't see an attack myself, but then > we didn't get the triple-handshake problem even after the initial > double-handshake attack was known. You are actually describing the problem we were having: We had both versions throughout the history of the document. There is this feeling that there could be an attack (somehow) but nobody knows how it works and so it is hard to decide for one or the other approach. > - ID nits complains that 6234 has obsoleted 4634, and indeed so it > has:-) I'll note that in the LC announce. Ok. > > - 2^16-1 CachedObject instances makes no sense at all, that would be > bigger than the full handshake. Why not pick a sensible value? Even > if you don't put such a value in the syntax, you could at least say > that e.g. N instances will likely be pointless, for whatever N > (10-ish?) would make the h/w bigger overall. That's indeed a bit large. I reduced it to 1..2^8-1. > > - page 6: wrt 7250 do you need to say that the server can tell which > thing (cert or SPKI) the client has cached from the hash value? I > think it can only work that way, but it might be worth saying that. > If it works some other way, then I didn't get that, so probably some > other bit of text would be needed. I added a note. I do indeed assume that the server is able to select the right certificate/SPKI from the received hash value. > - typo: consideratios Ok. Ciao Hannes > > Cheers, > S. > > ___ > 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] PRF digest function for ChaCha20-Poly1305 cipher suites
Eric Rescorla wrote: > Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 uses HKDF. > Are you suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512 and that > TLS 1.2 use SHA-512 with HKDF, or something different? > I mean that TLS 1.2 should use SHA-512 with the TLS 1.2 PRF and that TLS 1.3 should use SHA-512 with HKDF. > Nobody should pay attention to what the MTI cipher suite for TLS 1.2 is, >> because it's obsolete; in fact, one would be making a huge mistake to >> deploy it now if one's application didn't have legacy backward >> compatibility concerns. And, we should change the MTI cipher suite for TLS >> 1.3 to the ChaCha20-Poly1305 ones, because they solve a lot of problems. >> For example, they remove any question of any need to implement rekeying, >> they avoid the weird IV construction hacks that are necessary for 128-bit >> cipher suites like AES-GCM, and they can be implemented efficiently in a >> safe way, unlike AES-GCM. >> > > This seems like a separate question. > You are the one that brought the MTI stuff into this, not me. > SHA-256-using cipher suites are widely deployed and not going away any > time soon, so what resource are you trying to conserve here? > I'm trying to minimize the number of algorithms (amount of code) necessary to implement ChaCha20-Poly1305 using x25519 for key agreement and Ed25519 for signatures. The different between needing or not needing SHA-256 matters most for very small computers (AVR and Cortex-M0), but doesn't really matter much for larger computers where SHA-256 has an advantage. In particular, since there seems to be a notable amount of hardware that is or will soon be released that optimized for ChaCha20-Poly1305+x25519+Ed25519, because of Apple HomeKit, it would be nice to take advantage of that for TLS. Besides that, the inconsistency regarding why these new 256-bit-encryption-key cipher suites are currently defined to use SHA-256 in the PRF whereas all the existing 256-bit-encryption-key cipher suites use SHA-384 seems strange. Even if an application wants to use AES-GCM cipher suites, it would be able to avoid needing SHA-256 if it implemented the AES256-GCM cipher suites instead of AES128-GCM. Cheers, Brian -- https://briansmith.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] What does it mean to not include 0-RTT message in the handshake hash?
The handshake hash specification in section 7.1 says: Where handshake_hash includes all messages up through the server CertificateVerify message, but not including any 0-RTT handshake messages (the server's Finished is not included because the master_secret is need to compute the finished key). What are the 0-RTT handshake messages that should be excluded? The diagram in 6.2.2 shows the client hello and its extensions, the optional client cert and client cert verify, and a finished message. Presumably, the handshake hash does not exclude the client hello. What is the intent there? Is the sentence meant to exclude the 0-RTT cert, cert verify and finished messages? -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
On Mon, Dec 21, 2015 at 5:49 PM, Christian Huitema wrote: > The handshake hash specification in section 7.1 says: > You're referring the editor's copy (WIP-11), right? > Where handshake_hash includes all messages up through the > server CertificateVerify message, but not including any > 0-RTT handshake messages (the server's Finished is not > included because the master_secret is need to compute > the finished key). > > What are the 0-RTT handshake messages that should be excluded? The diagram > in 6.2.2 shows the client hello and its extensions, the optional client > cert and client cert verify, and a finished message. Presumably, the > handshake hash does not exclude the client hello. What is the intent there? > Is the sentence meant to exclude the 0-RTT cert, cert verify and finished > messages? > I was just going over this text today and realized it's kind of confusing (and the whole "handshake_hash" abstraction is starting to be less useful in light of the PR#316 reframing of the authentication block). Unless I'm confused (which is possible given the time of night), the intention, as you say, is to separate out the 0-RTT handshake messages i.e., (cert, cert verify, finished) from the 1-RTT computations. However, as indicated in S 6.3.3. and 6.3.4: - The 0-RTT Certificate Verify covers the ClientHello and Certificate (as well as the cached messages from the server shown in the table in 6.3.4) - The 0-RTT Finished includes the above messages plus the CertificateVerify. Trying to figure out the best way to clarify this text. PRs welcome :) -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
> You're referring the editor's copy (WIP-11), right? Yes. ... > I was just going over this text today and realized it's kind of confusing > (and the whole "handshake_hash" abstraction is starting to be less useful > in light of the PR#316 reframing of the authentication block). Yes, the "handshake hash" is indeed confusing. Specifying something like "all messages up to " is simple enough. But there are several such points, used at different stages. Server Hello, Server certificate verify, Server Finished, Client certificate verify, Client finished.. It would be a bit more clear to give each of them its own name. > Unless I'm confused (which is possible given the time of night), > the intention, as you say, is to separate out the 0-RTT handshake > messages i.e., (cert, cert verify, finished) from the 1-RTT computations. OK. That does not simplify implementations using running hashes... > Trying to figure out the best way to clarify this text. PRs welcome :) Yes of course... -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
On 22 December 2015 at 13:25, Christian Huitema wrote: >> Unless I'm confused (which is possible given the time of night), >> the intention, as you say, is to separate out the 0-RTT handshake >> messages i.e., (cert, cert verify, finished) from the 1-RTT computations. > > OK. That does not simplify implementations using running hashes... It does if you consider the possibility of having to drop the 0-RTT data. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
On Monday, December 21, 2015 09:25:44 pm Christian Huitema wrote: > > I was just going over this text today and realized it's kind of confusing > > (and the whole "handshake_hash" abstraction is starting to be less useful > > in light of the PR#316 reframing of the authentication block). > > Yes, the "handshake hash" is indeed confusing. Specifying something like "all > messages up to " is simple enough. But there are several such > points, used at different stages. Server Hello, Server certificate verify, > Server Finished, Client certificate verify, Client finished.. It would be a > bit more clear to give each of them its own name. Along this same line, I'd suggest getting rid of "session_hash", at least as-is. Instead, just use "handshake_hash" for everything and specify what's included at each use. "Session hash" is just another term that has to be referenced, when it's just the final state of the handshake hash. The term doesn't really add anything unless every separate stage of the handshake hash was named separately (in which case, "handshake_hash_*" naming might be more clear) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
On Mon, Dec 21, 2015 at 6:33 PM, Dave Garrett wrote: > On Monday, December 21, 2015 09:25:44 pm Christian Huitema wrote: > > > I was just going over this text today and realized it's kind of > confusing > > > (and the whole "handshake_hash" abstraction is starting to be less > useful > > > in light of the PR#316 reframing of the authentication block). > > > > Yes, the "handshake hash" is indeed confusing. Specifying something like > "all messages up to " is simple enough. But there are several > such points, used at different stages. Server Hello, Server certificate > verify, Server Finished, Client certificate verify, Client finished.. It > would be a bit more clear to give each of them its own name. > > Along this same line, I'd suggest getting rid of "session_hash", at least > as-is. Instead, just use "handshake_hash" for everything and specify what's > included at each use. "Session hash" is just another term that has to be > referenced, when it's just the final state of the handshake hash. I tend to agree > The term doesn't really add anything unless every separate stage of the > handshake hash was named separately (in which case, "handshake_hash_*" > naming might be more clear) Yeah, that might work. I'm putting the final touches on draft-11 and will see what I can do to clarify this. Thanks -Ekr > > > Dave > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
