[TLS] Re: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt
Hi Peter, I think there's a misunderstanding. My response to your original question on what assumption one needs to make on the PQ KEM to be able to reuse the argument in [DOWLING] was "none", in the following sense: If you're _only_ after the classic security shown in [DOWLING], then there's no additional assumption needed. That is, I think the [DOWLING] result can be adapted to hold, assuming the DH component is strong. Note that this argument is _not_ via IND-CCA security of some combiner KEM, but following the current proof. That is, relying directly on PRF-ODH and then key derivation (which includes the transcript, and hence also the possibly modified PQ KEM ciphertext), ensuring separated keys. It seems you understood my response as "the [DOWLING] results hold with a combiner KEM". That's indeed _not_ the case, in particular because this result doesn't use a KEM/IND-CCA type assumption, so one can't hope to just plug in such assumption for the result to still go through. And I agree with your assessment, that a K = KDF(ss_pq || ss_ec) KEM combiner step would itself not achieve IND-CCA security. As you write, one could modify the PQ ciphertext without changing ss_pq, violating that property. (This is in line with [GIACON] including the ciphertexts in the key derivation.) Even then, the raw ss_ec is not an IND-CCA KEM secret. So showing results based on KEM assumptions here requires working out more analysis details. I hope this clarifies things a little? Best, Felix On 2024-08-20 13:02 +0200, Peter C wrote: Felix, I definitely don't understand something here, so I have tried to abstract things slightly to try to illustrate why I think there might still be an issue. I'm reasonably (but not completely) confident that I haven't abstracted away anything significant. Apologies if I've missed something important. Consider the PQ/ECDH hybrid KEM where the KEM combiner is K = KDF(ss_pq || ss_ec). I think you are essentially arguing that an adversary A that breaks the IND-CCA2 security of the hybrid KEM can be converted into an adversary B that breaks something like PRF-ODH security for the ECDH component. IND-CCA2 is the usual notion. PRF-ODH might need a little explanation in this case. I think it needs to be along the following lines: - The adversary selects ss*_pq for the challenger. - The challenger chooses an ECDH key pair (sk*_ec, pk*_ec) and "ciphertext" ct*_ec, and computes K*_0 = KDF(ss*_pq || ss*_ec) with the corresponding ECDH shared secret ss*_ec. The challenger also chooses a random K*_1 and sets K* = K_b for a random bit b. - The adversary is given the public key pk*_ec, ciphertext ct*_ec, and key K*, and can query an oracle with (ss_pq, ct_ec) =/= (ss*_pq, ct*_ec) to get K = KDF(ss_pq || ss_ec). I agree that adversary B can embed a PRF-ODH challenge into an IND-CCA2 challenge for adversary A. B chooses a PQ key pair (sk*_pq, pk*_pq) and ciphertext ct*_pq, computes the PQ shared secret ss*_pq and uses ss*_pq to request pk*_ec, ct*_ec and K* from the PRF-ODH challenger. The corresponding IND-CCA2 challenge will be the public key (pk*_pq, pk*_ec), ciphertext (ct*_pq, ct*_ec) and key K*. I also agree that B can simulate (to some extent) the decapsulation oracle. Given a query (ct_pq, ct_ec) =/= (ct*_pq, ct*_ec) from A, B uses sk*_pq to compute the PQ shared secret ss_pq, queries the PRF-ODH oracle with (ss_pq, ct_ec) and returns the response to A. In the case of a query (ct_pq, ct*_ec) where ct_pq =/= ct*_pq but ss_pq = ss*_pq, B can indeed identify this and adjust, say, by returning the challenge key K*. I think the issue is that by handling invalid PRF-ODH queries in this way, adversary B may not be able to use adversary A to break PRF-ODH. If the PQ KEM is appropriately weak, then a perfectly reasonable approach to breaking IND-CCA2 for the hybrid KEM is to find a second PQ ciphertext ct_pq =/= ct*_pq that encapsulates the same PQ shared secret ss*_pq and query the decapsulation oracle with (ct_pq, ct*_ec) to see if it returns the challenge key K* or not. In the simulation above, it will always return K* and so A will always conclude that it is the real key, regardless of the PRF-ODH challenger's choice of b. The difference between this and X25519 equivalent public keys is that it is easy to identify the equivalent public keys so both the PRF-ODH and IND-CCA2 games can be adjusted to exclude their use in oracle queries. This is essentially the same as requiring public key validation. I don't believe it's possible to modify the IND-CCA2 game to block equivalent PQ ciphertexts in the same way and even if you could I think it would be a significant deviation from the usual security notion. Sorry for all the details. Hopefully, it's clear enough! Best, Peter -Original Message- From: Felix Günther Sent: Tuesday, August 13, 2024 10:51 AM To: Peter C ; Marc Fischlin Cc: tls@ietf.org Subject: Re: [TL
[TLS] Re: ECH Proxy Mode
Hi, > On Sep 4, 2024, at 11:28, Raghu Saxena wrote: > > On 9/3/24 10:52 PM, 涛叔 wrote: >> This idea was derived from my attempt to implement encrypted TLS SNI Proxy. >> The SNI >> does not only expose privacy information, many ISP use it to block certain >> web site. >> Even though the current draft of ECH works to protect the ClientHello, it >> can only >> protect the sites that deployed the ECH. >> >> If we can adjust the current design and let the client-facing generate and >> response >> the accept_confirmation signal, we can make ECH everywhere without upgrading >> any of >> current TLS backend server. Which means the client-facing can work as an >> encrypted >> TLS SNI Proxy. > > I'm trying to understand what exactly your use-case here is. Wouldn't a naive > HTTPS Proxy w/ CONNECT be sufficient? > > E.g. if we have the proxy domain `https://myproxy.com` , and the website we > want to connect to is `https://supersecret.com`, then assuming a classic > HTTPS Proxy running on `myproxy.com`, the Client would make a TLS handshake > to `myproxy.com` and reveal the Proxy SNI, however once the TLS handshake > with the proxy is complete, the `CONNECT` to `supersecret.com` will be inside > the TLS tunnel, so it will be private. > > I think this would be sufficient, since even in the split-example with ECH > you mention, the `public_name` of the first client-facing server will be > visible anyway. Yes, the native HTTPS Proxy with CONNECT has similar feature. However, the ECH based SNI Proxy still has some benefits. First, we setup one DNS over HTTPS server, and let the user agent use the DoH server. Second, we setup the client-facing ECH server as SNI proxy. Third, in our DoH server, we "hijack" the A/ record for the original server and point it to the ECH client-facing server, and add the fake HTTPS/SVCB record to indicate the user agent that the original "support" ECH. Finally, when the user agent try to negotiate the TLS session to the backend server, it looks up both the A/ and HTTPS records from the DoH server. Then the user agent will connect to our client-facing server (work as SNI proxy). Since the user agent also derives our fake HTTPS record with ECH config, the user agent will try to connect the client-facing server using this config with a proper generate config_id and public_name. We can dynamically generate this ECHConfig and associate the real original domain name to some dynamic public_name. When the client-facing server accept the ECH handshake, it can decrypt the real domain name of the original server, and then it will works as a normal SNI-proxy and try to connect to the backend server using the ClientHelloInner. As the server has no idea of this ECH-based proxy, it will respond a normal ServerHello with normal random field. Once our ECH client-facing the ServerHello, it has to respond the accept_confirmation on behalf of the original. However, the current draft requires using the last 8 bytes of random in ServerHello to indicate the accept_confirmation, which can not be modified by the client-facing server, and this design makes it impossible to implement this ECH-based SNI proxy. If we can implement ECH-based SNI proxy, we can "deploy" ECH to all TLS server without upgrading the HTTPS server software of the backend server. All we need is to do some kind of "DNS hijacking". This hijacking will result in no security problem because the client-facing server will only see the ClientHelloInner and can not monitor the real plain traffic under TLS. If we can implement ECH-based SNI proxy, the user agent setup will be simplified as much as possible. All it needs to do is setup a proper DoH server, and let all other configuration in the remote side of ECH client-facing server and DoH server. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360
I do not think we need to make Curve25519 MTI. The purpose of MTIs is to provide a minimum baseline for interoperability, and we have that already with the existing MTI. That's entirely compatible with most people preferring X25519 because they believe it's better than the MTI. -Ekr On Mon, Aug 26, 2024 at 7:26 AM David Adrian wrote: > I also support *not* making Curve 25519 MTI. > > > On Mon, Aug 26, 2024 at 10:18 AM Richard Barnes wrote: > >> My feelings exactly match Rich's here. >> >> On Mon, Aug 26, 2024 at 10:15 AM Salz, Rich > 40akamai@dmarc.ietf.org> wrote: >> >>> I am also opposed to the merge. 8446bis changes are editorial and >>> clarifications, not semantic ones. >>> >>> >>> ___ >>> TLS mailing list -- tls@ietf.org >>> To unsubscribe send an email to tls-le...@ietf.org >>> >> ___ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
