Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

[Ilari Liusvaara <[e-mail]>]

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: [e-mail] <[e-mail]> 
> Sent: Sunday, February 13, 2022 2:34 PM
> To: Bas Westerbaan <[e-mail]>; Bytheway, Cameron <[e-mail]>; Martin Thomson <[e-mail]>; Kampanakis, Panos <[e-mail]>
> 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