Re: [TLS] draft-les-white-tls-preferred-pronouns
Lester White writes: > Title : Preferred Pronouns Extension for TLS I think the Security Considerations section needs to mention two security considerations, firstly the preferred identity is an unauthenticated parameter and can't safely be used until the Finished message definitely determines its validity so it shouldn't be used until after the other side's Finished message is received, and secondly that the odd-numbered (presumably "prime" is meant) number of experts needs to be at least 1024 bits worth, and a strong prime, i.e. p-1 and p+1 should have large prime factors. The suggested value of 11 doesn't meet these criteria, so should be changed for a value that does. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Don't Split HelloRetryRequest
I'm not sure I agree with all of Martin's remarks below, but I absolutely agree both that we seem to be almost happily adding complexity and that that's a bad plan. S. On 01/04/2021 02:57, Martin Thomson wrote: I just reviewed the proposal to split HelloRetryRequest into outer and (encrypted) inner. https://github.com/tlswg/draft-ietf-tls-esni/pull/407/files I'm strongly opposed to taking the change. It complicates the design greatly and unnecessarily. The existing design has some flaws, but they can be fixed more elegantly than this. (Apologies if this seems a little long. I'm writing down every possible argument I can think of, because I can't guarantee that I will be coherent at the meeting.) # HelloRetryRequest Has a Narrow Purpose Let's first address the key question of what HelloRetryRequest exists to do. It exists to ensure that the client and server are able to jointly agree on keys to use for the remainder of the handshake. This is a very narrow scope. Furthermore, the particulars of key agreement are public. This is important as we can also say that all hidden servers need to use the same configuration as it relates to cipher suites, key exchange, and related parameters, as the results of negotiation are sent in the clear in the ServerHello. My claim here is that there is no value in protecting any parameter that might change in response to HelloRetryRequest. # Don't Seek Complexity It is entirely possible to imagine scenarios where an inner ClientHello has different preferences from an outer ClientHello. While in theory we can construct a design that would support that (the pull request does this well enough), to do so only serves to increase complexity. It does not address any real use case or problem that I'm aware of. If we allow for the client to provide different values in inner and outer ClientHello messages, then the current design means that the client is faced with some ambiguity about which of the two messages a HelloRetryRequest applies to. If we try to create an indicator, then that leaks. We could solve the problem by making the protocol more complex. Or we could avoid it. This problem is entirely avoidable. # Matching Inner and Outer Values When we get right down to it, there are a very small number of things that truly change in response to HelloRetryRequest. And all of these changes are to values that do not need confidentiality protection. The draft lists three fields that change: ciphersuites, key_share, and version. From my perspective, changing cipher suites, supported groups, or versions would be a big mistake. So what changes is even more limited. Just the shares in key_share. On this basis, a client that offers cipher suites, groups, versions, and key shares that are identical in both inner and outer ClientHello messages will always receive a HelloRetryRequest that applies equally to both messages. The only adjustment that is acceptable with respect to these fields being identical is the addition of TLS 1.2-only options to the outer ClientHello (or the removal of the same from the inner ClientHello if you prefer it that way around). This is a fine optimization on the basis that accepting ECH represents a commitment to support TLS 1.3 (or higher). But it is really just an optimization (the draft makes this mandatory, which is silly). The client can therefore remove options from the inner ClientHello only if it is impossible to select them with TLS 1.3 or higher. For new extensions, if they define a means of adjustment or correction via HelloRetryRequest (there is currently just one: password_salt, which I haven't examined), then they too need to follow this restriction. It's not an onerous one. Follow this simple constraint and HelloRetryRequest will always apply equally to both inner and outer ClientHello and everything works. Conveniently, this is more or less exactly what the current draft says. Almost. The draft currently allows inner and outer ClientHello to have different types of key share. The way it handles this is terrible: it recommends breaking the transcript. To me, that seems like it would only serve to open the protocol up to downgrade attack. Incidentally, I don't see a problem with having a different key share *value* in inner and outer ClientHello. There's no point in doing that unless you believe that these values leak information (they really shouldn't), but it wouldn't break this model if a client decided to do that. https://github.com/tlswg/draft-ietf-tls-esni/issues/333 appears to be concerned about the cookie only applying to one or other ClientHello. I don't see how is the case, so I'm just going to say that this is fixed by having HelloRetryRequest apply to both inner and outer ClientHello messages. If the client receives HelloRetryRequest that applies to just one of the two, then the problem is that the client is faulty. That would be treated as
Re: [TLS] TLS Opaque
On Tue, Mar 30, 2021 at 9:39 PM Joseph Salowey mailto:j...@salowey.net>> wrote: There is at least one question on the list that has gone unanswered for some time [1]. [1] https://mailarchive.ietf.org/arch/msg/tls/yCBYp10QuYPSu5zOoM3v84SAIZE/ I've found most of the OPAQUE drafts are pretty confusing / incorrect / or typo'd when it comes to lines like these. Describing these calculations seems difficult in ASCII, so I don't fault anyone for making mistakes here. The authors have also been pretty responsive in adding test vectors and such. If the answer is “it’s a typo”, that’s fine – I agree that RFCs are a horrid format for expressing equations. However, it would be good if there were to state what is the correct relationship here (and possibly update the draft with the corrected versions) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Opaque
Sorry, I was thinking of the wrong draft. See: https://tools.ietf.org/html/draft-irtf-cfrg-opaque-03#section-4.2.2 and https://tools.ietf.org/html/draft-irtf-cfrg-opaque-03#appendix-C thanks, Rob On Thu, Apr 1, 2021 at 6:08 AM Scott Fluhrer (sfluhrer) wrote: > > > On Tue, Mar 30, 2021 at 9:39 PM Joseph Salowey wrote: > > > > There is at least one question on the list that has gone unanswered for > some time [1]. > > > > [1] https://mailarchive.ietf.org/arch/msg/tls/yCBYp10QuYPSu5zOoM3v84SAIZE/ > > > > I've found most of the OPAQUE drafts are pretty confusing / incorrect / or > typo'd when it comes to lines like these. Describing these calculations > seems difficult in ASCII, so I don't fault anyone for making mistakes here. > The authors have also been pretty responsive in adding test vectors and > such. > > > > If the answer is “it’s a typo”, that’s fine – I agree that RFCs are a > horrid format for expressing equations. However, it would be good if there > were to state what is the correct relationship here (and possibly update > the draft with the corrected versions) > > > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Opaque
Thanks Bob for pointing to the "real" ongoing specification of OPAQUE in https://tools.ietf.org/html/draft-irtf-cfrg-opaque-03 and its careful specification of OPAQUE-3DH, including test vectors (and sorry Scott for the typos in the other draft). draft-irtf-cfrg-opaque is still work in process and comments on it are welcome. It is intended as a standalone specification of OPAQUE. In contrast, draft-sullivan-tls-opaque-01 is a very preliminary document to show ways in which OPAQUE can be combined within and transported by TLS 1.3, e.g., using the exported authentication mechanisms from draft-ietf-tls-exported-authenticator. It will be developed into a document compatible with the definition of OPAQUE in draft-irtf-cfrg-opaque. Hugo On Thu, Apr 1, 2021 at 10:51 AM Rob Sayre wrote: > Sorry, I was thinking of the wrong draft. See: > > https://tools.ietf.org/html/draft-irtf-cfrg-opaque-03#section-4.2.2 > > and > > https://tools.ietf.org/html/draft-irtf-cfrg-opaque-03#appendix-C > > thanks, > Rob > > > On Thu, Apr 1, 2021 at 6:08 AM Scott Fluhrer (sfluhrer) < > sfluh...@cisco.com> wrote: > >> >> >> On Tue, Mar 30, 2021 at 9:39 PM Joseph Salowey wrote: >> >> >> >> There is at least one question on the list that has gone unanswered for >> some time [1]. >> >> >> >> [1] >> https://mailarchive.ietf.org/arch/msg/tls/yCBYp10QuYPSu5zOoM3v84SAIZE/ >> >> >> >> I've found most of the OPAQUE drafts are pretty confusing / incorrect / >> or typo'd when it comes to lines like these. Describing these calculations >> seems difficult in ASCII, so I don't fault anyone for making mistakes here. >> The authors have also been pretty responsive in adding test vectors and >> such. >> >> >> >> If the answer is “it’s a typo”, that’s fine – I agree that RFCs are a >> horrid format for expressing equations. However, it would be good if there >> were to state what is the correct relationship here (and possibly update >> the draft with the corrected versions) >> >> >> >> >> > ___ > 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] Transport Issues in DTLS 1.3
Folks- I am appending what I sent Martin & Gorry this morning. I looked quite quickly as Martin was looking for quick input. I am happy to iterate if things aren't all that understandable. allman [Quick hit.] I agree with Martin's DISCUSS and Gorry's notes. A couple more things here ... > This spec looks a mess! A generous reading is that this is most of the problem. I think maybe there is some intent in here that isn't stated very well. It needs to be explicit and not as sloppy. A few specific things (in addition to what Gorry said, which I absolutely agree with): - "Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems" + Gorry flagged this and I am flagging it again. If this is something that can lead to serious problems, let's not just leave it to "choice of the implementation". Especially if we have some idea how to make it less problematic. - "Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 [RFC6298])" + I wrote RFC 6298 and I have no idea where this is coming from! + Even if this value of 100msec is OK for DTLS it shouldn't lean on RFC 6298 because RFC 6298 doesn't say that is OK. I.e., the parenthetical is objectively wrong. + RFC 6298 says the INITIAL RTO should be 1sec (point (2.1) in section 2). RFC 8961 affirms this and also says the INITIAL RTO should be 1sec (requirement (1) in section 4). - "Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time-sensitive applications." + Again, this mis-states RFC 6298, which says the initial RTO is 1sec (not 3sec). (Previous to RFC 6298 the initial RTO was 3sec, which is probably where the notion comes from. Most of the purpose of RFC 6298 was to drop the initial RTO to 1sec.) + This is a statement of desire, not any sort of principled justification for using 100msec. At the least this should be much better argued. + To me 100msec feels much too close to the RTT of some network paths to be appropriate here. To be clear, deviations from RFC 8961 that gather consensus are fine, but you should say why that deviation is OK. And, I'd think the further you deviate the more you need to say (for me). I.e., dropping from 1sec to 900msec may not be that big of an issue. But, dropping to 1/10-th of the guideline and to something pretty close to not rare RTTs should require some care and some discussion, IMO. + And, I am not trying to be a picky protocol lawyer and say this document "didn't check the RFC 8085 / RFC 8961 box". Rather, RFC 8085 & 8961 say things for a reason and I don't think we should implicitly ignore them because they come from experience on how to do these sorts of things. - "The retransmit timer expires: the implementation transitions to the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state." + Maybe this is spec sloppiness, but boy does it sound like the recipe TCP used before VJCC to collapse the network. I.e., expire and retransmit the window. Rinse and repeat. It may be the intention is for backoff to be involved. But, that isn't what it says. - “When they have received part of a flight and do not immediately receive the rest of the flight (which may be in the same UDP datagram). A reasonable approach here is to set a timer for 1/4 the current retransmit timer value when the first record in the flight is received and then send an ACK when that timer expires.” + Where does 1/4 come from? Why is it "reasonable"? This just feels like a complete WAG that was pulled out of the air. And, +1 on all the flight size stuff Martin mentioned. allman signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Transport Issues in DTLS 1.3
Hi Ekr! > This means that we have rather more latitude in terms of how > aggressively we retransmit because it only applies to a small > fraction of the traffic. (Strikes me as a bit of a weird formulation.) > Firefox uses 50ms and AIUI Chrome > uses a value derived from the ICE handshake (which is probably > better because there are certainly times where 50ms is too short). Yes- the best thing to do is to use a measured value instead of assuming on static number will always work. But, you have to get a measurement to do that, so you have to start somewhere. >> Relatedly, in section 5.8.3 there is no specific recommendation for a >> maximum flight size at all. I would think that applications SHOULD >> have no more than 10 datagrams outstanding unless it has some OOB >> evidence of available bandwidth on the channel, in keeping with de >> facto transport best practice. > > I agree that this is a reasonable change. I like this, too. I think that limits the impact of any sort of badness. >> Granted, doubling the timeout will reduce the rate, but when >> retransmission is ack-driven there is essentially no reduction of >> sending rate in response to loss. > > I don't believe this is correct. Recall that unlike TCP, there's > generally no buffer of queued packets waiting to be transmitted. > Rather, there is a fixed flight of data which must be delivered. > With one exceptional case [1], an ACK will reflect that some but > not all of the data was delivered and processed; when > retransmitting, the sender will only retransmit the un-ACKed > packets, which naturally reduces the sending rate. Given the quite > small flights in play here, that reduction is likely to be quite > substantial. For instance, if there are three packets and 1 is > ACKed, then there will be a reduction of 1/3. I tend to agree with ekr here. This doesn't tend to worry me greatly. > Note that the timeout is actually only reset after successful loss-free > delivery of a flight: > >Implementations SHOULD retain the current timer value until a >message is transmitted and acknowledged without having to >be retransmitted, at which time the value may be >reset to the initial value. > > There seems to be some confusion here (perhaps due to bad > writing). When the text says "resets the retransmission timer" it > means "re-arm it with the current value" not "re-set it to the > initial default". For instance, suppose that I send flight 1 with > retransmit timer value > T. After T seconds, I have not received anything and so I retransmit > it, doubling to 2T. After I get a response, I now send a new > flight. The timer should be 2T, not T. I agree that is how to manage the timer. > With that said, I think it would be reasonable to re-set to whatever > the measured RTT was, rather than the initial default. This would > avoid potentially resetting to an overly low default (though it's > not clear to me how this could happen because if your RTT estimate > is too low you will never get a delivery without retransmission). That's one problem with a too-low initial RTT and a reason why RFCs 8085 & 8961 use a conservative initial. However, I might suggest not setting the timeout to the measured RTT, but to something based on the measured RTT. The best guidance here (8085 & 8961) is that this value should be based on both the RTT and the variance in the RTT. With one sample you don't have variance. TCP handles this by setting the RTO to 3 times the first measured RTT. That's just old VJCC. It has always struck me as a bit conservative, but ultimately this is a blip in the TCP context and so I have never thought deeply about it. But, perhaps if you did something like 1.5 times the measured RTT you'd account for a bit of variance that will no doubt be present. > On point (1), I think that the fact that we have extensive > deployment of timeout-driven retransmission in the field with > short timers is fairly strong evidence that it will not destroy > the Internet and more generally that the "retransmit the whole > flight" design is safe in this case. I certainly agree that there > might be settings in which 100ms is too short. Rather than > litigate the timer value, which I agree is a judgement call, I > suggest we increase the default somewhat (250? 500) and then > indicate that if the application has information that a shorter > timer is appropriate, it can use one. I think that sounds fine. And, if you could wedge some words about experience into the document that'd seem useful, as well, IMO. > With that said, given that your concern seems to be large flights, > I could maybe live with halving the *window* rather than the size > of the flight. In your example, you suggest an initial window of > 10, so this would give us 10, 5, 3, ... This would have little > practical impact on the vast majority of handshakes, but I suppose > might slightly improve things on the edge cases where you have a > large flight *and* a high
Re: [TLS] Don't Split HelloRetryRequest
Hi Martin, would you mind working out a PR? I think being able to compare 407 to a concrete alternative would be helpful. Just so that we're on the same page, here's a quick summary of the issues that 407 is designed to solve. (These may or may not be problems in your view, and I don't claim this list is exhaustive.) - 233: No acceptance signal until after HRR, so the procedure for computing CH2 is underspecified. This can be avoided by advertising the same preferences in CHI/CHO, but the spec doesn't require this. - 373: To fix 3233, can we put an acceptance signal in HRR.random? Probably not, since HRR.random has a value specified in RFC8446. - 358: RFC8446 allows the value of an extension in CH2 to differ from CH1 only if the extension appears in HRR. - 333: "Split mode" is broken, since the client doesn't know who the cookie is for. Best, Chris P. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Don't Split HelloRetryRequest
Given the range of Martin's comments, I'd be surprised if that could be reduced to a PR;-) But let me ask a question meanwhile - how often does HRR actually happen and could we not just let ECH fail in a bunch of situations that would otherwise require all this new complexity? Thanks, S. On 01/04/2021 18:29, Christopher Patton wrote: Hi Martin, would you mind working out a PR? I think being able to compare 407 to a concrete alternative would be helpful. Just so that we're on the same page, here's a quick summary of the issues that 407 is designed to solve. (These may or may not be problems in your view, and I don't claim this list is exhaustive.) - 233: No acceptance signal until after HRR, so the procedure for computing CH2 is underspecified. This can be avoided by advertising the same preferences in CHI/CHO, but the spec doesn't require this. - 373: To fix 3233, can we put an acceptance signal in HRR.random? Probably not, since HRR.random has a value specified in RFC8446. - 358: RFC8446 allows the value of an extension in CH2 to differ from CH1 only if the extension appears in HRR. - 333: "Split mode" is broken, since the client doesn't know who the cookie is for. Best, Chris P. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-les-white-tls-preferred-pronouns
The Internet Engineering Task Force (IETF) prides itself on its open philosophy, where anyone can submit a proposal or comment on work in progress, regardless of financial resources, industry credentials, race, gender, sexual orientation, or national origin, without any review by the organization. Regrettably, sometimes individuals abuse that openness by submitting texts that are disrespectful of others, in violation of the IETF Code of Conduct [1] and anti-harassment policy [2]. On 1 April 2021, there were two examples of anonymous proposals that were both racist and deeply disrespectful, thus violating policy. The Internet Engineering Steering Group (IESG) has accordingly removed these documents from the IETF website. Lars Eggert IETF Chair, on behalf of the IESG [1] https://www.rfc-editor.org/rfc/rfc7154.html [2] https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Don't Split HelloRetryRequest
> But let me ask a question meanwhile - how often does HRR > actually happen and could we not just let ECH fail in a > bunch of situations that would otherwise require all this > new complexity? > One way HRR is used is in case the client's and server's cipher suite preferences don't intersect. This feature is an essential part of TLS, as there's no a priori reason why the client and server will initially advertise overlapping preferences. (They usually do, hence the claim that HRR is rare.) I don't think aborting the handshake instead of HRR is an acceptable solution, as this would mean there are deployments with which TLS couldn't be used. Chris P. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Don't Split HelloRetryRequest
One way HRR is used is in case the client's and server's cipher suite > preferences don't intersect. This feature is an essential part of TLS, as > there's no a priori reason why the client and server will initially > advertise overlapping preferences. (They usually do, hence the claim that > HRR is rare.) I don't think aborting the handshake instead of HRR is an > acceptable solution, as this would mean there are deployments with which > TLS couldn't be used. > Slight refinement: David B. pointed out to me that "cipher suite preference" isn't quite the right term here. The client provides key shares in its CH that it guesses the server can use; if it's wrong, then the server replies with HRR. A more accurate statement would be that "HRR is essential for ensuring the client sends a key share the server supports." ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-les-white-tls-preferred-pronouns
Thank you! > On Apr 1, 2021, at 11:13 AM, Lars Eggert wrote: > > The Internet Engineering Task Force (IETF) prides itself on its open > philosophy, where anyone can submit a proposal or comment on work in > progress, regardless of financial resources, industry credentials, race, > gender, sexual orientation, or national origin, without any review by the > organization. Regrettably, sometimes individuals abuse that openness by > submitting texts that are disrespectful of others, in violation of the IETF > Code of Conduct [1] and anti-harassment policy [2]. > > On 1 April 2021, there were two examples of anonymous proposals that were > both racist and deeply disrespectful, thus violating policy. The Internet > Engineering Steering Group (IESG) has accordingly removed these documents > from the IETF website. > > Lars Eggert > IETF Chair, on behalf of the IESG > > [1] https://www.rfc-editor.org/rfc/rfc7154.html > [2] https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/ > > ___ > 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] Don't Split HelloRetryRequest
Hiya, On 01/04/2021 19:13, Christopher Patton wrote: But let me ask a question meanwhile - how often does HRR actually happen and could we not just let ECH fail in a bunch of situations that would otherwise require all this new complexity? One way HRR is used is in case the client's and server's cipher suite preferences don't intersect. This feature is an essential part of TLS, as there's no a priori reason why the client and server will initially advertise overlapping preferences. (They usually do, hence the claim that HRR is rare.) I've seen that claim and kinda suspect it's valid but my question was whether anyone had measured it? I don't think aborting the handshake instead of HRR is an acceptable solution, as this would mean there are deployments with which TLS couldn't be used. No. At worst it might mean that there are places that need to do some config before TLS+ECH will work, but that's true already - they'll need to publish an ECHConfig anyway. I really wonder if we could not achieve as good an outcome much more easily with some guidance on checking your front- end's choice of curves and failing when some of the HRR cases get out of whack. (There'd still be some work to do for ECH as we can't as you say get rid of HRR, but there might be a lot less work/complexity.) Cheers, S. Chris P. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-les-white-tls-preferred-pronouns
Gosh, and here I was addressing Peter Gutman's comments. Oh well. --Les; Sent: Thursday, April 01, 2021 at 11:13 AM From: "Lars Eggert" To: tls@ietf.org Subject: Re: [TLS] draft-les-white-tls-preferred-pronouns The Internet Engineering Task Force (IETF) prides itself on its open philosophy, where anyone can submit a proposal or comment on work in progress, regardless of financial resources, industry credentials, race, gender, sexual orientation, or national origin, without any review by the organization. Regrettably, sometimes individuals abuse that openness by submitting texts that are disrespectful of others, in violation of the IETF Code of Conduct [1] and anti-harassment policy [2]. On 1 April 2021, there were two examples of anonymous proposals that were both racist and deeply disrespectful, thus violating policy. The Internet Engineering Steering Group (IESG) has accordingly removed these documents from the IETF website. Lars Eggert IETF Chair, on behalf of the IESG [1] https://www.rfc-editor.org/rfc/rfc7154.html [2] https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/ ___ 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] Don't Split HelloRetryRequest
> I absolutely agree both that we seem to be almost > happily adding complexity I don't think you have to assume bad intent (or negligence). Several people brought up valid concerns and we're trying to address them. > On Apr 1, 2021, at 4:46 AM, Stephen Farrell wrote: > > > I'm not sure I agree with all of Martin's remarks below, > but I absolutely agree both that we seem to be almost > happily adding complexity and that that's a bad plan. > > S. > > On 01/04/2021 02:57, Martin Thomson wrote: >> I just reviewed the proposal to split HelloRetryRequest into outer and >> (encrypted) inner. >> https://github.com/tlswg/draft-ietf-tls-esni/pull/407/files >> I'm strongly opposed to taking the change. It complicates the design >> greatly and unnecessarily. >> The existing design has some flaws, but they can be fixed more elegantly >> than this. >> (Apologies if this seems a little long. I'm writing down every possible >> argument I can think of, because I can't guarantee that I will be coherent >> at the meeting.) >> # HelloRetryRequest Has a Narrow Purpose >> Let's first address the key question of what HelloRetryRequest exists to do. >> It exists to ensure that the client and server are able to jointly agree on >> keys to use for the remainder of the handshake. This is a very narrow scope. >> Furthermore, the particulars of key agreement are public. This is important >> as we can also say that all hidden servers need to use the same >> configuration as it relates to cipher suites, key exchange, and related >> parameters, as the results of negotiation are sent in the clear in the >> ServerHello. >> My claim here is that there is no value in protecting any parameter that >> might change in response to HelloRetryRequest. >> # Don't Seek Complexity >> It is entirely possible to imagine scenarios where an inner ClientHello has >> different preferences from an outer ClientHello. While in theory we can >> construct a design that would support that (the pull request does this well >> enough), to do so only serves to increase complexity. It does not address >> any real use case or problem that I'm aware of. >> If we allow for the client to provide different values in inner and outer >> ClientHello messages, then the current design means that the client is faced >> with some ambiguity about which of the two messages a HelloRetryRequest >> applies to. If we try to create an indicator, then that leaks. >> We could solve the problem by making the protocol more complex. Or we could >> avoid it. >> This problem is entirely avoidable. >> # Matching Inner and Outer Values >> When we get right down to it, there are a very small number of things that >> truly change in response to HelloRetryRequest. And all of these changes are >> to values that do not need confidentiality protection. >> The draft lists three fields that change: ciphersuites, key_share, and >> version. From my perspective, changing cipher suites, supported groups, or >> versions would be a big mistake. So what changes is even more limited. >> Just the shares in key_share. >> On this basis, a client that offers cipher suites, groups, versions, and key >> shares that are identical in both inner and outer ClientHello messages will >> always receive a HelloRetryRequest that applies equally to both messages. >> The only adjustment that is acceptable with respect to these fields being >> identical is the addition of TLS 1.2-only options to the outer ClientHello >> (or the removal of the same from the inner ClientHello if you prefer it that >> way around). This is a fine optimization on the basis that accepting ECH >> represents a commitment to support TLS 1.3 (or higher). But it is really >> just an optimization (the draft makes this mandatory, which is silly). The >> client can therefore remove options from the inner ClientHello only if it is >> impossible to select them with TLS 1.3 or higher. >> For new extensions, if they define a means of adjustment or correction via >> HelloRetryRequest (there is currently just one: password_salt, which I >> haven't examined), then they too need to follow this restriction. It's not >> an onerous one. >> Follow this simple constraint and HelloRetryRequest will always apply >> equally to both inner and outer ClientHello and everything works. >> Conveniently, this is more or less exactly what the current draft says. >> Almost. >> The draft currently allows inner and outer ClientHello to have different >> types of key share. The way it handles this is terrible: it recommends >> breaking the transcript. To me, that seems like it would only serve to open >> the protocol up to downgrade attack. >> Incidentally, I don't see a problem with having a different key share >> *value* in inner and outer ClientHello. There's no point in doing that >> unless you believe that these values leak information (they really >> shouldn't), but it wouldn't break this model if a c
Re: [TLS] Don't Split HelloRetryRequest
Hiya, On 01/04/2021 19:28, Carrick Bartle wrote: I absolutely agree both that we seem to be almost happily adding complexity I don't think you have to assume bad intent (or negligence). Several people brought up valid concerns and we're trying to address them. Hmm. I got an offlist mail on that too. I'm sorry if I gave the impression that people's intentions were dodgy, that really wasn't my intent. I think it's entirely possible to have the best intentions and yet to be too happy to add complexity. I've done it myself loads of times in the past, and there are even RFCs that show that;-) That is what I think may be happening wrt ECH - we seem to be forgetting that this stuff is inherently complex, even in it's simplest case, and making it more complex could kill it. Cheers, S. On Apr 1, 2021, at 4:46 AM, Stephen Farrell wrote: I'm not sure I agree with all of Martin's remarks below, but I absolutely agree both that we seem to be almost happily adding complexity and that that's a bad plan. S. On 01/04/2021 02:57, Martin Thomson wrote: I just reviewed the proposal to split HelloRetryRequest into outer and (encrypted) inner. https://github.com/tlswg/draft-ietf-tls-esni/pull/407/files I'm strongly opposed to taking the change. It complicates the design greatly and unnecessarily. The existing design has some flaws, but they can be fixed more elegantly than this. (Apologies if this seems a little long. I'm writing down every possible argument I can think of, because I can't guarantee that I will be coherent at the meeting.) # HelloRetryRequest Has a Narrow Purpose Let's first address the key question of what HelloRetryRequest exists to do. It exists to ensure that the client and server are able to jointly agree on keys to use for the remainder of the handshake. This is a very narrow scope. Furthermore, the particulars of key agreement are public. This is important as we can also say that all hidden servers need to use the same configuration as it relates to cipher suites, key exchange, and related parameters, as the results of negotiation are sent in the clear in the ServerHello. My claim here is that there is no value in protecting any parameter that might change in response to HelloRetryRequest. # Don't Seek Complexity It is entirely possible to imagine scenarios where an inner ClientHello has different preferences from an outer ClientHello. While in theory we can construct a design that would support that (the pull request does this well enough), to do so only serves to increase complexity. It does not address any real use case or problem that I'm aware of. If we allow for the client to provide different values in inner and outer ClientHello messages, then the current design means that the client is faced with some ambiguity about which of the two messages a HelloRetryRequest applies to. If we try to create an indicator, then that leaks. We could solve the problem by making the protocol more complex. Or we could avoid it. This problem is entirely avoidable. # Matching Inner and Outer Values When we get right down to it, there are a very small number of things that truly change in response to HelloRetryRequest. And all of these changes are to values that do not need confidentiality protection. The draft lists three fields that change: ciphersuites, key_share, and version. From my perspective, changing cipher suites, supported groups, or versions would be a big mistake. So what changes is even more limited. Just the shares in key_share. On this basis, a client that offers cipher suites, groups, versions, and key shares that are identical in both inner and outer ClientHello messages will always receive a HelloRetryRequest that applies equally to both messages. The only adjustment that is acceptable with respect to these fields being identical is the addition of TLS 1.2-only options to the outer ClientHello (or the removal of the same from the inner ClientHello if you prefer it that way around). This is a fine optimization on the basis that accepting ECH represents a commitment to support TLS 1.3 (or higher). But it is really just an optimization (the draft makes this mandatory, which is silly). The client can therefore remove options from the inner ClientHello only if it is impossible to select them with TLS 1.3 or higher. For new extensions, if they define a means of adjustment or correction via HelloRetryRequest (there is currently just one: password_salt, which I haven't examined), then they too need to follow this restriction. It's not an onerous one. Follow this simple constraint and HelloRetryRequest will always apply equally to both inner and outer ClientHello and everything works. Conveniently, this is more or less exactly what the current draft says. Almost. The draft currently allows inner and outer ClientHello to have different types of key share. The way it handles this is terrible: it recommends breaking the transcript. To me, that seems like it would o
Re: [TLS] Reminder ECH Interim Thursday 4/1
Also additional meeting information is available here: https://datatracker.ietf.org/meeting/upcoming On Wed, Mar 31, 2021 at 9:03 PM Joseph Salowey wrote: > The Transport Layer Security (tls) WG will hold a virtual interim meeting on > 2021-04-01 from 12:00 to 13:00 America/Los_Angeles (19:00 to 20:00 UTC). > > Agenda: > Work on Resolving open ECH Issues > https://github.com/tlswg/draft-ietf-tls-esni/issues > > > Information about remote > participation:https://ietf.webex.com/ietf/j.php?MTID=m84a93a2ceeeb3de64a70c45025be9d0b > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Don't Split HelloRetryRequest
Hi Martin, Thanks for the comments. As the author of #374, I obviously didn't think it so clearly unnecessary, but glad to hear your thoughts. Hopefully we can get on the same page as to what the issues are and/or a better solution. (Always happy to replace something with a simpler option, provided it also works!) To that end, I'd second Chris's suggestion of working through an alternate PR so we have something concrete. Going through some of these in detail (inline) On Wed, Mar 31, 2021 at 9:58 PM Martin Thomson wrote: > # Matching Inner and Outer Values > > When we get right down to it, there are a very small number of things that > truly change in response to HelloRetryRequest. And all of these changes > are to values that do not need confidentiality protection. > > The draft lists three fields that change: ciphersuites, key_share, and > version. From my perspective, changing cipher suites, supported groups, or > versions would be a big mistake. So what changes is even more limited. > Just the shares in key_share. > > On this basis, a client that offers cipher suites, groups, versions, and > key shares that are identical in both inner and outer ClientHello messages > will always receive a HelloRetryRequest that applies equally to both > messages. > > The only adjustment that is acceptable with respect to these fields being > identical is the addition of TLS 1.2-only options to the outer ClientHello > (or the removal of the same from the inner ClientHello if you prefer it > that way around). This is a fine optimization on the basis that accepting > ECH represents a commitment to support TLS 1.3 (or higher). But it is > really just an optimization (the draft makes this mandatory, which is > silly). The client can therefore remove options from the inner ClientHello > only if it is impossible to select them with TLS 1.3 or higher. > > For new extensions, if they define a means of adjustment or correction via > HelloRetryRequest (there is currently just one: password_salt, which I > haven't examined), then they too need to follow this restriction. It's > not an onerous one. > > Follow this simple constraint and HelloRetryRequest will always apply > equally to both inner and outer ClientHello and everything works. > Conveniently, this is more or less exactly what the current draft says. > Almost. > This was a previous attempt at this, but it seems to have been confusing. I do agree that having ClientHelloInner vs ClientHelloOuter differences that result in different HelloRetryRequest acceptance criteria is a bad plan: in general, I think a client implementation should be judicious about which difference it exposes because each difference needs special logic to make sure it's using the right set as you evaluate the handshake. At the same time, I worry that *mandating* it in the extension will make this decision process tricky to navigate and get us in a rough corner. PR #316 was trying to capture exactly this, but it seems we didn't get on the same page. (Maybe we can now?) See this discussion: https://github.com/tlswg/draft-ietf-tls-esni/pull/316#discussion_r509880007 And so the text ended up with something self-contradictory. It says: "[...] clients offering ECH MUST ensure that all extensions or parameters that might change in response to receiving a HelloRetryRequest have the same values in ClientHelloInner and ClientHelloOuter." https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-handling-helloretryrequest And then it goes to list things that differ from this criteria! Indeed the list is right and the criteria is wrong. The criteria is neither sufficient (we do need cipher suites to align), nor sufficient (as you note, the key share *values* don't strictly need to match). I concluded from this exercise that trying to formulate the rules is a bit of a mess. As you allude to with password_salt, we need to formulate something that can capture future HRR extensions. (I'd also gotten that sense from one of the past WG meetings: land the HRR-matching rule as a bandaid, but we didn't have consensus for it as an actual solution.) I actually had not heard of password_salt, so thanks for the pointer. I've only skimmed it but, at a glance, this seems exactly like something where you'd want ClientHelloInner vs ClientHelloOuter to differ. It seems to be about some password-based TLS authentication, but any client authentication should only apply to the true ClientHelloInner handshake and not the fallback ClientHelloOuter handshake. > The draft currently allows inner and outer ClientHello to have different > types of key share. The way it handles this is terrible: it recommends > breaking the transcript. To me, that seems like it would only serve to > open the protocol up to downgrade attack. > I'm not sure I follow this point. Do you mean the draft as-is, or the PR? I don't believe the draft as-is does, and I don't think the PR does anything to the transcript that draft as-is d
Re: [TLS] Don't Split HelloRetryRequest
Hiya, On 01/04/2021 19:24, Stephen Farrell wrote: some guidance on checking your front- end's choice of curves and failing when some of the HRR cases get out of whack Actually it occurs to me that we could for example say that back-ends are RECOMMENDED to support the first curve listed in ECHConfig for both ECH and the TLS h/s and then also RECOMMEND that clients include a key share for that curve as well. With that, it might be acceptable to not use HRR (but fail) if the inner CH has no key shares that the back-end can handle. Things like that might reduce the number of HRR cases we need to handle via new protocol mechanisms. S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Don't Split HelloRetryRequest
I'm going to briefly respond, but as this is a public holiday and I have no real desire to work too much, please forgive any radio silence that follows. On Fri, Apr 2, 2021, at 05:56, David Benjamin wrote: > This was a previous attempt at this, but it seems to have been confusing. > > I do agree that having ClientHelloInner vs ClientHelloOuter differences > that result in different HelloRetryRequest acceptance criteria is a bad > plan: in general, I think a client implementation should be judicious > about which difference it exposes because each difference needs special > logic to make sure it's using the right set as you evaluate the > handshake. > > At the same time, I worry that *mandating* it in the extension will > make this decision process tricky to navigate and get us in a rough > corner. PR #316 was trying to capture exactly this, but it seems we > didn't get on the same page. (Maybe we can now?) See this discussion: > https://github.com/tlswg/draft-ietf-tls-esni/pull/316#discussion_r509880007 My claim (to be verified) is that mandating something is possible. It might not require a simple rule (cannot be different); it might instead require that each extension be analyzed and have its own rules instead. I'm confident that for the 4 or so extensions that can change in response to HRR, we can make that work. > > The draft currently allows inner and outer ClientHello to have different > > types of key share. The way it handles this is terrible: it recommends > > breaking the transcript. To me, that seems like it would only serve to > > open the protocol up to downgrade attack. > > I'm not sure I follow this point. Do you mean the draft as-is, or the > PR? I don't believe the draft as-is does, and I don't think the PR does > anything to the transcript that draft as-is doesn't already do. The > transcript behaviors are largely forced by a combination of backwards > compatibility for ClientHelloOuter and split mode for ClientHelloInner. I refer to this, which I would propose be cut: > Note: if ClientHelloOuter and ClientHelloInner use different groups for their > key shares or differ in some other way, then the HelloRetryRequest may > actually be invalid for one or the other ClientHello, in which case a fresh > ClientHello MUST be generated, ignoring the instructions in > HelloRetryRequest. -- https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#section-6.1.4-4 > I think you may have misunderstood #333. That or I'm misunderstanding > your response. Imagine a client-facing server that wants to support HRR > statelessly. When that client-facing server accepts ECH and gets an HRR > from the backend server to forward, it has no opportunity to inject its > own cookie. Yeah, I missed that distinction. Let's not support that. If the client-facing server wants to forward AND use the cookie to route the second ClientHello without maintaining state, let it coordinate with the hidden server. > In terms of sticking out, Ben Schwartz also pointed out another issue > with the current situation. It's not just that, where HelloRetryRequest > occurs naturally, this quirk reveals GREASE. A forged HelloRetryRequest > also reveals GREASE. This PR resolves this by authenticating the ECH > acceptance signal in HelloRetryRequest. Yeah, that leaks that grease happened. We can thank those who were overzealous in their interpretation of the rules in RFC 8446. Either way, this style of attack doesn't really bother me that much as it is very obvious and requires active interception. > I'd be very interested to understand the architectural constraints > here. This didn't seem likely to be particularly challenging to > implement, but I only know our own stack and certainly could have > mispredicted. As I said in the meeting. HRR only has limited battle testing in practice, this would be even less tested, but far more complex. Anything we can do to limit complexity, even at the cost of more complex analysis, is worth doing in my opinion. There is only one analysis we need to do for the specification, but (hopefully) multiple implementations. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-les-white-tls-preferred-pronouns
On Thu, Apr 1, 2021 at 11:21 AM Carrick Bartle wrote: > Thank you! > Yes, thank you. And, also thanks for doing useful engineering such as https://github.com/NTAP/quant. Maybe the IESG should consider deleting the IETF general list. I know this list isn't the right venue to debate that idea, but I do not regret unsubscribing long before this incident. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Additional ECH PRs
Hi folks, This pile of PRs was skipped during the interim today. They should be mostly ready to go: - https://github.com/tlswg/draft-ietf-tls-esni/pull/415 - https://github.com/tlswg/draft-ietf-tls-esni/pull/414 - https://github.com/tlswg/draft-ietf-tls-esni/pull/411 - https://github.com/tlswg/draft-ietf-tls-esni/pull/410 - https://github.com/tlswg/draft-ietf-tls-esni/pull/409 - https://github.com/tlswg/draft-ietf-tls-esni/pull/382 Please have a look and provide feedback. We'd like to merge in the next week or so. Thanks! Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
