Re: [TLS] Constant-time Algorithms
Also, is it necessary for a TLS client to care about implementing algorithms in constant time, or is this only of concern to servers? Thanks, Mike On 5/14/21 14:56, Michael D'Errico wrote: Hi, Is there a list somewhere stating which parts of TLS require constant-time algorithms? Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Constant-time Algorithms
Hi, Is there a list somewhere stating which parts of TLS require constant-time algorithms? Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS WG GitHub interaction
Hi,
I used to be very active in the development of TLS
specifications (version 1.2) and some of the extensions.
At the time, all discussion was done on the mailing list.
I don't know if I'll be active going forward, but the
trend to move everything to GitHub is a mistake, in my
opinion.
First of all, GitHub is owned by Microsoft, a private
for-profit company. I don't think I need to point out
past actions by the company which were not in the best
interest of anybody other than their own shareholders
(and then not even them in actuality). GitHub is just a
property to them, and who knows when they'll tire of it
and shut it down or sell it off. Bad idea to rely on it.
As an implementer of TLS, it was important to follow all
of the discussions as they were happening, to understand
the trade-offs being made, to check whether the result
was even something you could implement! (I'll point to
the stateless HelloRetryRequest debacle which you can not
implement correctly as an example. I still owe Ilari a
response, if I go back to reading the spec for 1.3.)
I don't want to have to "Go To GitHub" to work on TLS. I
would want all of the messages to arrive in my email, as
they used to. The messages all go into a separate folder
so I can ignore them if I want. My inbox is not
cluttered by them. This is a fine system.
GitHub's issue tracking system is actually pretty nice.
I took a look. I'd guess that there's some free software
("free" as in "freedom") which could be run on the IETF
website which would provide the equivalent functionality.
Though I'd prefer to go back to the way it used to be.
Mike
On Wed, Oct 21, 2020, at 18:51, Christopher Wood wrote:
> RFC 8874 describes several different methods for using GitHub, ranging
> from the lightweight "document management mode" [1] to more heavyweight
> "issue discussion mode" [2]. Most TLS documents are hosted and worked
> on in GitHub, though with varying levels of interaction. For example,
> some interact with GitHub in "issue tracking mode," wherein editors
> primarily use GitHub for tracking open issues. Others interact with
> GitHub in a way that resembles "issue discussion mode," wherein
> substantive issue discussion takes place on GitHub issues and consensus
> calls occur on the list.
>
> This discrepancy has caused confusion in the past, especially with
> respect to how best to stay engaged in the continued development of WG
> documents. Moreover, with the rising rate at which other WGs and IETF
> participants adopt GitHub for document development, especially those
> formed in recent years, we have not made expectations for use of GitHub
> clear.
>
> To that end, after observing what's been maximally productive for
> document development in TLS and related WGs, taking into account
> community engagement, document review support, and editor tools, we
> propose the following: the TLS WG interact with WG documents in "issue
> discussion mode," following the approach outlined in [3].
>
> We'd like to hear whether folks are support or oppose this proposal.
> Please chime in (on the list!) and share your thoughts before November
> 4. We'll determine whether there is consensus to adopt this new
> approach moving forward at that time.
>
> Thanks,
> Chris, on behalf of the chairs
>
> [1] https://www.ietf.org/rfc/rfc8874.html#name-document-management-mode
> [2] https://www.ietf.org/rfc/rfc8874.html#name-issue-labeling-schemes
> [3] https://www.ietf.org/rfc/rfc8874.html#name-issue-discussion-mode
>
> ___
> 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] AD review of draft-ietf-tls-oldversions-deprecate-06
> Saying that it's your preference without saying why is likely > to have little effect, yes. (We endeavor to make decisions > based on technical merit, not voting, after all.) Why do you > want this? Hi, I think the advice should be: "If your code currently only supports TLS 1.0, please spend a week or two adding support for both TLS 1.1 and the downgrade protection SCSV." Since the vast majority of the 1.0 and 1.1 specifications is the same, someone who takes the advice has a good chance of succeeding. (You could then also say which other extensions are important and why, roughly in order of importance.) Recommending that people wholesale abandon their legacy system and implement TLS (1.2 and) 1.3 is asking too much, and will largely be ignored by the people who would be able to add 1.1 to their 1.0 code. I understand that we don't vote here. Mike On Tue, Oct 13, 2020, at 15:15, Benjamin Kaduk wrote: > Hi Mike, > > On Tue, Oct 13, 2020 at 03:09:15PM -0400, Michael D'Errico wrote: > > I know that saying this will have no effect, but I'd > > rather see deprecation of just TLS 1.0 and retain > > version 1.1 as not recommended. > > Saying that it's your preference without saying why is likely to have > little effect, yes. (We endeavor to make decisions based on technical > merit, not voting, after all.) Why do you want this? TLS 1.1 seems to > have minimal usage (less even than 1.0) and is much closer to 1.0 than 1.2 > (let alone 1.3) in terms of design and safety. > > > Also, we should not abandon RFC 7507 (downgrade > > protection SCSV). What harm is there in keeping it > > around? None. > > I don't expect implementations to abandon SCSV any faster than they abandon > TLS 1.0 or 1.1. But if the official advice is that 1.0 and 1.1 are > obsolete, then the official advice should also be that SCSV is obsolete -- > its function is performed in a different way by the newer versions of TLS. > > -Ben > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06
I know that saying this will have no effect, but I'd rather see deprecation of just TLS 1.0 and retain version 1.1 as not recommended. Also, we should not abandon RFC 7507 (downgrade protection SCSV). What harm is there in keeping it around? None. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Sending Custom DHE Parameters in TLS 1.3
Would it be possible to define a new dual-DH exchange where you do one with server-supplied parameters, and a second one with client-supplied parameters, so if one is broken or sabotaged the connection is still secure? Mike On Mon, Oct 12, 2020, at 13:35, Blumenthal, Uri - 0553 - MITLL wrote: > I suggest that custom parameters should be allowed, and documented as > completely under user/administrator responsibility. > > Ensuring that a custom modulus is not "too small" or "too large" (etc.) > in that case is not your problem or your business. > > > > On 10/12/20, 13:32, "TLS on behalf of Ilari Liusvaara" > wrote: > > On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote: > > > > It appears that there may be a need to revert to the > > old way of sending Diffie-Hellman parameters that > > the server generates. I see that TLS 1.3 removed > > this capability*; is there any way to add it back? > > The Diffie-Hellman support in TLS 1.2 is severly broken. There is no > way to use it safely on client side. This has lead to e.g., all the web > browers to remove support for it. > > There is no way to ensure that the parameters sent are not totally > broken, e.g.: > > - Modulus too small. > - Modulus too large. > - Modulus not prime (has been used as a backdoor!). > - Modulus is weak (possibly backdoored). > - Subgroup order does not have large prime factor. > > Even checking the third would require primality test, and primality > tests at relevant sizes are slow. And the fourth and fifth can not be > checked at all in general case. > > > For ECDHE, TLS 1.2 allowed server to specify custom curve to do the > key exchange with. Rightfully pretty much nobody implemented that. > > > I think TLS WG should withdraw recommendation (as flawed) on all > TLS_DHE_* ciphersuites. > > > -Ilari > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > Attachments: > * smime.p7s ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Weak Diffie-Hellman Primes (was: DH generator 2 problem?)
On Fri, Oct 9, 2020, at 11:17, Christopher Wood wrote: > Michael, since your question is more related to the cryptographic > primitives used by TLS than the protocol itself, the chairs encourage > you to continue this discussion on the CFRG mailing list [2]. > > Thanks, > Chris, on behalf of the chairs > > [1] ... > [2] https://mailarchive.ietf.org/arch/browse/cfrg/ Hi, As requested, I sent the message below to the CFRG mailing list on the 10th. I did not join the list, but have been watching via the link [2] above and so far nobody has said anything. Mike To: cfrg at irtf dot org Hi, I'm not a member of this list, but was encouraged to start a discussion here about a discovery I made w.r.t. the published Diffie-Hellman prime numbers in RFC's 2409, 3526, and 7919. These primes all have a very interesting property where you get 64 or more bits (the least significant bits of 2^X mod P for some secret X and prime P) detailing how the modulo operation was done. These 64 bits probably reduce the security of Diffie-Hellman key exchanges though I have not tried to figure out how. The number 2^X is going to be a single bit with value 1 followed by a lot of zeros. All of the primes in the above mentioned RFC's have 64 bits of 1 in the most and least significant positions. The 2's complement of these primes will have a one in the least significant bit and at least 63 zeros to the left. When you think about how a modulo operation is done manually, you compare a shifted version of P against the current value of the operand (which is initially 2^X) and if it's larger than the (shifted) P, you subtract P at that position and shift P to the right, or if the operand is smaller than (the shifted) P, you just shift P to the right without subtracting. Instead of subtracting, you can add the 2's complement I mentioned above. Because of the fact that there are 63 zeros followed by a 1 in the lowest position, you will see a record of when the modulo operation performed a subtraction (there's a one) and when it didn't (there's a zero). You can use the value of the result you were given by your peer (which is 2^X mod P) and then add back the various 2^j * P's detailed wherever the lowest 64 bits had a value of 1 to find the state of the mod P operation when it wasn't yet finished. This intermediate result is likely going to make it easier to determine X than just a brute force search. I don't plan to join this list, though I am flattered to have been asked to do so. I'm not a cryptographer. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Sending Custom DHE Parameters in TLS 1.3
Hi, It appears that there may be a need to revert to the old way of sending Diffie-Hellman parameters that the server generates. I see that TLS 1.3 removed this capability*; is there any way to add it back? Mike *From RFC 8446: - Other cryptographic improvements were made, including changing the RSA padding to use the RSA Probabilistic Signature Scheme (RSASSA-PSS), and the removal of compression, the Digital Signature Algorithm (DSA), and custom Ephemeral Diffie- Hellman (DHE) groups. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
The argument for the security is based on the parser synthetizer combinator, which takes a parser p for type t1 and an injective function f:t1->t2 and returns a parser p' for the type p2. TLS, I don't even know you anymore Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
> Hopefully https://tools.ietf.org/html/rfc8446#section-4.2.11.2 > makes it clear why the pre_shared_key extension must be at > the end of the list. I see what was done, but it still makes me a bit sad that whatever security property was desired couldn't have been done differently to avoid this requirement. Hopefully we never discover a new extension that should be "last" Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:
> [...] The behavior we should demand from our cryptographic
> constructions is that the cryptography itself correctly returns
> "valid" or "invalid" based on the input message, provided that
> the application inputs the correct key material. (It should also
> return "invalid" if incorrect key material is supplied, of course.)
> The ability to produce two different messages for which the
> cryptography returns "valid" violates this principle; even if we
> do not see an obvious path by which a reasonable application
> might supply those inputs to the cryptographic code, it is still
> a flawed construction.
Hi,
I'd like clarification about this point, where the cryptography
should return values of "valid" or "invalid". This is a general
question, not specifically about this draft. (Please read at
least the next 2 paragraphs.)
I remember a long time ago, it may have been the renegotiation
info extension, where there was a lot of calculation being done,
there were two complicated values each side had to compute.
If they were equal, then everything was fine and the handshake
could proceed. If not, there was an insecure renegotiation
happening. (Or maybe it was the downgrade protection RFC,
I can't remember now.) But if the values were not equal, then
something bad was happening and the handshake should not
proceed.
The problem both Martin Rex and I discovered at nearly the
same time (posts to the mailing list within minutes of each
other) was that both sides could go through all the motions
faithfully calculating all of the values, correctly, and then
forget to compare them to see if the values were actually
the same. I noticed this because I wrote the code, and it
seemed like an easy thing to overlook.
I remember suggesting that we somehow incorporate the
calculated values into the derivation of the record layer keys
so the MAC would fail, or maybe into the Finished message
calculation so (if you remember to check that?) a failure is
noticed later. This suggestion was shot down by the author
unilaterally for what I perceived at the time to be petty
reasons.
I still believe that (D)TLS security should not rely on the
implementer to check whether two values are equal. This
is too easy to forget to do. Or you could do this in C:
if (complex_value_a = complex_value_b) {
// we're in trouble
}
I have not looked at the TLS 1.3 draft beyond the hour or so
I've put in so far to see whether this reliance on checking is
in there too. I've also not checked whether the security
proof I was referred to has any games where the implementer
forgot to compare values. Or a game where everybody made
the same error and nobody noticed (forgetting to put the
HelloRetryRequest into the Tramscript-Hash for example).
Mike
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DH generator 2 problem?
> This is a reminder to keep discourse here courteous and respectful. I am hoping this comment was not directed at me. I find myself biting my tongue frequently, but will try to do a better job of it going forward in any case. > We want this mailing list to be maximally useful for all readers. > Dismissive or otherwise disrespectful replies are counter to that goal. > Please check out the official Code of Conduct [1] for more information. > > Michael, since your question is more related to the cryptographic > primitives used by TLS than the protocol itself, the chairs encourage > you to continue this discussion on the CFRG mailing list [2]. I am not really interested in pursuing this further. If the cryptographers want to run with it, that's fine. I'm more of a protocol implementer person and will refocus my attention there, or not, haven't decided. Mike > Thanks, > Chris, on behalf of the chairs > > [1] https://ietf.org/about/administration/policies-procedures/code-of-conduct/ > [2] https://mailarchive.ietf.org/arch/browse/cfrg/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DH generator 2 problem?
POC || GTFO I showed how to do it just by using your brain. If I'm wrong please explain. And, no, you don't get to decide who belongs here. Also I tried reading your thesis. It's waaay over my head, but I think I learned that quaternions are two-by-two matrices, really ing cool. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DH generator 2 problem?
I have not written any code, but have just been thinking about what is going on and I am pretty sure that the bottom 64 bits of 2^X mod P tell you information which can help you determine X. The top bits are also suspect but I haven't worried about those yet. My original message below explains which primes I'm talking about. They all have a solid block of 64 bits with value one in both the uppermost and bottom-most bit positions. This construction seems to make the primes a very bad choice for use with a Diffie-Hellman key exchange. If you think about how a modulo operation takes place (the long way, one bit position at a time), you compare the operand to (a shifted version of) P and if it's bigger you subtract P and shift P one bit to the right. If the operand is not bigger than P, you just shift P one bit to the right without doing a subtraction. Due to the construction of all of the primes in the RFCs cited below, you will get a trace of this in the bottom 64 bits. There will be a one whenever a subtraction occurred and a zero otherwise. This is because if you calculate the two's complement of the prime (followed by a bunch of zeros), there will be a lone 1 preceded by at least 63 zeros. Instead of subtracting, you can add this two's complement number, so a 1 will be placed wherever a subtraction happened or a 0 if there was no subtraction. I've not worked out how to use these 64 bits to then reconstruct X, but this seems like it was purposeful so I'm fairly certain it reduces the complexity of determining X from 2^X mod P. (In fact, there may be a use for more than just 64 of the bottom bits.) A private discussion I had seems to indicate that these particular primes would be bad even with a different generator (because number theory). I am hopeful that it's possible to construct better primes which are more secure than these (even using a generator of 2) for use with Diffie-Hellman. Mike On Thu, Oct 8, 2020, at 13:54, I wrote: > Using finite-field Diffie-Hellman with a generator > of 2 is probably not the best choice. Unfortunately > all of the published primes (RFCs 2409, 3526, and > 7919) use 2 for the generator. Any other generator > would likely be (not sure how much?) more secure. > > The problem is that 2^X consists of a single bit of > value 1 followed by a huge string of zeros. When > you then reduce this modulo a large prime number, > there will be a pattern in the bits which may help > an attacker discern the value of X. This is further > helped by the fact that all of the published primes > have 64 bits of 1 in the topmost and bottom-most bits. > In addition, the larger published primes are very > similar to the shorter ones, the shorter ones closely > matching truncated versions of the larger primes. > > If you were to manually perform the modulo-P operation > yourself, you would add enough zeros to the end of P > until the topmost bit is just to the right of the 1 > bit from 2^X, and then you'd subtract. This bit > pattern will always be the same, no matter the value > of X. In particular, the top 64 bits disappear since > they're all one. Continuing the mod-P operation, you > adjust the number of zeros after the prime P and then > subtract again, reducing the size of the operand. The > pattern of bits again will be the same, regardless of > the value of X, the only difference being the number > of trailing zeros. > > I have not looked at the cyclic patterns which happen > as you do this, but I wouldn't be surprised to find > that the "new" primes based on e (RFC 7919) have > easier-to-spot bit patterns than those based on pi. > > This is speculation of course. > > Should we define some new DH parameters which use a > different generator? Maybe the primes are fine > > Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DH generator 2 problem?
> This is speculation of course. I retract this part of my message due to the fact that the format of the primes in the recent spec is the same as the format going back to the original MODP primes. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] DH generator 2 problem?
Using finite-field Diffie-Hellman with a generator of 2 is probably not the best choice. Unfortunately all of the published primes (RFCs 2409, 3526, and 7919) use 2 for the generator. Any other generator would likely be (not sure how much?) more secure. The problem is that 2^X consists of a single bit of value 1 followed by a huge string of zeros. When you then reduce this modulo a large prime number, there will be a pattern in the bits which may help an attacker discern the value of X. This is further helped by the fact that all of the published primes have 64 bits of 1 in the topmost and bottom-most bits. In addition, the larger published primes are very similar to the shorter ones, the shorter ones closely matching truncated versions of the larger primes. If you were to manually perform the modulo-P operation yourself, you would add enough zeros to the end of P until the topmost bit is just to the right of the 1 bit from 2^X, and then you'd subtract. This bit pattern will always be the same, no matter the value of X. In particular, the top 64 bits disappear since they're all one. Continuing the mod-P operation, you adjust the number of zeros after the prime P and then subtract again, reducing the size of the operand. The pattern of bits again will be the same, regardless of the value of X, the only difference being the number of trailing zeros. I have not looked at the cyclic patterns which happen as you do this, but I wouldn't be surprised to find that the "new" primes based on e (RFC 7919) have easier-to-spot bit patterns than those based on pi. This is speculation of course. Should we define some new DH parameters which use a different generator? Maybe the primes are fine Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
On 10/6/20 10:28, I wrote: ASN.1 is actually pretty cool My favorite sentence in any RFC is: In ASN.1, EXPLICIT tagging is implicit unless IMPLICIT is explicitly specified. (Not brown-nosing) Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Un-deprecating everything TLS 1.2
Just want to clarify what I meant by "It" below where I said, "It seems like a lot of wasted effort for very little gain" "It" refers to "stateless HRR", not the pseudo code I wrote. Even though I proof read the whole message several times I missed this... Mike On 10/6/20 22:13, I wrote: [] Note that the pseudo code I wrote in the quoted message below (steps 0 thru 12) does a lot more than what RFC 8446 implies you should do so that the server does have access to both the original ClientHello1 message and the HelloRetryRequest message. It seems like a lot of wasted effort for very little gain (if any, maybe it's worse in every respect - memory use, processing time, latency, bandwidth...). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 ECC Private Key Compromise? (was Re: Un-deprecating everything TLS 1.2)
On 10/6/20 19:11, Nick Harper wrote: I conclude that if this leads to some vulnerability, this implies the ECDHE algorithm (or its implementation), not the TLS handshake, is flawed. Thank you for the analysis! Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Un-deprecating everything TLS 1.2
at exist (openSSL, boringSSL, NSS, Go's crypto/tls just to name a few), it won't be hard to convince yourself that the HRR code path doesn't depend on secrets used in the core handshake. Chris P. [1] https://eprint.iacr.org/2020/573 On Mon, Oct 5, 2020 at 2:47 PM Michael D'Errico <mailto:mike-l...@pobox.com>> wrote: On 10/5/20 10:21, Christopher Patton wrote: > A couple pointers for getting started: Thank you for providing these links! I'm going through the first one now and will note that it does not even mention the HelloRetryRequest message. So while I am confident there has been quite a bit of study of a ClientHello -> ServerHello handshake, there may not have been much study of ClientHello1 -> HelloRetryRequest -> ClientHello2 -> ServerHello handshakes. I'm especially concerned about the fact that a "stateless" server does not even remember what the ClientHello1 or HelloRetryRequest messages were when it receives the second ClientHello. Load-balanced data centers seem to do this based on some of the discussion I've had this week. The protocol handles the missing ClientHello1 message by replacing it with hash-of-ClientHello1, but then you're supposed to rely on the client to tell you this value in its ClientHello2. Even if nothing funny is happening, how is the (stateless) server supposed to put the HelloRetryRequest message in the Transcript-Hash? Where does it get this value from if it's not also somehow in the "cookie" (which is how the client reminds the server of hash-of-ClientHello1)? And how would you put the HelloRetryRequest message into the cookie extension when the cookie itself is a part of the HelloRetryRequest? Just trying to imagine the code I'd have to write to do this correctly makes my head spin: 0) [disable "TCP Fast Open" so I don't do lots of processing without knowing there's a routable address associated with the client] 1) receive ClientHello1 2) generate HelloRetryRequest message without cookie 3) package ClientHello1 and HelloRetryRequest-minus- cookie into a data structure, encrypt + MAC to create a cookie 4) insert the cookie into the HelloRetryRequest, remembering to update the length of the extensions 5) send HelloRetryRequest (with cookie) to client 6) erase all memory of what just happened!!! 7) receive ClientHello2 8) ensure it has a cookie extension (well I should at least remember the fact that I already sent a HelloRetryRequest and not be completely stateless, right? Otherwise the client may be able to send many ClientHelloN's without a cookie) 9) check MAC on the cookie and if it's valid, decrypt it to determine the contents of ClientHello1 and the HelloRetryRequest (without cookie) messages 10) MAKE SURE ClientHello2 is valid according to what was received in ClientHello1 (RFC 8446 has a list of things a client is allowed to do; I would want to check all of them, so a hash of ClientHello1 is inadequate in my opinion). This seems to be a necessary thing to do even for stateful servers. 11) Recreate the actual HelloRetryRequest message that was sent to the client by putting the cookie into HRR-minus-cookie (in the same place within the list of extensions as was already done in step 4, but since we threw it away, do it again) 12) Hash the ClientHello1 and add this hash to the Transcript-Hash along with the HelloRetryRequest message And I didn't even handle the possibility of replay. Can a cryptographer (I don't claim to be one) please take a few moments to look at the possibilities for a server which doesn't implement step 8 and allows multiple ClientHello's without a cookie on the same connection? Or a server that doesn't put the entire ClientHello1 into the cookie and can not check whether ClientHello2 is conformant to the list of allowed changes? Or a server that has to maybe "guess" the content of HelloRetryRequest based on ClientHello2 since it just sent hash-of-ClientHello1 in the cookie? And if it guesses wrong and the Transcript-Hash ends up different from the client, the peers will not be able to communicate (denial of service to legitimate clients). Implementers -- how do you put a HelloRetryRequest message into the Transcript-Hash if you are "stateless" and threw it in the bin along with ClientHello1? Mike > 1. Check out Dowling et al.'s recent analysis. Published a month or > so ago, it's the mo
[TLS] TLS 1.3 ECC Private Key Compromise? (was Re: Un-deprecating everything TLS 1.2)
[Resending this with a better Subject line. --Mike] On 10/6/20 16:11, I wrote: On 10/5/20 22:00, Christopher Patton wrote: I agree that the HRR code path is hard to reason about, but I don't really see an attack here. Is it your contention that the HRR code path leads to an attack not accounted for by existing proofs? I have a concern that yes, there may be a way to attack a TLS server via the HRR code path that may not be possible without using HRR. I am hopeful that I'm wrong about this, but as a non- cryptographer it would be difficult to come up with any kind of proof. Specifically, I am thinking that a client can trick a server to use its ECC private key to do an operation using the wrong curve, the wrong point, or maybe something else. See the pseudo code I wrote below. Step 10 is where the server should be checking that the second ClientHello is valid based on what it originally sent in the first ClientHello. RFC 8446 implies that you should check ClientHello2 vs. ClientHello1 because if this wasn't necessary then why is there a list of allowed modifications? But then it also says you can throw away CH1 and just send the client a hash of it, rely on the client to send it back (once), and not check whether the second ClientHello is properly similar to the first one (since the server doesn't even retain it). Can a malicious client send in its second Client- Hello an invalid combination of EC point, curve, cipher suite, etc. (that a server maybe doesn't even check because there's a cookie extension in there as well) and then use the result to discern the key? How many handshakes does the client need to make to get the private key if I'm right? One? I've avoided spelling this out because it seems potentially serious, and there was the weekend, but it's Tuesday now, and I have been hopeful that I haven't been just ignored and everyone has been disabling TLS 1.3 and/or fixing their code, etc. Please just tell me why I'm wrong and I'll feel better since we won't have to malign another cute furry animal. Mike I don't think this is likely. One way to think about this problem is as follows [1]. Given an attacker that exploits the HRR code path, can you efficiently construct an attacker that exploits a version of the protocol without the HRR code path implemented? If the answer is "yes", and if we assume the protocol is secure *without* the HRR code path implemented (as asserted by a proof of security, say), it must be case that the protocol is also secure *with* the HRR code path implemented. Although I haven't studied this problem specifically --- Dowling et al. appear to address this problem, if only implicitly --- my intuition is that the answer is "yes". The reason, loosely, is that the HRR code path doesn't appear to depend on any ephemeral or long-term secret key material used by the server for the core handshake. In particular, it doesn't depend on the server's key share or signing key. This means that the adversary can "simulate" any computation involving the HRR code path in its head, without interacting with a real server. This observation ought to yield the reduction I described above. Perhaps the spec is vague here, but if you study any one of the high quality implementations that exist (openSSL, boringSSL, NSS, Go's crypto/tls just to name a few), it won't be hard to convince yourself that the HRR code path doesn't depend on secrets used in the core handshake. Chris P. [1] https://eprint.iacr.org/2020/573 On Mon, Oct 5, 2020 at 2:47 PM Michael D'Errico <mailto:mike-l...@pobox.com>> wrote: On 10/5/20 10:21, Christopher Patton wrote: > A couple pointers for getting started: Thank you for providing these links! I'm going through the first one now and will note that it does not even mention the HelloRetryRequest message. So while I am confident there has been quite a bit of study of a ClientHello -> ServerHello handshake, there may not have been much study of ClientHello1 -> HelloRetryRequest -> ClientHello2 -> ServerHello handshakes. I'm especially concerned about the fact that a "stateless" server does not even remember what the ClientHello1 or HelloRetryRequest messages were when it receives the second ClientHello. Load-balanced data centers seem to do this based on some of the discussion I've had this week. The protocol handles the missing ClientHello1 message by replacing it with hash-of-ClientHello1, but then you're supposed to rely on the client to tell you this value in its ClientHello2. Even if nothing funny is happening, how is the (stateless) server supposed to put the HelloRetryRequest message in the Transcript-Hash? Where does it get this value from if it's not also somehow in the "cookie" (which is how the client reminds the server of hash-of-ClientHello1)?
Re: [TLS] Un-deprecating everything TLS 1.2
On 10/5/20 22:00, Christopher Patton wrote: I agree that the HRR code path is hard to reason about, but I don't really see an attack here. Is it your contention that the HRR code path leads to an attack not accounted for by existing proofs? I have a concern that yes, there may be a way to attack a TLS server via the HRR code path that may not be possible without using HRR. I am hopeful that I'm wrong about this, but as a non- cryptographer it would be difficult to come up with any kind of proof. Specifically, I am thinking that a client can trick a server to use its ECC private key to do an operation using the wrong curve, the wrong point, or maybe something else. See the pseudo code I wrote below. Step 10 is where the server should be checking that the second ClientHello is valid based on what it originally sent in the first ClientHello. RFC 8446 implies that you should check ClientHello2 vs. ClientHello1 because if this wasn't necessary then why is there a list of allowed modifications? But then it also says you can throw away CH1 and just send the client a hash of it, rely on the client to send it back (once), and not check whether the second ClientHello is properly similar to the first one (since the server doesn't even retain it). Can a malicious client send in its second Client- Hello an invalid combination of EC point, curve, cipher suite, etc. (that a server maybe doesn't even check because there's a cookie extension in there as well) and then use the result to discern the key? How many handshakes does the client need to make to get the private key if I'm right? One? I've avoided spelling this out because it seems potentially serious, and there was the weekend, but it's Tuesday now, and I have been hopeful that I haven't been just ignored and everyone has been disabling TLS 1.3 and/or fixing their code, etc. Please just tell me why I'm wrong and I'll feel better since we won't have to malign another cute furry animal. Mike I don't think this is likely. One way to think about this problem is as follows [1]. Given an attacker that exploits the HRR code path, can you efficiently construct an attacker that exploits a version of the protocol without the HRR code path implemented? If the answer is "yes", and if we assume the protocol is secure *without* the HRR code path implemented (as asserted by a proof of security, say), it must be case that the protocol is also secure *with* the HRR code path implemented. Although I haven't studied this problem specifically --- Dowling et al. appear to address this problem, if only implicitly --- my intuition is that the answer is "yes". The reason, loosely, is that the HRR code path doesn't appear to depend on any ephemeral or long-term secret key material used by the server for the core handshake. In particular, it doesn't depend on the server's key share or signing key. This means that the adversary can "simulate" any computation involving the HRR code path in its head, without interacting with a real server. This observation ought to yield the reduction I described above. Perhaps the spec is vague here, but if you study any one of the high quality implementations that exist (openSSL, boringSSL, NSS, Go's crypto/tls just to name a few), it won't be hard to convince yourself that the HRR code path doesn't depend on secrets used in the core handshake. Chris P. [1] https://eprint.iacr.org/2020/573 On Mon, Oct 5, 2020 at 2:47 PM Michael D'Errico <mailto:mike-l...@pobox.com>> wrote: On 10/5/20 10:21, Christopher Patton wrote: > A couple pointers for getting started: Thank you for providing these links! I'm going through the first one now and will note that it does not even mention the HelloRetryRequest message. So while I am confident there has been quite a bit of study of a ClientHello -> ServerHello handshake, there may not have been much study of ClientHello1 -> HelloRetryRequest -> ClientHello2 -> ServerHello handshakes. I'm especially concerned about the fact that a "stateless" server does not even remember what the ClientHello1 or HelloRetryRequest messages were when it receives the second ClientHello. Load-balanced data centers seem to do this based on some of the discussion I've had this week. The protocol handles the missing ClientHello1 message by replacing it with hash-of-ClientHello1, but then you're supposed to rely on the client to tell you this value in its ClientHello2. Even if nothing funny is happening, how is the (stateless) server supposed to put the HelloRetryRequest message in the Transcript-Hash? Where does it get this value from if it's not also somehow in the "cookie" (which is how the client reminds the server of hash-of-ClientHello1)? And how would you put the HelloRetryRequest message into the cook
Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
I think we are in agreement. On 10/6/20 13:12, Christian Huitema wrote: * Receiver side: receive the message, parser with generic ASN.1 decoder, process the message using the "parsed" representation, re-encode with DER, check the signature. I recall that at least one root certificate had a SEQUENCE encoded using BER-but-not-DER (?) Yeah if your software re-encoded that, it would no longer be the same sequence of bytes. Experience showed that this workflow is very problematic, because the parse/reencode process may introduce subtle changes and the signature will fail. One may argue that these changes are due to implementation bugs, but fact it that this is a rich environment for growing bugs. Based on experience, the receiver side is better done as: * Receiver side: receive the message, save it, parse and process, and when it is time to verify the signature go back to the original message and check the signature. This is how I did X.509 verification, though I was late to the game and the advice was already there to accept a BER-encoded certificate. Not sure if I would have done the DER re-encoding bit if that was the current advice at the time since it seems like the wrong thing to do, but maybe I would have. If we do that, then there is no reason to mandate minimal length encoding. And TLS already does that. For example, we do not reorder extensions according to some canonical rules before placing them in the transcript. I was disappointed to see that the TLS 1.3 spec now has a requirement to put one of the ClientHello extensions in a specific place (last in the list). We discussed this at length during the development of either TLS 1.2 or one of the extensions (maybe renegotiation-info?) and we ultimately came to what I believe was the correct decision never to require any ordering of the extensions. Sad to see the group capitulated to whomever said it would make their software easier to write (which I doubt). Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
Okay, we disagree about things. Not sure it's worth proceeding. I haven't read whatever spec cTLS is Got it. My advice is universally applicable, to whatever spec you are working on. cTLS, QUIC, whatever-TF. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
But if the spec says MUST be minimum length, I would feel compelled to check every one. "Be liberal in what you accept" no? A requirement of MUST in a security protocol usually means (or at least should mean) that there's a good reason for the thing, whatever it is, so if you are not checking it, then bad things can happen. I try to heed Postel's advice though, and can sometimes be more liberal than the spec says if I really know what the trade-offs are. With crypto though, I don't pretend to be expert in it, I'm kind of afraid of it, and I'm not sure how anyone can claim to understand it well enough to say, for example, that ECC is so much better than everything else. What if it's all broken? We're getting rid of everything else that we know works Please don't require minimum length unless security would be weaker without it. If the fields are used in digests/hashing/signatures, then it matters. (The DER/BER comment upthread) It matters in X.509 certificates because the basic encoding rules (BER) allow you to specify the same thing in different ways. With DER, there is only one way to encode every element, so everybody will come up with the same string of bytes and hashes of those strings will be the same, signatures will verify, etc. I haven't read whatever spec cTLS is, but know that if I decided to implement it someday and there's a "varints MUST be minimum length" requirement, I'd assume that it's important and would check for it. If this is a waste of CPU cycles, then please don't make it a requirement. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
I would prefer the minimum encoding length. But if the spec says MUST be minimum length, I would feel compelled to check every one. Please don't require minimum length unless security would be weaker without it. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
1994 called. It wanted to talk about distinguished encoding rules. Yes, DER vs. BER. ASN.1 is actually pretty cool (bits on the wire in X.690, not X.680). The encoding also reminds me of UTF-8 which is a variable length: 0xxx 110x 10yy 1110 10yy 10zz 0xxx 10yy 10zz 10ww UTF-8 requires using the fewest number of bytes to represent a Unicode code point. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Un-deprecating everything TLS 1.2
On 10/5/20 10:21, Christopher Patton wrote: A couple pointers for getting started: Thank you for providing these links! I'm going through the first one now and will note that it does not even mention the HelloRetryRequest message. So while I am confident there has been quite a bit of study of a ClientHello -> ServerHello handshake, there may not have been much study of ClientHello1 -> HelloRetryRequest -> ClientHello2 -> ServerHello handshakes. I'm especially concerned about the fact that a "stateless" server does not even remember what the ClientHello1 or HelloRetryRequest messages were when it receives the second ClientHello. Load-balanced data centers seem to do this based on some of the discussion I've had this week. The protocol handles the missing ClientHello1 message by replacing it with hash-of-ClientHello1, but then you're supposed to rely on the client to tell you this value in its ClientHello2. Even if nothing funny is happening, how is the (stateless) server supposed to put the HelloRetryRequest message in the Transcript-Hash? Where does it get this value from if it's not also somehow in the "cookie" (which is how the client reminds the server of hash-of-ClientHello1)? And how would you put the HelloRetryRequest message into the cookie extension when the cookie itself is a part of the HelloRetryRequest? Just trying to imagine the code I'd have to write to do this correctly makes my head spin: 0) [disable "TCP Fast Open" so I don't do lots of processing without knowing there's a routable address associated with the client] 1) receive ClientHello1 2) generate HelloRetryRequest message without cookie 3) package ClientHello1 and HelloRetryRequest-minus- cookie into a data structure, encrypt + MAC to create a cookie 4) insert the cookie into the HelloRetryRequest, remembering to update the length of the extensions 5) send HelloRetryRequest (with cookie) to client 6) erase all memory of what just happened!!! 7) receive ClientHello2 8) ensure it has a cookie extension (well I should at least remember the fact that I already sent a HelloRetryRequest and not be completely stateless, right? Otherwise the client may be able to send many ClientHelloN's without a cookie) 9) check MAC on the cookie and if it's valid, decrypt it to determine the contents of ClientHello1 and the HelloRetryRequest (without cookie) messages 10) MAKE SURE ClientHello2 is valid according to what was received in ClientHello1 (RFC 8446 has a list of things a client is allowed to do; I would want to check all of them, so a hash of ClientHello1 is inadequate in my opinion). This seems to be a necessary thing to do even for stateful servers. 11) Recreate the actual HelloRetryRequest message that was sent to the client by putting the cookie into HRR-minus-cookie (in the same place within the list of extensions as was already done in step 4, but since we threw it away, do it again) 12) Hash the ClientHello1 and add this hash to the Transcript-Hash along with the HelloRetryRequest message And I didn't even handle the possibility of replay. Can a cryptographer (I don't claim to be one) please take a few moments to look at the possibilities for a server which doesn't implement step 8 and allows multiple ClientHello's without a cookie on the same connection? Or a server that doesn't put the entire ClientHello1 into the cookie and can not check whether ClientHello2 is conformant to the list of allowed changes? Or a server that has to maybe "guess" the content of HelloRetryRequest based on ClientHello2 since it just sent hash-of-ClientHello1 in the cookie? And if it guesses wrong and the Transcript-Hash ends up different from the client, the peers will not be able to communicate (denial of service to legitimate clients). Implementers -- how do you put a HelloRetryRequest message into the Transcript-Hash if you are "stateless" and threw it in the bin along with ClientHello1? Mike 1. Check out Dowling et al.'s recent analysis. Published a month or so ago, it's the most recent proof of security of the full handshake (also includes PSK modes): https://eprint.iacr.org/2020/1044 2. Check out Paterson and van der Merwe's survey of the body of papers that helped to shape TLS 1.3. It also overviews the myriad attacks against TLS 1.2 and below that catalyzed a more proactive design approach for 1.3: https://link.springer.com/chapter/10.1007/978-3-319-49100-4_7 If you're unable to download the second (2.), the same paper appears in a slightly different form in van der Merwe's PhD thesis. No analysis is perfect, but so far, 1.3 appears to be far superior to 1.0-1.2. Best, Chris P. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Un-deprecating everything TLS 1.2
Hi, I'm pretty sure TLS 1.3 is completely broken. Can we please stop deprecating things that TLS 1.2 uses and make them all Recommended again? Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Test Server update
BTW, if anybody is hoping I'll update my test server to support TLS 1.3, I am not going to be doing that. Version 1.3 is broken and I don't think anybody should use it. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
On 10/3/20 16:12, Nick Lamb wrote: You can't possibly implement [stateless HelloRetryRequest] the way the spec suggests with just a hash in a HRR cookie extension. Lots of people have and it works just fine, so it seems to me that "You can't possibly" here means something closer to "I still don't understand how to" and as such would be more appropriate to some sort of programming Q site like Stack Overflow than an IETF working group. StackOverflow has only one result if you search for HelloRetryRequest and it is about jdk.disabledAlgorithms. When you say it "works just fine" I think you are saying that the handshake will complete. But is it secure? This is the important parts of "works" and I'm not sure it's possible to do it correctly without a lot of work, and am certain that a hash is not enough information even if it's integrity-protected. The client MUST use the same value for legacy_session_id in its retried ClientHello. As a result this value will be available alongside the cookie. Section 4.4.2 is clear that a hash used this way in the cookie should be "protected with some suitable integrity protection algorithm". For example some implementations use an HMAC construction, but you could do other things here successfully. So in fact this is not especially optimistic. All the integrity protection bytes tell you is that the server did in fact generate the cookie at some point in the past. You don't even know how old the cookie is if it just contains a hash, unless you are frequently changing the key (and keeping the previous key around for a bit to cover the case that the key rollover happened within the life- time of an old cookie). A client could possibly exploit this by making many connections and sending a second ClientHello on each one with the same legacy_session_id_echo and cookie. A stateless server might not be keeping track of whether a cookie is being reused, and why would it if it's actually stateless? If it's going to go through the trouble of keeping track of previously-used cookies, possibly across several distributed machines, why not just be not-stateless and avoid all of the hassle? And, yes, it is optimistic to trust a client to do the right thing. It's also dangerous. I used the word optimistic to downplay the significance. Rebuilding the beginning of the transcript hash based solely on what the client sends in its second ClientHello message is fraught with peril. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
On 10/2/20 22:13, I wrote: Please don't tell me all the current TLS 1.3 implementations forgot to include the HelloRetryRequest in the transcript hash. Is this the reason why Microsoft ditched Edge and rebuilt on top of Chrome? There must have been a bug bounty for this. Are there still bug bounties? I've been sidelined for a while Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
On 10/2/20 14:15, I wrote: The server also needs to know the entire HelloRetryRequest message since this goes into the Transcript Hash calculation: Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) = Hash(message_hash ||/* Handshake type */ 00 00 Hash.length || /* Handshake message length (bytes) */ Hash(ClientHello1) || /* Hash of ClientHello1 */ HelloRetryRequest || ... || Mn) Please don't tell me all the current TLS 1.3 implementations forgot to include the HelloRetryRequest in the transcript hash. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Client attacks on stateless HRR? (was Re: Is stateless HelloRetryRequest worthwhile?)
> If the client is trying to perform > some sort of attack on the server by re-sending an old cookie, I assume > that a prerequisite for this attack is that the TLS handshake succeeds. Maybe you don't need the handshake to succeed? As a non-cryptographer I can't say what the implications might be (as I said to Watson in private email) but some of you are crypto people. If you can create N parallel sessions using the same cookie (send the same ClientHello1 with the same Random value (?), or maybe trick a poorly-written server by sending an initial ClientHello1 containing a cookie extension, or use DTLS (?)), what could you do as a malicious client? I don't know the answer, I'm asking. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
> > You can't possibly implement [stateless HelloRetryRequest] the > > way the spec suggests with just a hash in a HRR cookie extension. > > The only thing the server needs to know is the hash of the ClientHello > (so it can restore the transcript hash) and that the server has already > sent a HelloRetryRequest (which it can detect by presence of the > cookie). The only argument I've seen made for what the spec suggests > not working is being able to verify which fields changed between > ClientHello1 and ClientHello2. The server also needs to know the entire HelloRetryRequest message since this goes into the Transcript Hash calculation: Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) = Hash(message_hash ||/* Handshake type */ 00 00 Hash.length || /* Handshake message length (bytes) */ Hash(ClientHello1) || /* Hash of ClientHello1 */ HelloRetryRequest || ... || Mn) Many of the fields in HelloRetryRequest are fixed or predictable, but the legacy_session_id_echo is not, for example. Also, relying on the client to remind you what the hash of ClientHello1 is seems extremely "optimistic" (in my opinion). > I see no language in RFC 8446 that the server MUST enforce that > the ClientHello2 is conformant with respect to ClientHello1. It doesn't, and you could probably argue that the HelloRetryRequest can be just a "do over" and let the client try again however it wants. But if the server doesn't do 100% validation of the second ClientHello as if it never received the first one, then there is room for mischief by a "curious" client. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
> I am having a difficult time understanding the tradeoffs you're facing. This is the first time I'm reading the TLS 1.3 RFC. I have implemented SSLv3, TLS 1.0, 1.1, and 1.2. You may have used my test server at https www dot mikestoolbox dot org or dot net to test your own code. It's kind of old now since it doesn't do ECC and the DHE_RSA key exchange I focused on has been disabled by most clients so you end up getting a regular RSA handshake now. I have gotten caught by the stateless HelloRetryRequest and can't get past it. You can't possibly implement it the way the spec suggests with just a hash in a HRR cookie extension. If it can be done at all, the stateless server should probably just put the ClientHello1 and HRR (minus the cookie) into the cookie extension. If this is how it should be done, then the spec should say so -- exactly how to do it so everyone does it the same (correct) way and not just hand-wave it and say figure it out yourself. Getting the cookie right isn't enough because of the potential for resending an old cookie by a mischievous client. Nico suggests that replay caches are hard to get right even when your distributed servers are all talking to each other. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
> Not always; see TCP "fast open" options. Maybe this should be disabled? Fortunately if you wanted to there is a setsockopt for TCP_FASTOPEN. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)
On 9/30/20 17:34, Benjamin Kaduk wrote: The HRR is presumed to be a deterministic function of the initial ClientHello, and as I discussed in my earlier message, the server can reconstruct the initial ClientHello from the second ClientHello and verify it against the hash in the cookie. I don't believe you can reliably always reconstruct the initial ClientHello1 from ClientHello2. Maybe current TLS 1.3 clients are sending simple enough ClientHello messages so this is possible today, but what about next week, next year, etc.? RFC 8446 lists on pages 27-28 all of the ways the client is supposed to (or allowed to) change the ClientHello that gets returned after a HelloRetryRequest: - If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group. - Removing the "early_data" extension (Section 4.2.10) if one was present. Early data is not permitted after a HelloRetryRequest. - Including a "cookie" extension if one was provided in the HelloRetryRequest. - Updating the "pre_shared_key" extension if present by recomputing the "obfuscated_ticket_age" and binder values and (optionally) removing any PSKs which are incompatible with the server's indicated cipher suite. - Optionally adding, removing, or changing the length of the "padding" extension [RFC7685]. - Other modifications that may be allowed by an extension defined in the future and present in the HelloRetryRequest. The only way stateless HRR could work (I think) is if you sent the entire ClientHello1 and HelloRetryRequest-minus-cookie encoded in the cookie somehow, encrypted, integrity-protected. But a hash of ClientHello1 by itself just won't do. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)
I wrote: > Also the server can't be actually stateless since > it needs to know the HelloRetryRequest message > for the transcript hash, right? How can you even implement stateless HRR with a pseudo-session-ticket in the "cookie"? The server needs to know the full HRR message to calculate the transcript hash, but this can't be part of the ticket since the ticket is included within the HRR, thus changing it Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)
Anyway, back on the topic of stateless HelloRetryRequest, I don't see how this can work given that the client can make several modifications to the ClientHello which will invalidate the hash sent in the "cookie" (even if the client echos it back as required without modification). The hash isn't used for validation, but for continuing the running hash of the transcript to ensure that the negotiation isn't interfered with. See section 4.4.1. There may be a problem here if you try to implement the stateless HelloRetryRequest the way the spec. implies (by sending a hash of ClientHello1 in the "cookie" extension). A non-conforming client can send an initial ClientHello1, which both client and server know so they can compute the hash correctly. The server puts the hash in the cookie of a HelloRetryRequest and sends that to the client. The client can then put together any ClientHello2 it cares to and include the cookie from the HelloRetryRequest. If the server is "stateless" and throws away ClientHello1, there's no way for it to know that the second ClientHello2 it receives doesn't properly relate to ClientHello1. The handshake can still go all the way to completion even with a bad ClientHello2, I think. Also the server can't be actually stateless since it needs to know the HelloRetry- Request message for the transcript hash, right? There are a number of changes allowed to be made to the ClientHello1 that will make it impossible for the server to recreate the hash sent in the cookie field, even when there is nothing malicious happening. Simply changing the padding extension is one of them. Pruning the key_share list is another, as is updating the pre_shared_key list. So it can't reject any ClientHello2 which it doesn't hash to the cookie value. I don't know what the implications of this are (I've only spent about 30 minutes reading the spec.) but there appears to be some room for mischief if a server is "stateless." Maybe this should not be allowed out of prudence? What does this mean for DTLS 1.3? Putting a pseudo-session-ticket in the cookie as NSS (?) does might solve this problem to some extent, but I doubt the extra processing is worth the tiny amount of memory saved by tossing the ClientHello1 under normal conditions. (When being actively attacked this may be necessary, though I don't have experience working in a data center so I can't really say.) However, the RFC should probably not be implying that you can do stateless HelloRetryRequest by sending a cookie with just a hash of ClientHello1 (even if the server uses some integrity protection mechanism on the hash value). Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
DTLS 1.3 can be found here: https://tools.ietf.org/html/draft-ietf-tls-dtls13-38 Thank you. The HRR is used in DTLS 1.3 for DDoS prevention. This makes sense since DTLS is over UDP, but TLS is over TCP, so it's already undergone the SYN/ACK handshake to establish there's an actual peer with a reachable address. I'm thinking that the majority of the time, connections are going to be legitimate, so optimize for that case. Keep the first ClientHello in memory, send a simple unpredictable cookie (maybe 128 bits ?) and just check that it gets echoed. Then do all the validation of the second ClientHello against the first one that you have to do anyway. Monitor the activity occurring and if the server decides it's being attacked in some way, maybe then switch to stateless HRR (if this makes sense) or do whatever other countermeasures are appropriate. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
> The costs you describe are trivial. The general idea among developers these days that CPU cycles are free is a huge problem. You didn't answer my biggest question, though, which was whether you (or anybody else!) has had success using stateless HelloRetryRequest to increase the number of connections a datacenter can handle due to the fact that the servers were memory-bound. The amount of memory to hold the first ClientHello message is trivial. But if doing stateless HRR has measurably increased the performance of a data center's web serving capability, I'll change my mind about it. > We also implement DTLS where this is properly useful. I can't find the DTLS 1.3 spec. Which RFC is it? Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
[I'm resending this with a more appropriate Subject line. --Mike] On 9/29/20 19:51, Martin Thomson wrote: > It's symmetric crypto[1]. Hardly worth noting. > [1] Mostly. NSS wraps the symmetric key with an asymmetric key so that > server clusters can share session ticket encryption keys without needing > interconnects. But encryption or decryption only happens once per instance. Well, you also need a MAC, right? (encrypt-then-mac) This requires another key and a bunch of computation. Then you have to decode the cookie back into the server state, and then check whether the new ClientHello (CH) matches the original from the cookie, with possible changes, making sure that the key_share supplied in the new CH was in the original CH, checking that the list of PSK's was not tampered with in invalid ways, etc. Much of this is required of any handshake involving HRR even if not stateless. Seems worth noting. Have you measured? And how do you prevent someone from sending an old cookie back? If the server is truly stateless Did you (or a client) actually have a data center full of memory-bound servers which are now handling many more connections using the stateless HRR feature? I'm not trying to be unkind, I genuinely don't understand how stateless HRR can be beneficial. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On 9/29/20 19:51, Martin Thomson wrote: It's symmetric crypto[1]. Hardly worth noting. [1] Mostly. NSS wraps the symmetric key with an asymmetric key so that server clusters can share session ticket encryption keys without needing interconnects. But encryption or decryption only happens once per instance. Well, you also need a MAC, right? (encrypt-then-mac) This requires another key and a bunch of computation. Then you have to decode the cookie back into the server state, and then check whether the new ClientHello (CH) matches the original from the cookie, with possible changes, making sure that the key_share supplied in the new CH was in the original CH, checking that the list of PSK's was not tampered with in invalid ways, etc. Much of this is required of any handshake involving HRR even if not stateless. Seems worth noting. Have you measured? And how do you prevent someone from sending an old cookie back? If the server is truly stateless Did you (or a client) actually have a data center full of memory-bound servers which are now handling many more connections using the stateless HRR feature? I'm not trying to be unkind, I genuinely don't understand how stateless HRR can be beneficial. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
Is stateless HelloRetryRequest even being used? If so, how? NSS implements HRR this way always. We pack the necessary state for the connection to continue into the cookie (which is protected with an AEAD). We can also retain server state, in which case the retained state is compared against the state from the cookie as an extra sanity check. We chose to do this for a few reasons, but one thing is that it encourages us to use the second ClientHello for negotiating everything. OK, so it sounds like you put something similar to a NewSessionTicket (TLS 1.2) in the cookie with enough information to recreate the server state. This is quite a lot more information than just a "hash" as the spec implies. Also, are you sure you want to do this? The design of TLS 1.3 was supposed to make it fast, but creating a pseudo session ticket for every connection requiring a HRR and then validating and decoding it is going to be really slow. And your data center is going to get hotter because your servers will be compute bound instead of memory bound (if they even were). Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote: > > Luckily, we don't have any angry cryptographers in this group. Were they all pushed away too? Anyway, back on the topic of stateless HelloRetryRequest, I don't see how this can work given that the client can make several modifications to the ClientHello which will invalidate the hash sent in the "cookie" (even if the client echos it back as required without modification). Is stateless HelloRetryRequest even being used? If so, how? Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Sun, Sep 27, 2020, at 22:28, Michael D'Errico wrote: > > I'm afraid to keep reading In section 4, HandshakeType and Handshake are missing the value for the HelloRetryRequest message. Oh wait, never mind, it's the same value as ServerHello (?). Everything appears to be a hack within a hack If I hadn't already implemented TLS 1.0..1.2 I'd be completely lost reading RFC 8446. In fact I AM completely lost reading it. There's a mention of stateless HelloRetryRequest where the server sends a "cookie" containing a hash of the ClientHello. Is it supposed to rely on the client to echo this back? What if it doesn't? Or it puts in a different value? Or it gets modified in transit? Or it sends an initial ClientHello with a cookie extension as if it got a HelloRetryRequest? Am I worried about nothing here? OK, time for bed Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Sun, Sep 27, 2020, at 16:53, Ben Smyth wrote: > The client will reject the server's ServerHello in your example. OK, so all eggs in one basket? I'm afraid to keep reading Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS 1.3 Problem?
Hi, Took a quick look at RFC 8446 and noticed that there is no definition of ServerKeyExchange or ServerHelloDone which are part of TLS 1.2 and prior. A 1.3 client talking to a 1.2 or earlier server is likely going to receive both of these messages: RFC 5246 TLS August 2008 Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data <---> Application Data Figure 1. Message flow for a full handshake Since RFC 8446 obsoletes RFC 5246, this is a serious problem. How is this supposed to work? Sorry but I did not follow the development of TLS 1.3. I felt that I was unwelcome in this group by some of the "angry cryptographers" as I call them. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Sabotage?
Hi, I get a weird feeling that the internet is being hijacked and soon it will be impossible to reverse course. I have not followed the development of TLS 1.3 but it seems very different from TLS 1.2. Also TLS 1.2 is very different from TLS 1.0/1.1 (which are being deprecated). QUIC looked good at a glance, but it seems to rely on TLS to share key material, and also I'm more than a bit concerned about its capability to track users. Then there's Zoom video conferencing, where everybody working from home or in virtual school has an audio and video feed streaming to their servers. Github is owned by Microsoft with some dire consequences. Lots of large companies trying to be everything to everyone, and it turns out they're cruel. Anyone? Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New direction for TLS?
Hi, It looks like QUIC is even better than what I proposed. Thank you for suggesting it. Mike On Fri, Feb 14, 2020, at 15:03, Benjamin Kaduk wrote: > Hi Mike, > > On Fri, Feb 14, 2020 at 09:46:56AM -0500, Michael D'Errico wrote: > > Hi, > > > > It's been a long time since I posted to this list but saw that the charter > > is being updated and wanted to share an idea I had a while ago but have not > > found the time to work on. The TL;DR is to deprecate TLS and rebuild > > security on top of DTLS. With DTLS, you have encrypted packets, so think of > > them as the new IP and build TCP on top of that. It'd be like making the > > internet run on TCP/DTLS instead of TCP/IP, so most of the work is already > > done. I think this is all I need to say to get the idea across, but I can > > add detail if needed. > > This sounds really similar to QUIC > (https://datatracker.ietf.org/wg/quic/documents); perhaps you could take a > look > and try to describe any differences between your idea and what's being done > there? > > -Ben > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] New direction for TLS?
Hi, It's been a long time since I posted to this list but saw that the charter is being updated and wanted to share an idea I had a while ago but have not found the time to work on. The TL;DR is to deprecate TLS and rebuild security on top of DTLS. With DTLS, you have encrypted packets, so think of them as the new IP and build TCP on top of that. It'd be like making the internet run on TCP/DTLS instead of TCP/IP, so most of the work is already done. I think this is all I need to say to get the idea across, but I can add detail if needed. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
Aaron Zauner wrote: (of course I'd opt for SSLv5 just to mess with people). I'm surprised nobody has yet suggested retroactive renaming: SSLv4 == TLS 1.0 SSLv5 == TLS 1.1 SSLv6 == TLS 1.2 SSLv7 == TLS 1.3 Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
