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 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.ie
