Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
On Thu, Aug 18, 2022, at 7:57 PM, Martin Thomson wrote: > On Thu, Aug 18, 2022, at 22:39, Scott Fluhrer (sfluhrer) wrote: >> Actually, that was our original intention with this draft - to specify >> the framework, and to have other documents specify the actual pairs. >> However, I believe that the sense of the working group is that they >> want this draft to start with a limited number of options (and people, >> please correct me if I'm wrong). > > I'm saying that that is not a good idea. Drafts are cheap, and this > one is done. If that is counter to the sentiment of the working group, > then so be it. (Chair hat on) We specifically parked this document in its current post-WGLC state to sort out the issue of codepoints, be it here or in a separate companion document. Either way, the draft is not yet done. Best, Chris > > ___ > 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] WGLC for draft-ietf-tls-hybrid-design
On Thu, Aug 18, 2022, at 22:39, Scott Fluhrer (sfluhrer) wrote: > Actually, that was our original intention with this draft - to specify > the framework, and to have other documents specify the actual pairs. > However, I believe that the sense of the working group is that they > want this draft to start with a limited number of options (and people, > please correct me if I'm wrong). I'm saying that that is not a good idea. Drafts are cheap, and this one is done. If that is counter to the sentiment of the working group, then so be it. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] ECH not protect SNI
Hello, Guys, I have read the draft-ietf-tls-esni-14, and found the ECH does not protect the SNI. Because if the client use the outdated ECH config to encrypted the ClientHelloInner, it will not be decrypted by the client facing server. In order to correct the client, the server will finish the handshake using the ClientHelloOuter, which has its own SNI. And the server will send new ECH configs encrypted by its SSL certificate. So the client can verify the new configs is valid. In my own opinion, this design only hide the original SNI, but still depends the client-facing server's domain name. It has two drawbacks: 1. If one domain want to deploy ECH in share mode, it have to offer one addition domain for the ClientHelloOuter. 2. Even the real domain will be encrypted, the shared domain don't. And if the outs domain been blocked, all the inner domain will gone. So my question is why not just use the DNSSEC method the correct the client who has some outed ECH configs? If the client-facing can not decrypted the ClientHelloInner, all it needs to do is send the new HTTPS DNS records and their RRSIGs. And the client can validate them by the DNSSEC methods. By this design, there is no need to establish the outer TLS handshake. And no additional outer domain any more. The client does not need to know or deploy two domain as well. And for almost TLS handshake, their even no need to a SSL certificates. Because we can deploy some public key by the DNS, and make a PSK handshake to the server. So why the working group does not choose the DNSSEC method? Thanks Taoshu(涛叔) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Servers respond with BadRecordMac after ClientFinished, sent when PSK+EarlyData
I investigated this issue and found that TTLS13::Client does not send EndOfEarlyData when 0-RTT. The transcript was invalid because it did not contain EndOfEarlyData. By the way, I still have another question on this. I understand that if the server has not yet received EndOfEarlyData and it receives Finished, it should raise "bad_record_mac" alert and not ignore the lack of EndOfEarlyData. Because it assumes messages protected using keys derived from a "client_early_traffic_secret". Is my understanding of this correct? - https://www.rfc-editor.org/rfc/rfc8446.html#section-4.2.10 - > if the server fails to decrypt a 0-RTT record following an accepted "early_data" extension, it MUST terminate the connection with a "bad_record_mac" alert as per Section 5.2. - https://www.rfc-editor.org/rfc/rfc8446.html#section-4.5 - > This message indicates that all 0-RTT application_data messages, > After adding it, the error was gone and the connection closed with Alert(0). In that case, when adding "Connection: close" header, it should raise "bad_record_mac" alert, I wonder. For your reference, I created the client that does not send EndOfEarlyData when TLS 1.3 0-RTT Handshake. - https://github.com/thekuwayama/no_eoed_0rtt_client 2022年8月16日(火) 23:07 Kristijan Sedlak : > > Hey Ilari, > > thank’s for replying. I did verify the transcript as well. Everything seems > to be correct. I bet if it wasn't the 1-RTT and 0-RTT(no-early-data) would > fail too. Something weird is going on only in 0-RTT(early-data) case. > > Can you maybe point me to an URL with the correct TLS1.3 implementation where > I could safely test the client? > > Best, > Kristijan > > On 9 Aug 2022, at 08:51, Ilari Liusvaara wrote: > > Ilari > > > ___ > 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] WGLC for draft-ietf-tls-hybrid-design
> -Original Message- > From: TLS On Behalf Of Martin Thomson > Sent: Wednesday, August 17, 2022 7:05 PM > To: tls@ietf.org > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design > > On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote: > > Well, if we were to discuss some suggested hybrids (and we now know > > the NIST selection), I would suggest these possibilities: > > > > - X25519 + Kyber512 > > - P256 + Kyber512 > > - X448 + Kyber768 > > - P384 + Kyber768 > > Any specific pairs of primitives should be specified in a different document > to > this one. Actually, that was our original intention with this draft - to specify the framework, and to have other documents specify the actual pairs. However, I believe that the sense of the working group is that they want this draft to start with a limited number of options (and people, please correct me if I'm wrong). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
