[TLS]Re: TLS trust expressions and certificate_authorities
On 12/06/2024 02:36, Nick Harper wrote: If Trust Expressions does meaningfully change the calculus compared to certificate_authorities, it does it in a way that lessens risk. The certificate_authorities extension doesn't scale support the legitimate use case of trust negotiation/advertisement that Trust Expressions supports, but this problem doesn't exist for certificate_authorities advertising a single government CA. In your first example of how certificate_authorities differs from Trust Expressions, you've given an example of how Trust Expressions is less risky than certificate_authorities. You can't argue that T.E. contains the functionality of certificate_authorities as a subset, then conclude that having additional functionalities makes it less risky. You would need to argue the exact opposite, that T.E. doesn't contain the bad functionalities of certificate_authorities. The risk associated with abuse of a feature is not in any way diluted by tacking on good use cases. The complexity of deploying certificate_authorities for the government CA "risky" use case is much less than it is for Trust Expressions. The "risky" use case requires clients advertise the name of the CA, and it requires servers to be able to match a name in the certificate_authorities extension against one of its multiple certificates. This deployment has no machinery with CAs, ACME servers, or root programs publishing manifests. When you say certificate_authorities doesn't have any of the machinery necessary, that's because it doesn't need any such machinery, as Devon explained in point 4. In the "risky" use case, Trust Expressions requires the government to implement or compel more actions than it would with certificate_authorities. Starting with the clients, it would need to compel root programs to manage and publish an additional trust store manifest (or manage its own trust store manifest and compel advertisement of that as part of compelling trust). It would also need to have its CA (and the CA's ACME server) support the government trust store in its CertificatePropertyList. It looks like there's a lot more compulsion involved in this government-forced trust use case when the government uses Trust Expressions instead of certificate_authorities. I wonder what such a trust store manifest would look like... [1] [2]. There's at least one large player out there with a list of CAs ready to go and all the necessary machinery in place. [1] https://eidas.ec.europa.eu/efda/tl-browser/#/screen/home [2] https://eidas.ec.europa.eu/efda/swagger-ui/index.html#/api-browser-controller/getTrustedList ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Curve-popularity data?
On Wednesday, 12 June 2024 02:02:41 CEST, D. J. Bernstein wrote: There will be an annoyingly large number of options on the PQ side---for example, for different security levels and for patent avoidance---and I'd expect a tricky discussion of which options to recommend for TLS. I'm not sure I buy this premise. Currently there seems to be an overwhelming convergence on ML-KEM768 for this job, with the one exception being ML-KEM1024 being favored by the CNSA 2, but the latter also does not recommend hybrids, leaving us with really only one choice for the PQ hybrid for at least the medium term. Within ML-KEM, NSA isn't just favoring 1024, but _forbidding_ sizes below 1024: https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF The document doesn't forbid hybrids; on the contrary, it states that "NSA may allow or require hybrid solutions due to protocol standards, product availability, or interoperability requirements". So there isn't a clear dividing line between what NSA is doing and what the TLS WG will end up considering. Other people have already brought up NSA's ML-KEM requirements in TLS discussions, and people who don't think NSA should have control over IETF can still understand NSA's position as communicating security concerns relevant to TLS decisions. This by itself looks to me like a much more tricky discussion than any TLS curve discussions! while yes, the only people that will want ML-KEM-1024 are the ones that will want to follow CNSA 2.0, and those people are likely already following CNSA 1.0 (or Common Criteria), so use P-384. So, for the defined groups, if we provide P-256+ML-KEM-768 and P-384+ML-KEM-1024 it should cover all the bases for FIPS and (likely even future) Common Criteria requirements. Apple has rolled out ML-KEM-1024 in another protocol: https://security.apple.com/blog/imessage-pq3/ Meanwhile Meta says, regarding TLS, that they're rolling out ML-KEM-768 and, for performance reasons (TFO packet size), also ML-KEM-512: https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/ Sounds like big deployments of all three ML-KEM sizes already (times different Kyber versions, but let's assume all the different versions switch to the final version of ML-KEM after NIST posts that, which should happen any day now), and at least some of the underlying rationales are certainly applicable to TLS. yes, the question is if we want to pair P-256 with ML-KEM-512 or with ML-KEM-768 for the "FIPS compatible fast option" hybrid key exchange group. I don't have a strong opinion either way. -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Working Group Last Call for Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
This email starts the working group last call for "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings” I-D, located here: https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ The WG Last Call will end 26 June 2024 @ 2359 UTC. Please review the I-D and submit issues and pull requests via the GitHub repository that can be found at: https://github.com/tlswg/draft-ietf-tls-svcb-ech Alternatively, you can also send your comments to tls@ietf.org. Thanks, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Yes, my worry is really around enforcement of a property that can’t be strictly adhered to. How about something along the lines of: Until receiving a KeyUpdate from the peer, the sender MUST NOT send another KeyUpdate with request_update set to "update_requested". Note that implementations may receive an arbitrary number of messages between sending a KeyUpdate with request_update set to "update_requested" and receiving the peer's KeyUpdate, including unrelated KeyUpdates, because those messages may already be in flight. I think this would make the requirement more clear, and avoid enforcement of a requirement that can’t be strictly followed. From: David Benjamin Sent: Thursday, June 6, 2024 5:48 PM To: Kyle Nekritz Cc: Sean Turner ; TLS List Subject: Re: [TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345 Regarding 1343, the PR is a rule on the sender, not the receiver. After all, it says "The sender MUST NOT". It is not a rule on the receiver. We have interop problems *today* when one side sends too many KeyUpdates, triggered by data ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd Regarding 1343, the PR is a rule on the sender, not the receiver. After all, it says "The sender MUST NOT". It is not a rule on the receiver. We have interop problems *today* when one side sends too many KeyUpdates, triggered by data received. The PR does not ask receivers to enforce stuff, but (mostly) prevents senders from tripping receiver DoS limits and thus causing an interop problem. I say mostly because the scenario you mention is a good one. I hadn't thought of that. But that scenario is not an interop problem introduced by 1343. It's a scenario that 1343 doesn't fully solve, but still dramatically improves. Prior to 1343, a server with a buggy update_requested policy would send 3GB / 16K = 196,608 KeyUpdates for every 4 GB of data sent by the client, assuming full records. This will very, very easily trip DoS limits and quickly cause the connection to fail. 1343 clarifies that this update_requested policy is wrong sender behavior. You're right that 1343 doesn't completely solve the problem. The server will misinterpret the client's own KeyUpdates as response and send 1 KeyUpdate for every 4 GB of data. That is, however, an improvement by a factor of 196,608x. It would take a lot more traffic to trip a DoS limit under that scenario. Ideally we'd come up with an even better sender rule, but I suspect we cannot do so without completely redesigning updated_requested. During TLS 1.3's development, my position was that update_requested was a mistake and we should remove it, precisely due to its propensity for DoS and interop problems. I think that position has proven to be the right one, but it's too late to remove the feature now. 1343 is the best option I see to fix it right now. On Thu, Jun 6, 2024 at 1:46 PM Kyle Nekritz mailto:40meta@dmarc.ietf.org>> wrote: I object to 1343 because I don't think it can be implemented without risking interop problems. There is nothing tying a KeyUpdate response to the KeyUpdate that requested it, or distinguishing it from an unrelated KeyUpdate. As an example of how this can cause practical problems, say we have two peers with the following policies: Client: sends KeyUpdate with update_not_requested every 4GB of data sent (which is a reasonable policy, effectively making sure the client doesn't violate its own data limits, and letting the peer handle theirs) Server: sends a KeyUpdate with update_requested every 1GB of data sent by either peer (similar to the motivating example in the issue) If, like in the example in the issue, the client is sending a large amount of data, and not reading anything from the server until it's done, and the server isn't sending any response application data, the server will send an update_requested KeyUpdate after 1GB of data from the client. The server will then be blocked from sending more KeyUpdates due to the proposed requirement. However once the client sends 4GB of data, it will send an update_not_requested KeyUpdate. To the server, this will appear to be a response to it's KeyUpdate request, and it will be free to send another update_requested KeyUpdate. However, to the client, this will appear as a redundant KeyUpdate, since the KeyUpdate it sent wasn't actually in response to the server's first KeyUpdate. If the client enforces the MUST NOT added in the PR, this will cause a failure. -Original Message- From: Sean Turner mailto:s...@sn3rd.com>> Sent: Monday, June 3, 2024 11:38 AM To: TLS List mailto:tls@ietf.org>> Subject: [TLS]Consensus Call: -rfc8446bis PRs #1343 & #1345 !---| This Message Is From an External Sender |---! Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs h
[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Works for me! Updated the PR with your suggestion (plus one extra word to be clear it's a subsequent KeyUpdate and not a random past one). On Wed, Jun 12, 2024 at 3:56 PM Kyle Nekritz wrote: > Yes, my worry is really around enforcement of a property that can’t be > strictly adhered to. How about something along the lines of: > > > > Until receiving a KeyUpdate from the peer, the sender MUST NOT send > > another KeyUpdate with request_update set to "update_requested". > > > > Note that implementations may receive an arbitrary > > number of messages between sending a KeyUpdate with request_update set > > to "update_requested" and receiving the > > peer's KeyUpdate, including unrelated KeyUpdates, because those > messages may already be in flight. > > > > I think this would make the requirement more clear, and avoid enforcement > of a requirement that can’t be strictly followed. > > > > *From:* David Benjamin > *Sent:* Thursday, June 6, 2024 5:48 PM > *To:* Kyle Nekritz > *Cc:* Sean Turner ; TLS List > *Subject:* Re: [TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345 > > > > Regarding 1343, the PR is a rule on the sender, not the receiver. After > all, it says "The sender MUST NOT". It is not a rule on the receiver. We > have interop problems *today* when one side sends too many KeyUpdates, > triggered by data > > Regarding 1343, the PR is a rule on the sender, not the receiver. After > all, it says "The sender MUST NOT". It is not a rule on the receiver. > > > > We have interop problems *today* when one side sends too many KeyUpdates, > triggered by data received. The PR does not ask receivers to enforce > stuff, but (mostly) prevents senders from tripping receiver DoS limits and > thus causing an interop problem. > > > > I say mostly because the scenario you mention is a good one. I hadn't > thought of that. But that scenario is not an interop problem introduced by > 1343. It's a scenario that 1343 doesn't fully solve, but* still > dramatically improves*. Prior to 1343, a server with a buggy > update_requested policy would send 3GB / 16K = 196,608 KeyUpdates for every > 4 GB of data sent by the client, assuming full records. This will very, > very easily trip DoS limits and quickly cause the connection to fail. > > > > 1343 clarifies that this update_requested policy is wrong sender behavior. > You're right that 1343 doesn't completely solve the problem. The server > will misinterpret the client's own KeyUpdates as response and send 1 > KeyUpdate for every 4 GB of data. That is, however, an improvement by a > factor of 196,608x. It would take a lot more traffic to trip a DoS limit > under that scenario. Ideally we'd come up with an even better sender rule, > but I suspect we cannot do so without completely redesigning > updated_requested. During TLS 1.3's development, my position was that > update_requested was a mistake and we should remove it, precisely due to > its propensity for DoS and interop problems. I think that position has > proven to be the right one, but it's too late to remove the feature now. > 1343 is the best option I see to fix it right now. > > > > On Thu, Jun 6, 2024 at 1:46 PM Kyle Nekritz 40meta@dmarc.ietf.org> wrote: > > I object to 1343 because I don't think it can be implemented without > risking interop problems. There is nothing tying a KeyUpdate response to > the KeyUpdate that requested it, or distinguishing it from an unrelated > KeyUpdate. As an example of how this can cause practical problems, say we > have two peers with the following policies: > > Client: sends KeyUpdate with update_not_requested every 4GB of data sent > (which is a reasonable policy, effectively making sure the client doesn't > violate its own data limits, and letting the peer handle theirs) > Server: sends a KeyUpdate with update_requested every 1GB of data sent by > either peer (similar to the motivating example in the issue) > > If, like in the example in the issue, the client is sending a large amount > of data, and not reading anything from the server until it's done, and the > server isn't sending any response application data, the server will send an > update_requested KeyUpdate after 1GB of data from the client. The server > will then be blocked from sending more KeyUpdates due to the proposed > requirement. However once the client sends 4GB of data, it will send an > update_not_requested KeyUpdate. To the server, this will appear to be a > response to it's KeyUpdate request, and it will be free to send another > update_requested KeyUpdate. However, to the client, this will appear as a > redundant KeyUpdate, since the KeyUpdate it sent wasn't actually in > response to the server's first KeyUpdate. If the client enforces the MUST > NOT added in the PR, this will cause a failure. > > -Original Message- > From: Sean Turner > Sent: Monday, June 3, 2024 11:38 AM > To: TLS List > Subject: [TLS]Consensus Call: -rfc8446bis PRs #1343 & #1345 > > > > Since dra
[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Hi! Just reminder to get any concerns about merging these in by 17 June 2024. spt > On Jun 3, 2024, at 11:38, Sean Turner wrote: > > Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been > submitted (and discussed) that include changes to normative language: > > - #1343: Forbid the sender from sending redundant update_requested KeyUpdates > https://github.com/tlswg/tls13-spec/pull/1343 > > - #1345: Forbid the sender from sending duplicate supported groups entries > https://github.com/tlswg/tls13-spec/pull/1354 > > The discussion so far seems to support consensus to merge these PRs. If you > object, please > do so on the issue or in response to this message. Absent any pushback, we > will direct the > editors to incorporate them in two weeks' time. > > Cheers, > spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS trust expressions and certificate_authorities
On Wed, Jun 12, 2024 at 3:17 AM Dennis Jackson wrote: > You can't argue that T.E. contains the functionality of > certificate_authorities as a subset, then conclude that having additional > functionalities makes it less risky. You would need to argue the exact > opposite, that T.E. doesn't contain the bad functionalities of > certificate_authorities. The risk associated with abuse of a feature is not > in any way diluted by tacking on good use cases. > I'm not arguing that TE is a superset of certificate_authorities. I'm arguing that it's an incremental improvement over certificate_authorities. That is to say, certificate_authorities is a way for a relying party to indicate to a subscriber which CAs it trusts, and TE is another way to do the same thing. TE is an incremental improvement because it's solving the same problem but making different tradeoffs. To deploy the certificate_authorities extension, no extra machinery is needed past what's in the certificates, but that comes at a cost of a large number of bytes sent by the relying party. TE optimizes for size, at the cost of additional complexity and machinery involving additional parties. For the abuse scenario, TE makes it no easier than certificate_authorities (the size of advertising the single malicious CA isn't a concern, whereas it is a problem when it's a browser's entire trust store that's advertised), and TE adds additional deployment complexity compared to certificate_authorities, which lessens the risk. The takeaway here is that the risks associated with the abuse of Trust Expressions also exist with certificate_authorities. > > I wonder what such a trust store manifest would look like... [1] [2]. > There's at least one large player out there with a list of CAs ready to go > and all the necessary machinery in place. > Ready to go and do what?! If you're talking about the EU eIDAS QWAC trust list, those CAs were already trusted by browsers before the eIDAS regulations took effect, and eIDAS allows for their distrust and removal. Already, one CA [1] on that list is being distrusted by multiple [2] browsers [3]. Even if the EU has a published list of CAs that they could turn into a trust store manifest, this is a distraction from the point that with TE, abuse requires the cooperation (or compulsion) of more parties than with certificate_authorities. 1: https://eidas.ec.europa.eu/efda/tl-browser/#/screen/tl/AT/5/25 2: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XpknYMPO8dI/m/JBNFg3aVAwAJ 3: https://groups.google.com/a/ccadb.org/g/public/c/wRs-zec8w7k/m/G_9QprJ2AQAJ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Working Group Last Call for Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
I had one comment earlier that seems to have been missed [0]. Basically I was wondering if it may be useful to use stronger language in the draft to indicate a client MUST use Port Prefix Naming when looking up the SVCB record. Regards, Raghu Saxena [0] https://mailarchive.ietf.org/arch/msg/tls/ynRkX60dGq-ofmSW4POhppQcgkY/ On 6/13/24 2:10 AM, Sean Turner wrote: This email starts the working group last call for "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings” I-D, located here: https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ The WG Last Call will end 26 June 2024 @ 2359 UTC. Please review the I-D and submit issues and pull requests via the GitHub repository that can be found at: https://github.com/tlswg/draft-ietf-tls-svcb-ech Alternatively, you can also send your comments to tls@ietf.org. Thanks, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org OpenPGP_0xA1E21ED06A67D28A.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
