Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
> I only have some isolated random datapoints on number of disclosed WebPKI > ICAs since 2021-02-08 (a bit over year ago), but during that time, that > number has grown from 1669 to 1820. Thx Ilari. Understood. We are looking into how we could quantify how the complete ICA list changes over time in order to evaluate TBD3. Probably it would be in the days to weeks timeline than years, but that remains to be seen. Of course that would not cover usecases other than WebPKI, but probably that is the more dynamic one. -Original Message- From: TLS On Behalf Of Ilari Liusvaara Sent: Saturday, February 19, 2022 6:15 AM To: tls@ietf.org Subject: RE: [EXTERNAL] [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Sat, Feb 19, 2022 at 03:59:23AM +, Kampanakis, Panos wrote: > - If we can assume an OOB mechanism to load the ICAs then we can > simplify things. Practically we can assume there is no failure. > Agreed, but I am not sure that we should not include any non-normative > language for the inadvertent corner case though. > There should be a fallback, one that we are assuming will never > happen, but an implementer should account for it. It seems to me that the dominant failure modes are: - Using old ICA list that is missing some newly minted ICA. - Using custom TA that is missing ICA data. > - Connection re-establishment affects the security and privacy > assumptions and should be captured. I am not sure the concern is worse > than the regular fingerprinting text already in the draft, but point > taken. We can improve the text and I created an issue for it. > https://github.com/csosto-pk/tls-suppress-intermediates/issues/12 Regarding security and privacy, the most severe impact of any attack I can come up with is determining if some arbitrary ICA is on the ICA list or not (for passive attacks, that is restricted to the issuing ICA used by the server). Practical impact of attacker being able to do that depends on how many endpoints share that same ICA list. Rough outline of the attack (active variant): Fabricate a certificate purporting to be from some ICA, send it to client and observe if the client retries (ICA not on the list) or just fails (ICA is on the list). > I would be interested to track how that ICA list has been changing > over time. Let’s see if we can get data on that for FFs preload list, > Filippo’s or others. I only have some isolated random datapoints on number of disclosed WebPKI ICAs since 2021-02-08 (a bit over year ago), but during that time, that number has grown from 1669 to 1820. -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] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Fri, Feb 25, 2022 at 11:17 AM Ilari Liusvaara wrote: > I have hard time seeing how one could construct downgrade attack out of > this, as it just requests extra data from server on fallback. For most > other retry stuff, downgrade attack risk is obvious as less secure modes > are introduced / more secure modes are removed. I think I’m raising a question about whether or not implementations will actually do this, and arguably, to explicitly specify this if this is the expectation. In theory, yes, if the only thing changing in a fallback is an optional flag, it “shouldn’t” have concerns. In practice, however, these sorts of fallbacks (e.g. various server bug workarounds) introduce compositions that cause new and unexpected interactions. This is why the ecosystem has tried very hard to avoid fallbacks (c.f. TLS 1.3) and ensuring that both parties are able to commit to the negotiation. We saw this with the renegotiation issues getting confused state from the initial handshake. Having pathLen >= 1 would do as well, right? Sure, “without pathLen constraints” And such ICAs can already be abused for tracking if the browser does > transvalidity. Suppress ICAs flag would make it worse, by allowing other > sites to read such tracking supercookies. Transvalidity was never something widely supported outside of a specific product/library (Mozilla NSS). But yes, this is the point: this feature gives a much stronger signal. Defense is not doing transvalidity nor cached AIA chasing (since those > caches represent state that could be attacked). This closes the attack > for both with and without suppress ICAs. I fail to see how it closes it without suppress ICAs, particularly because the current draft very explicitly suggests caching as a possibility. And yes, implementations that wish to mitigate cross-context tracking are working to isolate those caches, and this was my point: doesn’t this isolation defeat the benefits of the caching / the likelihood of intermediate omission succeeding, and functionally mean that there needs to be a reliable, semi-real-time distribution mechanism for intermediates to achieve the benefits? I’m trying to look at this from a systems perspective, and tease out explicitly: what is this solution assuming exists in order to achieve the desired effect, and with those assumptions, are there simpler/less-risky/alternative technical solutions? Not to bikeshed, but because the design assumptions here are unstated and have practical and meaningful ecosystem effect, and so we at least owe that much. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Sat, Feb 19, 2022 at 04:28:52PM -0500, Ryan Sleevi wrote: > On Sat, Feb 19, 2022 at 6:15 AM Ilari Liusvaara > wrote: > > > > - Connection re-establishment affects the security and privacy > > > assumptions and should be captured. I am not sure the concern is > > > worse than the regular fingerprinting text already in the draft, > > > but point taken. We can improve the text and I created an issue > > > for it. > > https://github.com/csosto-pk/tls-suppress-intermediates/issues/12 > > > > Regarding security and privacy, the most severe impact of any attack > > I can come up with is determining if some arbitrary ICA is on the > > ICA list or not (for passive attacks, that is restricted to the issuing > > ICA used by the server). Practical impact of attacker being able to do > > that depends on how many endpoints share that same ICA list. > > > > Rough outline of the attack (active variant): Fabricate a certificate > > purporting to be from some ICA, send it to client and observe if the > > client retries (ICA not on the list) or just fails (ICA is on the list). > > > I'm hopeful that some may be interested to perform a more thorough > analysis. We saw enough complexity with respect to previous TLS versions > and the fallback logic being possible to induce downgrade attacks that I > think we should be very wary about introducing a class of anticipated > handshake failures that require connection re-establishment, especially > across independent TLS sessions. I realize that sounds a little like FUD, > but rather: every time we've tried to do this, it's blown up spectacularly, > so we need to make sure we're not setting up another bomb. I have hard time seeing how one could construct downgrade attack out of this, as it just requests extra data from server on fallback. For most other retry stuff, downgrade attack risk is obvious as less secure modes are introduced / more secure modes are removed. > I also think the active attack analysis is a bit lacking, especially since > the attacker has the ability to mint arbitrary ICAs on demand, without > running afoul of any existing client policies. For example, for the Web > PKI, by virtue of nameConstraints without pathLen in the basicConstraints, > the site can mint arbitrary ICAs and arbitrary EE certificates. Combined > with the discovery mechanism discussed, this is effectively the same as > other forms of stateful tracking (ala HSTS tracking), and thus likely to be > subjected to the same mitigations that would largely render the benefits > here ineffective, at best. Having pathLen >= 1 would do as well, right? And such ICAs can already be abused for tracking if the browser does transvalidity. Suppress ICAs flag would make it worse, by allowing other sites to read such tracking supercookies. Defense is not doing transvalidity nor cached AIA chasing (since those caches represent state that could be attacked). This closes the attack for both with and without suppress ICAs. Another defense to make reading ICA list harder would be to always trigger fallback if certificate validation fails and ICAs were suppressed. Neither defense would render suppress ICAs ineffective, since in vast majority of cases one can use quasi-static ICA list to buld verifiable certificate chain and then use that with no fallback. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Sat, Feb 19, 2022 at 6:15 AM Ilari Liusvaara wrote: > > - Connection re-establishment affects the security and privacy > > assumptions and should be captured. I am not sure the concern is > > worse than the regular fingerprinting text already in the draft, > > but point taken. We can improve the text and I created an issue > > for it. > https://github.com/csosto-pk/tls-suppress-intermediates/issues/12 > > Regarding security and privacy, the most severe impact of any attack > I can come up with is determining if some arbitrary ICA is on the > ICA list or not (for passive attacks, that is restricted to the issuing > ICA used by the server). Practical impact of attacker being able to do > that depends on how many endpoints share that same ICA list. > > Rough outline of the attack (active variant): Fabricate a certificate > purporting to be from some ICA, send it to client and observe if the > client retries (ICA not on the list) or just fails (ICA is on the list). I'm hopeful that some may be interested to perform a more thorough analysis. We saw enough complexity with respect to previous TLS versions and the fallback logic being possible to induce downgrade attacks that I think we should be very wary about introducing a class of anticipated handshake failures that require connection re-establishment, especially across independent TLS sessions. I realize that sounds a little like FUD, but rather: every time we've tried to do this, it's blown up spectacularly, so we need to make sure we're not setting up another bomb. I also think the active attack analysis is a bit lacking, especially since the attacker has the ability to mint arbitrary ICAs on demand, without running afoul of any existing client policies. For example, for the Web PKI, by virtue of nameConstraints without pathLen in the basicConstraints, the site can mint arbitrary ICAs and arbitrary EE certificates. Combined with the discovery mechanism discussed, this is effectively the same as other forms of stateful tracking (ala HSTS tracking), and thus likely to be subjected to the same mitigations that would largely render the benefits here ineffective, at best. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Sat, Feb 19, 2022 at 03:59:23AM +, Kampanakis, Panos wrote: > - If we can assume an OOB mechanism to load the ICAs then we can > simplify things. Practically we can assume there is no failure. > Agreed, but I am not sure that we should not include any > non-normative language for the inadvertent corner case though. > There should be a fallback, one that we are assuming will never > happen, but an implementer should account for it. It seems to me that the dominant failure modes are: - Using old ICA list that is missing some newly minted ICA. - Using custom TA that is missing ICA data. > - Connection re-establishment affects the security and privacy > assumptions and should be captured. I am not sure the concern is > worse than the regular fingerprinting text already in the draft, > but point taken. We can improve the text and I created an issue > for it. https://github.com/csosto-pk/tls-suppress-intermediates/issues/12 Regarding security and privacy, the most severe impact of any attack I can come up with is determining if some arbitrary ICA is on the ICA list or not (for passive attacks, that is restricted to the issuing ICA used by the server). Practical impact of attacker being able to do that depends on how many endpoints share that same ICA list. Rough outline of the attack (active variant): Fabricate a certificate purporting to be from some ICA, send it to client and observe if the client retries (ICA not on the list) or just fails (ICA is on the list). > I would be interested to track how that ICA list has been changing > over time. Let’s see if we can get data on that for FFs preload > list, Filippo’s or others. I only have some isolated random datapoints on number of disclosed WebPKI ICAs since 2021-02-08 (a bit over year ago), but during that time, that number has grown from 1669 to 1820. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Fri, Feb 18, 2022 at 04:47:09AM +, Kampanakis, Panos wrote: > > About the tlsflags, make sense. It would simplify things too. The > impression I got from the old draft-thomson-tls-sic thread and the > tlsflags draft was that it mandates an acknowledgement. I will > confirm with Yoav. The text in tlsflags looks like it mandates an acknowledgement, but I think it might be just confusing text. Regarding actual need for acknowledgement for this flag, I think that server acknowledging it could be useful so client knows if retrying without flag could be useful or not. For the client acknowledging it, I find that much less useful. If server proposes the extension, it better have exhaustive issuer list, be using certificates as just holders for raw public keys, or using certificate fingerprints for identification. Anything else looks like it is asking for trouble. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
> > I'm not sure I would agree that a 3-8 MB handshake to preserve the status > quo is exactly low hanging fruit. > If we use Dilithium2 for every signature, we're looking at about 17kB extra — not 3-8MB. ICA suppression removes one public key and signature, so 3.7kB. This is where looking to see what can be done to remove the necessity of > those SCTs and OCSPs, rather than trying to patch them into a PQ world. > If Rainbow or GeMMS doesn't make the cut, then replacing SCTs by inclusion proofs (to some daily picked side-loaded STHs) could be interesting (as they're ~1kB each), but that's not low hanging fruit. > The viability of CT itself becomes more suspect in a world of ginormous > signatures, > Dilithium2 and Falcon signatures+public keys are 2.4+1.3kB and 666+897B respectively. That won't cause trouble for CT. Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Wed, Feb 16, 2022 at 2:41 PM Kampanakis, Panos wrote: > Some responses below (sorry long email): > No worries, I think this invites some long responses, in part, because it's complex. > > how is that functionally different than simply saying "Intermediate 2" > is the Trust Anchor, using the computed outputs (RFC 5280, Section 6.1.6) > for Intermediate 2 as the inputs for RFC 5280, 6.1.1's algorithm for > validating End Entity? What value does "Intermediate 1", or "Root 1", serve > from a protocol or conceptual layer? > > > > Agreed, it is not different. But I believe adding Intermediates to the > trust bundle is less straightforward to be deployed everywhere especially > when expanding the scope to many more CAs. Note that the draft does not > consider the ICA list a trust list. It is just a list to build the chain. > There is some text in the draft trying to convey that. > I don't think I communicated this well then. Although this is trying to do something simple (in as much as treating the TLS and PKI layers distinct), I think it's missing that it's shifting a significant portion of that problem to PKI layer (re: synchronizing those ICAs), and also introducing complexity to the TLS layer (re: fallbacks and retries). If the problem statement is primarily oriented around PQ, then perhaps it's better to explore a solution that tries to keep both layers simple. Basically, it needs to be a little crisper what the client capabilities are. Presently, it handwaves them as out-of-scope, but as a consequence, makes it difficult to justify the assumptions/complexity that they hide. Does the client have durable storage (e.g. does the IoT device need rewritable media and not just ROM)? Does the client have a reliable (within TBD3) out-of-band update mechanism for metadata such as intermediates? Is the TLS implementation expected to be able to re-establish a connection (which many TLS APIs are not themselves responsible for, or at least, abstract that away)? These all affect the shape of the present design, but also any simplifications. > But although the directory option is the most straightforward option, > there is a dynamic cache building element too. I have experimented with > this a bit; someone may not even need a full ICA list. It could build its > cache dynamically as it starts connecting to peers. > As you captured later, this is (effectively) reintroducing TLS fallback. We worked very hard to try to minimize that, and while there are retries (ala HRR), they're integrated into the connection state machine. Needing to re-establish a new connection, sans flag, is a very big failure mode here, and one that definitely influences the shape of API design. Equally, this introduces some of the privacy risks that the EDNOTE was trying to dodge. It seems like the choice to reintroduce "connection re-establishment" logic would have bearing on the security and privacy assumptions here, and is worth making sure it's captured. Alternatively, if we take out this on-demand discovery piece, then we're effectively saying "Clients need a reliable update channel for this to work". Which may be a reasonable thing, but equally, it opens up the realm for simplifications, as discussed above and below here. > We just want the peer to declare “I somehow know my peer ICAs”. > Right, the criticism in the past is that it's not "I somehow know", but rather, "I *think* I know my peer's CAs", with some probability of being wrong. The what to do when things are wrong is important, and realizing that different peers may be more or less wrong (e.g. depending on update cadences) has a significant impact on deployability. > > > I'm not suggesting online signing by roots, but rather, that this > extension firmly rejects the "trust roots, discover intermediates" model of > 1996, so why shouldn't we lean into this more for PQ? > > > > Good point. I think the challenge is the significant scope change as you > are suggesting because now you are supposed to vet and somehow trust many > more CAs that don’t have their key offline like roots do. Generally, > significant changes like that scare me. Also let’s not forget the > challenges of having the TLS client say “if PQ, do PKI differently, else > keep the Netscape model”. > So, two responses. - In your responses to Ilari, and your original message, there seems to be some assumption that Mozilla policy is representative and reflective of what's possible here (c.f. disclosures). As much as I love and have actively contributed to that policy, I'm also uncomfortable with using it as a stand-in for the Web PKI or generalizations. That said, because you were willing to lean on it regarding constrained intermediates, then it should be clear that the "vet and trust more CAs" has already been a part of the policy for some time. Every intermediate is subjected to the same policies, the purpose of disclosure of said intermediates was intentionally to support that vetting first and foremost
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Wed, Feb 16, 2022, at 22:26, Ilari Liusvaara wrote: > I think the language in tlsflags about acknowledging extensions is > confusing. Tlsflags behavior should be similar to extensions, which do > not have acknowledgment requirement in base TLS (any acknowledgement > requirement is per extension). So I think any acknowledgement > requirement should be explicitly stated normatively. I agree with Ilari here. We shouldn't need to acknowledge this extension. And, as far as I can tell, the flags draft doesn't require it (though I admit that the text there on binary AND is confusing). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Wed, Feb 16, 2022 at 05:45:47AM +, Kampanakis, Panos wrote: > Good comments, thank you Ilari. > > To answer your comments > > > 1) There are a few "shall" in the text. Should those be "SHALL"? > > The two "shall" refer to draft-ietf-tls-tlsflags. Based on experience > from previous drafts, we do not want to repeat normative language > from another draft, so we kept them lowercase. We can still consider > making them normative though. I think the language in tlsflags about acknowledging extensions is confusing. Tlsflags behavior should be similar to extensions, which do not have acknowledgment requirement in base TLS (any acknowledgement requirement is per extension). So I think any acknowledgement requirement should be explicitly stated normatively. As to why I find tlsflags language confusing: I think flags as shorthand for empty extensions, and TLS extensions can be capability advertisments (no reply). E.g., compress_certificate, which happens to add a new HandshakeType. > > 3) Why there are two flags? I do not see a case where both would > > be sent in the same message. > > In the original draft there was only one. But we want for both the > client and server (CertReq) to be able to signal to their peer to > suppress CAs. draft-ietf-tls-tlsflags defines that the peer needs to > acknowledge the flag, thus we needed one per direction. There are no less than four existing TLS extensions (and flags work similarly to extensions), which work in both directions with the same codepoint, in the IANA registry: - status_request - signed_certificate_timestamp - delegated_credentials - transparency_info And there does not seem to be a percedent for extension that works in both directions, but with different codepoints. > > 4) In WebPKI, there are some cornercases (constrained ICAs) where > > the client might be missing a certificate or certificates in the > > chain. Currently the WebPKI root program rules allow not disclosing > > "technically constrained" certificates (but there are plans to > > change this). > > Good point. That has come up in discussions with my co-authors. As > Martin was pointing out, a lot hinges on the semantics of the > tls_flags bit. We probably can say that it means "I have all the > intermediates I am willing to accept". That's a little too absolute > for the web PKI as it stands. We don't have stats on how often we'd > fail as a result; we would have to check but unconstrained > intermediates probably isn't exceptional. The flag should probably > say "I have all the *unconstrained* intermediates that I'm willing > to accept" or maybe "I have all the intermediates from that I'm > willing to accept, unless it's the WebPKI and then I only have > unconstrained intermediates"' I would expect constrained intermediates to be quite rare. IIRC, there is a lot of red tape in Baseline Requirements about constrained ICAs. > But if MSRP 2.8 adds constrained intermediates, then "I have all the > intermediates I am willing to accept" may just suffice. MSRP 2.8 is slated for this year, so it might very well fix this issue for WebPKI. Another way to address the issue would be to write some text that the server might want to send any ICA that has not been publically disclosed. As that is neutral to PKI and is exactly what makes constrained ICAs problematic here. > > 5) In the client auth scenario, the server might have exhaustive > > list of all issuing ICAs it accepts, so including any ICAs is never > > necressary. However, this might be handled even currently by not > > giving the client a chain. However, doing this in other direction > > can be quite dangerous without prior agreement. > > I am not sure I am following that argument. If the client does not > have a chain what happens if the server does not have all > intermediates? Sending ICA will not help: The authentication would still fail. But actually, if using public PKI certificates for client auth (usually not a great idea), then this can fail rather badly with legacy servers that do not have issuing ICA lists at all. > By quite dangerous do you mean that if they have not pre-agreed on > the ICA list there could be an auth failure and recovery will not > be easy because the server can't track the clients it is expecting > ICAs from? Am I getting you right? The problem is legacy clients. If one of those connects to the server and server omits the chain, that will cause handshake failure. Unfortunately, currently there are fair amount of misconfigured servers that behave this way. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
Good comments, thank you Ilari. To answer your comments > 1) There are a few "shall" in the text. Should those be "SHALL"? The two "shall" refer to draft-ietf-tls-tlsflags. Based on experience from previous drafts, we do not want to repeat normative language from another draft, so we kept them lowercase. We can still consider making them normative though. > 2) Section 3.2: "To prevent a failed TLS connection, a client could chose to > not send its intermediates regardless of the flag from the server, if it has > a reason to believe the issuing CAs do not exist in the server ICA list." > ... Shouldn't the client send its intermediates if it thinks the server does > not have them. You are right. Nit. We will fix it. I created issue https://github.com/csosto-pk/tls-suppress-intermediates/issues/5 for it. > 3) Why there are two flags? I do not see a case where both would be sent in > the same message. In the original draft there was only one. But we want for both the client and server (CertReq) to be able to signal to their peer to suppress CAs. draft-ietf-tls-tlsflags defines that the peer needs to acknowledge the flag, thus we needed one per direction. > 4) In WebPKI, there are some cornercases (constrained ICAs) where the client > might be missing a certificate or certificates in the chain. > Currently the WebPKI root program rules allow not disclosing "technically > constrained" certificates (but there are plans to change this). Good point. That has come up in discussions with my co-authors. As Martin was pointing out, a lot hinges on the semantics of the tls_flags bit. We probably can say that it means "I have all the intermediates I am willing to accept". That's a little too absolute for the web PKI as it stands. We don't have stats on how often we'd fail as a result; we would have to check but unconstrained intermediates probably isn't exceptional. The flag should probably say "I have all the *unconstrained* intermediates that I'm willing to accept" or maybe "I have all the intermediates from that I'm willing to accept, unless it's the WebPKI and then I only have unconstrained intermediates"' But if MSRP 2.8 adds constrained intermediates, then "I have all the intermediates I am willing to accept" may just suffice. I created issue https://github.com/csosto-pk/tls-suppress-intermediates/issues/6 for this. > 5) In the client auth scenario, the server might have exhaustive list of all > issuing ICAs it accepts, so including any ICAs is never necressary. However, > this might be handled even currently by not giving the client a chain. > However, doing this in other direction can be quite dangerous without prior > agreement. I am not sure I am following that argument. If the client does not have a chain what happens if the server does not have all intermediates? By quite dangerous do you mean that if they have not pre-agreed on the ICA list there could be an auth failure and recovery will not be easy because the server can't track the clients it is expecting ICAs from? Am I getting you right? -Original Message- From: TLS On Behalf Of Ilari Liusvaara Sent: Monday, February 14, 2022 2:43 AM To: tls@ietf.org Subject: RE: [EXTERNAL] [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Mon, Feb 14, 2022 at 03:33:05AM +, Kampanakis, Panos wrote: > Hi TLS WG, > > This draft draft-kampanakis-tls-scas-latest is attempting to resurrect > Martin’s original draft-thomson-tls-sic. It proposes using two new TLS > 1.3 flags (draft-ietf-tls-tlsflags ) to signal to the TLS server or > client to not send its Intermediate CA (ICA) certificates. > > Feedback and discussion are welcome. > > -Original Message- > From: internet-dra...@ietf.org > Sent: Sunday, February 13, 2022 2:34 PM > To: Bas Westerbaan ; Bytheway, Cameron > ; Martin Thomson ; Kampanakis, > Panos > Subject: [EXTERNAL] New Version Notification for > draft-kampanakis-tls-scas-latest-00.txt > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > > A new version of I-D, draft-kampanakis-tls-scas-latest-00.txt > has been successfully submitted by Panos Kampanakis and posted to the IETF > repository. > > Name: draft-kampanakis-tls-scas-latest > Revision: 00 > Title: Suppressing CA Certificates in TLS 1.3 > Document
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
Hi Panos, There was additionally some discussion during IETF 105 [1], which looked a bit about the problem. As a problem statement, it's definitely an interesting problem, and certainly, one we need to start preparing to solve practically. I think one very direct question is this: If we are confident that the client and server have negotiated some shared trust bundle reliably, why would we use intermediates at all? That is, if a given client knows a certificate path such that Root->Intermediate 1->Intermediate 2 exists, sufficient that it can be omitted within the TLS exchange and only send End Entity, then how is that functionally different than simply saying "Intermediate 2" is the Trust Anchor, using the computed outputs (RFC 5280, Section 6.1.6) for Intermediate 2 as the inputs for RFC 5280, 6.1.1's algorithm for validating End Entity? What value does "Intermediate 1", or "Root 1", serve from a protocol or conceptual layer? This might sound too abstract, but I think highlights the core concept of the proposal, which is that certificate path building and validation become unnecessary in a scheme where we're eliding intermediates. In the original deployment model of TLS using X.509, the certificates sent were simply pointers into the X.500 Directory. Of course, we all know that didn't manifest, and we certainly don't depend on the Directory, and so we used the certificate chains provided in-band to communicate trust in a world where the Directory doesn't exist. The flags proposal, in effect, is introducing the notion of a "static Directory" - such as the examples you pointed to of Mozilla's CSV output or Filippo's consolidation of that output. I realize this suggests a much larger change to the trust model we've inherited from Netscape's snap decisions 25 years ago, but given PQ, does it make sense to re-examine whether or not we need such intermediates at all? That is, if we're willing to say "This is signed by Intermediate 2, and you're expected to know about it and its limitations", how is this different from saying "This is signed by Trust Anchor Foo, and you're expected to know about it and its limitations". I'm not suggesting online signing by roots, but rather, that this extension firmly rejects the "trust roots, discover intermediates" model of 1996, so why shouldn't we lean into this more for PQ? I'm not sure I see addressed in the draft how it handles the problem previously raised on the mic [1] and on the list [2], regarding version skew problems. Section 3.1 of the draft states "To prevent a failed TLS connection, a client MAY choose not to send the flag if its list of ICAs hasn't been updated in TBD3 time or has any other reason to believe it does not include the ICAs for the peer", but this leaves a lot open to interpretation. For example, is it expected that clients will retry the connection, as suggested in [3]? That seems to be the suggestion from 3.1's "If the connection still fails ... the client MUST NOT send the flag in a subsequent connection to the server". Or is this meant to be left unspecified, similar to Section 3's "It is beyond the scope of this document to define how CA certificates are identified and stored"? It seems rather fundamental to the assessment of the proposal to understand the proposed client behaviours here. A significant amount of practicality for this proposal rests on what the value for TBD3 is. For example, if this is seen as the only practically viable (at Internet scale) way to deploy PQ, then we should presume that a failure for the client to have a fresh set is, effectively, a failure to communicate with a site that needs such a fresh set. Have I misunderstood the conclusions of your research [4]? If this is functionally necessary for certain deployments, then the choice of TBD3 is a reflection of "How long do servers/CAs need to wait, before a newly provisioned intermediate becomes practically deployable"? When Certificate Transparency (RFC 6962) examined a similar question, the suggestion by CAs then was that 24 hours (the proposed CT MMD for direct integration into the log) was untenable, and thus SCTs, the "immediate promise to log, without proof of having been integrated into the Merkle tree", were introduced. Ilari's point about technically constrained subordinates is related to this; even for those not constrained, today's ecosystem has them functionally usable immediately, and disclosure is not required for week(s) after by policies, if at all. The choice of TBD3 is both a reflection of, and an expectation of, broader ecosystem behaviours and changes, but which are left somewhat minimally specified, and which seems rather substantial. The current draft doesn't address the question about how "The Web PKI" is not a comprehensive set of all CAs, but rather, an overlapping/intersecting set from independent vendors. This raises practical questions about deployability, because it speaks a bit to trust anchor agility within these applications. F
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Mon, Feb 14, 2022 at 03:33:05AM +, Kampanakis, Panos wrote: > Hi TLS WG, > > This draft draft-kampanakis-tls-scas-latest is attempting to resurrect > Martin’s original draft-thomson-tls-sic. It proposes using two new TLS > 1.3 flags (draft-ietf-tls-tlsflags ) to signal to the TLS server or > client to not send its Intermediate CA (ICA) certificates. > > Feedback and discussion are welcome. > > -Original Message- > From: internet-dra...@ietf.org > Sent: Sunday, February 13, 2022 2:34 PM > To: Bas Westerbaan ; Bytheway, Cameron > ; Martin Thomson ; Kampanakis, Panos > > Subject: [EXTERNAL] New Version Notification for > draft-kampanakis-tls-scas-latest-00.txt > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > > A new version of I-D, draft-kampanakis-tls-scas-latest-00.txt > has been successfully submitted by Panos Kampanakis and posted to the IETF > repository. > > Name: draft-kampanakis-tls-scas-latest > Revision: 00 > Title: Suppressing CA Certificates in TLS 1.3 > Document date: 2022-02-13 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-kampanakis-tls-scas-latest-00.txt > Status: > https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-latest/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest > Some quick comments: 1) There are a few "shall" in the text. Should those be "SHALL"? 2) Section 3.2: "To prevent a failed TLS connection, a client could chose to not send its intermediates regardless of the flag from the server, if it has a reason to believe the issuing CAs do not exist in the server ICA list." ... Shouldn't the client send its intermediates if it thinks the server does not have them. 3) Why there are two flags? I do not see a case where both would be sent in the same message. 4) In WebPKI, there are some cornercases (constrained ICAs) where the client might be missing a certificate or certificates in the chain. Currently the WebPKI root program rules allow not disclosing "technically constrained" certificates (but there are plans to change this). 5) In the client auth scenario, the server might have exhaustive list of all issuing ICAs it accepts, so including any ICAs is never necressary. However, this might be handled even currently by not giving the client a chain. However, doing this in other direction can be quite dangerous without prior agreement. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
Hi TLS WG, This draft draft-kampanakis-tls-scas-latest is attempting to resurrect Martin’s original draft-thomson-tls-sic. It proposes using two new TLS 1.3 flags (draft-ietf-tls-tlsflags ) to signal to the TLS server or client to not send its Intermediate CA (ICA) certificates. It assumes that we can pre-cache or load all the necessary intermediate CAs in order to build the cert chains to authenticate peers. As a data point, the size of a full ICA cache for the web would be 1-2MB (1-2 thousand ICAs) based on testing and 3rd party data [7][8]. 1-2MB is trivial for most usecases. When it is not, other caching mechanisms can be used. The main usecases that would benefit from this would be - post-quantum (D)TLS (PQ certs are going to be big and thus introduce issues for (D)TLS and QUIC [1][2][3][4]). - EAP-TLS in cases with big cert chains [5][6] - constrained environments where even a few KB in a (D)TLS handshake matter We believe we have addressed the comments regarding the original draft https://mailarchive.ietf.org/arch/browse/tls/?q=draft-thomson-tls-sic Feedback and discussion are welcome. Rgs, Panos [1] https://blog.cloudflare.com/sizing-up-post-quantum-signatures/ [2] https://www.ndss-symposium.org/ndss-paper/post-quantum-authentication-in-tls-1-3-a-performance-study/ [3] https://dl.acm.org/doi/10.1145/3386367.3431305 [4] https://assets.amazon.science/00/f8/aa76ff93472d9b55b6a84716e34c/speeding-up-post-quantum-tls-handshakes-by-suppressing-intermediate-ca-certificates.pdf [5] https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert [6] https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13 [7] https://github.com/FiloSottile/intermediates [8] https://ccadb-public.secure.force.com/mozilla/MozillaIntermediateCertsCSVReport -Original Message- From: internet-dra...@ietf.org Sent: Sunday, February 13, 2022 2:34 PM To: Bas Westerbaan ; Bytheway, Cameron ; Martin Thomson ; Kampanakis, Panos Subject: [EXTERNAL] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. A new version of I-D, draft-kampanakis-tls-scas-latest-00.txt has been successfully submitted by Panos Kampanakis and posted to the IETF repository. Name: draft-kampanakis-tls-scas-latest Revision: 00 Title: Suppressing CA Certificates in TLS 1.3 Document date: 2022-02-13 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-kampanakis-tls-scas-latest-00.txt Status: https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-latest/ Htmlized: https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest Abstract: A TLS client or server that has access to the complete set of published intermediate certificates can inform its peer to avoid sending certificate authority certificates, thus reducing the size of the TLS handshake. The IETF Secretariat ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
