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 <tls-bounces@ietf.org> 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 +0000, 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-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: Sunday, February 13, 2022 2:34 PM
> To: Bas Westerbaan <bas@cloudflare.com>; Bytheway, Cameron 
> <bythewc@amazon.com>; Martin Thomson <mt@lowentropy.net>; Kampanakis, 
> Panos <kpanos@amazon.com>
> 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