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

["Kampanakis, Panos" <[e-mail]>]

Thx Ilary. 

ACK about the unconstrained CAs and the MSRP 2.8. I updated the git issue and we will address it in text. 

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. 



-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Wednesday, February 16, 2022 6:27 AM
To: Kampanakis, Panos <[e-mail]>
Cc: [e-mail]
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 Wed, Feb 16, 2022 at 05:45:47AM +0000, 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