[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech
>From the server operator side, I feel strongly that the multi-CDN example should show a selected CDN setup not a merged CDN setup. The "Automation is required to keep these records consistent with the original records in the CDN providers' zones." mentioned in the current example is outside of the scope of this draft and is not something that I see being operationally viable. Having this example would be worse than having no examples as it provides a misleading perception that this is straightforward, but this is far outside how multi-CDN setups integrate with customers today and is not something that I can see CDN operators being willing to support. Beyond that it would be helpful to hear from implementers on the client side if these examples help, especially from those who were confused before. Again, see here for the diff (with discussion): https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/18/files Erik On Wed, Oct 16, 2024 at 4:54 PM Ben Schwartz wrote: > OK. Erik, Mike, Paul: Let me know if you have any further comments on #18. > > --Ben > -- > *From:* Sean Turner > *Sent:* Wednesday, October 16, 2024 3:06 PM > *To:* draft-ietf-tls-svcb-ech.auth...@ietf.org < > draft-ietf-tls-svcb-ech.auth...@ietf.org> > *Cc:* dn...@ietf.org WG ; TLS List > *Subject:* Re: [TLS] [DNSOP] Re: Re: Re: Re: AD review > draft-ietf-tls-svcb-ech > > > > Authors (Ben, Mike, and Eric), > > Thank for the PR with some examples: > https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/18 > > Once you’ve settled the debate (hopefully before Monday), please go ahead > and merge so that Paul can get the IETF LC started. > > Cheers, > spot > > > On Oct 9, 2024, at 09:38, Sean Turner wrote: > > > > Authors (Ben, Mike, and Eric), > > > > It looks like we haves some agreement here. There’s some agreement that > the PR [1] addresses the concern and there’s some agreement to agree to > disagree on other points. Please go ahead and merge the PR [1]. > > > > spt > > > > [1] https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 > > > >> On Oct 8, 2024, at 21:38, Eric Rescorla wrote: > >> > >> I agree that you can't trust a resolver that you only know about from > ADD. > >> > >> -Ekr > >> > >> > >> On Tue, Oct 8, 2024 at 8:31 AM Paul Wouters > wrote: > >> I agree with your points. Our only difference of opinion seems to be > about how much one should trust a TRR. > >> I still prefer to need to trust them the least possible, meaning I > would want DNSSEC validation to at least > >> detect tampering at the TRR. With more ECH deployed, and less > visibility of SNI, there will be increase > >> pressure on TRRs to do so. > >> > >> But this discussion is not really in scope for the ECH SVCB draft, > other than that I am concerned about the > >> illusion of ECH privacy being lost because of a "trusted by the network > via ADD" resolver being used. > >> > >> Paul > >> > >> On Mon, Oct 7, 2024 at 9:36 PM Eric Rescorla wrote: > >> Paul, > >> > >> I don't understand your threat model here. > >> > >> 1. As already noted upthread, ECH inherently leaks the name you are > >> resolving to the resolver. This leak doesn't depend on the resolver > >> tampering with the response, so DNSSEC verification on the client > >> doesn't help here [0]. > >> > >> 2. If the client accepts the network resolver, as opposed to requiring > >> a TRR, then a malicious network will always be able to force the user > >> into leaking their browsing history on that network. Thus, as you > >> say, if you want ECH to guarantee privacy you need to use encrypted > >> transport to a TRR. > >> > >> 3. As Ben observed, if the client caches the response from the > >> recursive, then an ECH record from malicious resolver A (e.g., in the > >> airport) might allow A to continue to learn the SNI even when you are > >> using non-malicious resolver B (e.g., at your house). But the only > >> way to get into this hole is to use the network provided (potentially > >> malicious) resolver. > >> > >> 4. The specific attack in (3) can be prevented if the client only > >> cached ECH records when they were DNSSEC signed, but this still > >> leaves you leaking to the malicious network's resolver whenever > >> you try to retrieve an uncached value, so it's much better to > >> just insist on using a TRR, which protects against this attack > >> entirely, at which point DNSSEC provides limited value. > >> > >> If you think this analysis is wrong, please explain the attack > >> which is prevented by client-side DNSSEC validation, remembering > >> that it can only be done reliably when the client already is > >> using a TRR. > >> > >> -Ekr > >> > >> > >> [0] DNSSEC validation at the recursive might help, but that's not what > >> we're talking about. > >> > >> On Mon, Oct 7, 2024 at 9:16 AM Paul Wouters > wrote: > >> > >> On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote: > >> > >> > >> On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters > wrote: > >> > >> On S
[TLS] Re: Consensus call for RFC8773bis Formal Analysis Requirement
Hi, I think this is a very straightforward way to introduce hybrid keying to TLS 1.3. I think this extension will increase the use of TLS 1.3 in national security systems, which I think is very welcome. This kind of hybrid keying / defense-in depth is exactly what is recommended in the excellent PhD thesis by Martin Ekerå [1], who is also chief cryptographer of the Swedish NCSA. As long as the extension does not alter the certificate authentication or the ephemeral key exchange, I do not see any way it could lower the security, but I am not against formal analysis. I am satisfied with the Privacy Considerations section and would like to see this draft published as proposed standard. Some comments on draft-ietf-tls-8773bis-02: - - - "There are two motivations for using a certificate with an external PSK." For national security systems, I think it is motivated to always use hybrid keying, combining symmetric keying with post-quantum secure asymmetric keying. The recommendation in [1] is to combine symmetric keying, post-quantum secure asymmetric keying, and classically secure asymmetric keying, as a defense-in depth. See Algorithm 1 and Figure A.1 of [1]. - - - "but it will take many years for TLS 1.3 ciphersuites that use these algorithms to be developed and deployed" X25519MLKEM768 already seem developed and deployed. - - - "Since the "tls_cert_with_extern_psk" extension is intended to be used only with initial handshakes, it MUST NOT be sent alongside the "early_data" extension." I don't think the MUST NOT follows from that "tls_cert_with_extern_psk" is intended to be used only with initial handshakes. External PSKs can be used with "early_data" in the initial handshake according to RFC 8446. Suggestion: NEW: "tls_cert_with_extern_psk" MUST NOT be sent alongside the "early_data" extension." - - - "However, TLS 1.3 does not permit an external PSK to be used in the same fashion as a resumption PSK, and this extension does not alter those restrictions" I don't know what these restrictions on external PSK are and I could not find them in RFC 8446. - - - "For protection against the future invention of a CRQC, the symmetric key needs to be at least 128 bits It needs to be at least 128 bits to protect against classic computers as well. The sentence is also duplicated in the following paragraph. Suggestion: NEW "For protection against the future attacks, the symmetric key needs to be at least 128 bits" - - - "the advantage of Grover’s algorithm will be smaller." I don't think Grover's will ever have any practical advantage. In addition to cost and parallelization, two additional factors mentioned in footnote 18 of [1] are: "large-scale fault-tolerant quantum computers as currently envisaged are very slow compared to classical computers" "The overheads incurred by the need to employ quantum error correction to achieve fault tolerance are furthermore substantial." - - - - "If the external PSK is known to any party other than the client and the server, then the external PSK MUST NOT be the sole basis for authentication. I think certificate-based server authentication SHALL be used even if the external PSK is known only be the client and the server. - - - "In addition, clients MAY also include psk_ke mode to support a subsequent NewSessionTicket." I think this draft focusing on hybrid keying in high-security systems should forbid psk_ke. - - - Cheers, John [1] Ekerå, "On factoring integers, and computing discrete logarithms and orders, quantumly" http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)
On 18/10/2024 02:30, Sean Turner wrote: Whoops - Corrected! I'm still not seeing minutes? > The summary is that the process described in the slides is > basically the right shape. I'm either misinterpreting that or disagree with you. Not sure which. ISTM the concerns about anonymous influence on the standards process wasn't covered in the slides, nor your conclusion, and fixing that would seem like a significant change, so I guess you'd have called that out were it the case. If the FATT process still has anonymous reviewers, IMO it is still broken. Cheers, S. OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] I-D Action: draft-ietf-tls-extended-key-update-01.txt
Internet-Draft draft-ietf-tls-extended-key-update-01.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Extended Key Update for Transport Layer Security (TLS) 1.3 Authors: Hannes Tschofenig Michael Tüxen Tirumaleswar Reddy Steffen Fries Yaroslav Rosomakho Name:draft-ietf-tls-extended-key-update-01.txt Pages: 16 Dates: 2024-10-19 Abstract: The Transport Layer Security (TLS) 1.3 specification offers a dedicated message to update cryptographic keys during the lifetime of an ongoing session. The traffic secret and the initialization vector are updated directionally but the sender may trigger the recipient, via the request_update field, to transmit a key update message in the reverse direction. In environments where sessions are long-lived, such as industrial IoT or telecommunication networks, this key update alone is insufficient since forward secrecy is not offered via this mechanism. Earlier versions of TLS allowed the two peers to perform renegotiation, which is a handshake that establishes new cryptographic parameters for an existing session. When a security vulnerability with the renegotiation mechanism was discovered, RFC 5746 was developed as a fix. Renegotiation has, however, been removed from version 1.3 leaving a gap in the feature set of TLS. This specification defines an extended key update that supports forward secrecy. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-extended-key-update-01.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-extended-key-update-01 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
