Re: [TLS] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?
> I forget, did we need to bind it to the actual handshake secret, or was > the transcript and ClientHelloInner.random sufficient? That would avoid the > circular processing dependency. > As I recall, it was decided to bind the acceptance signal to the handshake signal in order to mitigate some specific, active, "don't-stick-out" attacks. Chris P. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?
On 3/18/2021 7:35 AM, Christopher Patton wrote: I forget, did we need to bind it to the actual handshake secret, or was the transcript and ClientHelloInner.random sufficient? That would avoid the circular processing dependency. As I recall, it was decided to bind the acceptance signal to the handshake signal in order to mitigate some specific, active, "don't-stick-out" attacks. The specific suggestion to tie the acceptance signal to the handshake secret was made I believe to simplify the security analysis. There are a variety of attacks in which a man in the middle can play games with specific extensions. Tying the signal to the handshake secret provides a robust defense against such games, and simplifies the analysis of the security properties. It also has nice 'don't stick out' properties, but those are not the only reasons. -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?
Hiya, On 18/03/2021 16:55, Christian Huitema wrote: On 3/18/2021 7:35 AM, Christopher Patton wrote: I forget, did we need to bind it to the actual handshake secret, or was the transcript and ClientHelloInner.random sufficient? That would avoid the circular processing dependency. As I recall, it was decided to bind the acceptance signal to the handshake signal in order to mitigate some specific, active, "don't-stick-out" attacks. The specific suggestion to tie the acceptance signal to the handshake secret was made I believe to simplify the security analysis. There are a variety of attacks in which a man in the middle can play games with specific extensions. I missed the bit that allowed extension-specific games - can you point me at that? Tying the signal to the handshake secret provides a robust defense against such games, and simplifies the analysis of the security properties. It also has nice 'don't stick out' properties, but those are not the only reasons. And one consequence is that you end up doing more or less all the work of trial decryption to handle the case where the wrong ECHConfig was used by the client. If we do stick with wanting that binding then I think it may be cleaner to actually just do the trial decryption (of an encrypted extension like the earlier nonce) and then declare victory or fallback to checking the outer after that - at least in that case one can expect to be able to use existing code more easily and with less liklihood of breaking things or leaving leaks. Or, and maybe even better, think again about those attacks and see if they can be avoided without the handshake-secret, or if they still seem compelling enough to justify the awkward consequences. Cheers, S. PS: An aside - I reckon it's too late to try not stick out with the server hello - the client hello has given the game away lready. That's a bummer really but I think it's game- over for that entry on the wishlist with ECH. -- Christian Huitema ___ 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] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?
On 3/18/2021 10:24 AM, Stephen Farrell wrote: Hiya, On 18/03/2021 16:55, Christian Huitema wrote: On 3/18/2021 7:35 AM, Christopher Patton wrote: I forget, did we need to bind it to the actual handshake secret, or was the transcript and ClientHelloInner.random sufficient? That would avoid the circular processing dependency. As I recall, it was decided to bind the acceptance signal to the handshake signal in order to mitigate some specific, active, "don't-stick-out" attacks. The specific suggestion to tie the acceptance signal to the handshake secret was made I believe to simplify the security analysis. There are a variety of attacks in which a man in the middle can play games with specific extensions. I missed the bit that allowed extension-specific games - can you point me at that? Tying the signal to the handshake secret provides a robust defense against such games, and simplifies the analysis of the security properties. It also has nice 'don't stick out' properties, but those are not the only reasons. And one consequence is that you end up doing more or less all the work of trial decryption to handle the case where the wrong ECHConfig was used by the client. If we do stick with wanting that binding then I think it may be cleaner to actually just do the trial decryption (of an encrypted extension like the earlier nonce) and then declare victory or fallback to checking the outer after that - at least in that case one can expect to be able to use existing code more easily and with less liklihood of breaking things or leaving leaks. I agree that you have a strong argument there, Stephen, one that was not developed during the discussion on the mailing list and on GitHub. If I paraphrase, trial decryption has two big components: first computing the master secret based on the trial hypothesis, and then deriving the handshake key and verifying whether it actually decrypts the server's message. You measure that most of the work is done when "computing the master secret". If the hint depends on the master secret, then there is little difference in cost between "computing the master secret and checking the hint" versus "computing the master secret and trying to decrypt the message". We could just as well do trial decryption. Well, OK. That's exactly the kind of things that we learn from doing implementations. That means we should either go for a much simpler hint of acceptance, or just be happy with trial decryption. There were a bunch of options reviewed in GitHub issue #274 (https://github.com/tlswg/draft-ietf-tls-esni/issues/274). Should we reopen that discussion? Or, and maybe even better, think again about those attacks and see if they can be avoided without the handshake-secret, or if they still seem compelling enough to justify the awkward consequences. I think that the requirements are to (1) make sure that the hint proves that the server properly decoded the ECH data and (2) make sure that the hint is different for every attempt. The embedding in the server random is probably the only option, given that TLS 1.3 very much restricts the number of unencrypted extensions in the Server Hello. Cheers, S. PS: An aside - I reckon it's too late to try not stick out with the server hello - the client hello has given the game away lready. That's a bummer really but I think it's game- over for that entry on the wishlist with ECH. Yes. We have to rely on effective greasing. I don't have a great confidence in that. -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?
On Thu, Mar 18, 2021 at 2:56 PM Christian Huitema wrote: > > On 3/18/2021 10:24 AM, Stephen Farrell wrote: > > > > Hiya, > > > > On 18/03/2021 16:55, Christian Huitema wrote: > >> On 3/18/2021 7:35 AM, Christopher Patton wrote: > >> > I forget, did we need to bind it to the actual handshake secret, or > was > the transcript and ClientHelloInner.random sufficient? That would > avoid the > circular processing dependency. > > >>> As I recall, it was decided to bind the acceptance signal to the > >>> handshake > >>> signal in order to mitigate some specific, active, "don't-stick-out" > >>> attacks. > >> > >> The specific suggestion to tie the acceptance signal to the handshake > >> secret was made I believe to simplify the security analysis. There > >> are a variety of attacks in which a man in the middle can play games > >> with specific extensions. > > > > I missed the bit that allowed extension-specific games - can > > you point me at that? > > > >> Tying the signal to the handshake secret provides a robust defense > >> against such games, and simplifies the analysis of the security > >> properties. It also has nice 'don't stick out' properties, but those > >> are not the only reasons. > > > > And one consequence is that you end up doing more or less > > all the work of trial decryption to handle the case where > > the wrong ECHConfig was used by the client. If we do stick > > with wanting that binding then I think it may be cleaner to > > actually just do the trial decryption (of an encrypted > > extension like the earlier nonce) and then declare victory > > or fallback to checking the outer after that - at least in > > that case one can expect to be able to use existing code more > > easily and with less liklihood of breaking things or leaving > > leaks. > > I agree that you have a strong argument there, Stephen, one that was not > developed during the discussion on the mailing list and on GitHub. If I > paraphrase, trial decryption has two big components: first computing the > master secret based on the trial hypothesis, and then deriving the > handshake key and verifying whether it actually decrypts the server's > message. You measure that most of the work is done when "computing the > master secret". If the hint depends on the master secret, then there is > little difference in cost between "computing the master secret and > checking the hint" versus "computing the master secret and trying to > decrypt the message". We could just as well do trial decryption. > > Well, OK. That's exactly the kind of things that we learn from doing > implementations. That means we should either go for a much simpler hint > of acceptance, or just be happy with trial decryption. There were a > bunch of options reviewed in GitHub issue #274 > (https://github.com/tlswg/draft-ietf-tls-esni/issues/274). Should we > reopen that discussion? > I don't think I'd agree that *most* of the work is in the secret computation per se. Actually doing trial decryption with the secret requires reaching down into the record layer. This is especially onerous for QUIC, where the record layer is offloaded to another protocol (often outside the TLS library). I think going back to full trial decryption would still considerably increase the cost of implementing ECH over the current draft. That said, I do agree that even the first part seems more onerous than expected and it's worth reconsidering things. We switched using just the randoms to the full handshake secret to mitigate some issues. Perhaps there's an intermediate point that still mitigates those issues but avoids the expensive part of the secret computation? What if we kept the ClientHelloInner...ServerHelloECHConf transcript as in the current draft, but derived the signal exclusively from that? (Or from the client random and that transcript, though the transcript includes the client random anyway.) We'll still bind in the ServerHello extensions, and it still includes the encrypted inner ClientHello random, as in the randoms formulation. It doesn't do the job as clearly as the handshake secret did, but maybe it'll work? Implementation-wise, this variant would not require actually processing the ServerHello extensions. David > > Or, and maybe even better, think again about those attacks > > and see if they can be avoided without the handshake-secret, > > or if they still seem compelling enough to justify the awkward > > consequences. > > I think that the requirements are to (1) make sure that the hint proves > that the server properly decoded the ECH data and (2) make sure that the > hint is different for every attempt. The embedding in the server random > is probably the only option, given that TLS 1.3 very much restricts the > number of unencrypted extensions in the Server Hello. > > > > > > Cheers, > > S. > > > > PS: An aside - I reckon it's too late to try not stick out > > with the server hello - the client hello has given the game > > away lready
Re: [TLS] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?
Hiya, On 18/03/2021 19:17, David Benjamin wrote: I don't think I'd agree that *most* of the work is in the secret > computation per se. Actually doing trial decryption with > the secret requires reaching down into the record layer. > This is especially onerous for QUIC, where the record layer > is offloaded to another protocol (often outside the TLS > library). Ah, fair point - I've not looked at QUIC at all. But how are encrypted extensions and tickets handled in such cases? If those are handled in the original library then a trial decryption should be possible too maybe? What if we kept the ClientHelloInner...ServerHelloECHConf transcript as in the current draft, but derived the signal exclusively from that? (Or from the client random and that transcript, though the transcript includes the client random anyway.) We'll still bind in the ServerHello extensions, and it still includes the encrypted inner ClientHello random, as in the randoms formulation. It doesn't do the job as clearly as the handshake secret did, but maybe it'll work? Implementation-wise, this variant would not require actually processing the ServerHello extensions. Right - if that's ok security-wise then it'd be fine for implementation, better than either the current approach or full trial decryption. We could I suppose consider just keeping the current expand/extract construct but replacing the handshake-secret with something else based just on that same input buffer. Cheers, 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
