Subject: [TLS] Proposed changes to draft-ietf-tls-subcerts

From: "Patton,Christopher J" <[email-masked]>
Date: Wed, 18 Jul 2018 01:17:44 +0000

Hi all,

I've added a few pull requests to the draft "Delegated credentials for TLS" that address the proposals discussed at IETF.

Specifically:

  *   https://github.com/tlswg/tls-subcerts/pull/8 -- Creates a tighter binding of the DC to the handshake parameters;
  *   https://github.com/tlswg/tls-subcerts/pull/9 -- Permits mandatory delegation-key isolation, addresses the proposed"must-use-DC" TLS feature extension;
  *   https://github.com/tlswg/tls-subcerts/pull/10 -- drops support for TLS 1.2.

Comments on these changes are welcome; feel free to chime in on GitHub.

Thanks,
Chris Patton

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 18 Jul 2018 09:56:16 +0300

> Comments on these changes are welcome; feel free to chime in on GitHub.

The way mandatory delegation-key usage is specified seems to violate how
X.509 critical bit is supposed to work. The bit is not supposed to alter
processing of recogized extensions, it is only supposed to alter processing
of unrecognized extensions from ignore to reject.

If you want to actually alter the processing to require such
certificate to always only be used for DC, you need a flag somewhere
else, which might be payload of the extension (and that extension
should _also_ be marked critical to ensure that clients that do not
understand DC do not accept it).

-Ilari

---

From: "Patton,Christopher J" <[email-masked]>
Date: Wed, 18 Jul 2018 17:33:05 +0000

Hi Ilari, I suppose you mean that this condition violates the critical bit semantics: "If the extension is marked critical, then the server MUST NOT offer the certificate unless it offers a delegated credential as well."

Your suggesting adding a "must-use-DC" flag to the extension body? The condition would be: "If the <must-use-DC> flag of the extension is set, then the server MUST NOT offer the certificate unless ..."

________________________________
From: [email-masked] <[email-masked]> on behalf of Ilari Liusvaara <[email-masked]>
Sent: Wednesday, July 18, 2018 2:56 AM
To: Patton,Christopher J
Cc: [email-masked]
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

On Wed, Jul 18, 2018 at 01:17:44AM +0000, Patton,Christopher J wrote:
>   *   https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2Dsubcerts_pull_8&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Jkn0aWEFHUhGyKTRFXHGPt7fdDUvxeXGJQkwmPR2HdU&e= -- Creates a tighter binding of the DC to the handshake parameters;
>   *   https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2Dsubcerts_pull_9&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=lsmtgnR-B-sA-BU_CcpbAtB7UC4Q0zyFqOLOGB3-FZM&e= -- Permits mandatory delegation-key isolation, addresses the proposed"must-use-DC" TLS feature extension;
>   *   https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2Dsubcerts_pull_10&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Q1-PUQoj_LL4tFA4UPxTUiiUNRYfsdAf9nhNCaAItZY&e= -- drops support for TLS 1.2.
>

-Ilari

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 18 Jul 2018 18:00:32 -0400

I do not think you can change an extension syntax or semantic.  It is three
tuple: extn ID, criticality flag, and value.

You can add the syntax and semantics  within the extension value as to what
it means.   That may not help those who do not understand the extension and
cannot process the value.

From: TLS [mailto:[email-masked]] On Behalf Of Patton,Christopher J
Sent: Wednesday, July 18, 2018 1:33 PM
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

Hi Ilari, I suppose you mean that this condition violates the critical bit
semantics: "If the extension is marked critical, then the server MUST NOT
offer the certificate unless it offers a delegated credential as well."

Your suggesting adding a "must-use-DC" flag to the extension body? The
condition would be: "If the <must-use-DC> flag of the extension is set, then
the server MUST NOT offer the certificate unless ..."

  _____  

From: [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> > on behalf of
Ilari Liusvaara <[email-masked] <mailto:[email-masked]>
Sent: Wednesday, July 18, 2018 2:56 AM
To: Patton,Christopher J
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts 

On Wed, Jul 18, 2018 at 01:17:44AM +0000, Patton,Christopher J wrote:
> Hi all,
> 
> 
> I've added a few pull requests to the draft "Delegated credentials for
TLS" that address the proposals discussed at IETF.
>   *
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2D
subcerts_pull_8
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2
Dsubcerts_pull_8&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VK
s6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Jkn0aWE
FHUhGyKTRFXHGPt7fdDUvxeXGJQkwmPR2HdU&e=>
&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A
bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Jkn0aWEFHUhGyKTRFXHGPt7
fdDUvxeXGJQkwmPR2HdU&e= -- Creates a tighter binding of the DC to the
handshake parameters;
>   *
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2D
subcerts_pull_9
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2
Dsubcerts_pull_9&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VK
s6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=lsmtgnR
-B-sA-BU_CcpbAtB7UC4Q0zyFqOLOGB3-FZM&e=>
&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A
bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=lsmtgnR-B-sA-BU_CcpbAtB
7UC4Q0zyFqOLOGB3-FZM&e= -- Permits mandatory delegation-key isolation,
addresses the proposed"must-use-DC" TLS feature extension;
>   *
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2D
subcerts_pull_10
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2
Dsubcerts_pull_10&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=V
Ks6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Q1-PUQ
oj_LL4tFA4UPxTUiiUNRYfsdAf9nhNCaAItZY&e=>
&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A
bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Q1-PUQoj_LL4tFA4UPxTUii
UNRYfsdAf9nhNCaAItZY&e= -- drops support for TLS 1.2.
> 
> Comments on these changes are welcome; feel free to chime in on GitHub..

-Ilari

---

From: "Patton,Christopher J" <[email-masked]>
Date: Thu, 19 Jul 2018 19:04:31 +0000

Thanks both of you for the feedback.

I've revised the PR:

https://github.com/tlswg/tls-subcerts/pull/9

There's now a "strict" flag that, if set, requires the server to offer a DC. In Sec. 6.1, I describe why I think this is sufficient. Let me know what you think!

Best,

Chris

________________________________
From: Santosh Chokhani <[email-masked]>
Sent: Wednesday, July 18, 2018 6:00 PM
To: Patton,Christopher J; 'Ilari Liusvaara'
Cc: [email-masked]
Subject: RE: [TLS] Proposed changes to draft-ietf-tls-subcerts

I do not think you can change an extension syntax or semantic.  It is three tuple: extn ID, criticality flag, and value.

You can add the syntax and semantics  within the extension value as to what it means.   That may not help those who do not understand the extension and cannot process the value.

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> on behalf of Ilari Liusvaara <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 18, 2018 2:56 AM
To: Patton,Christopher J
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 19 Jul 2018 22:39:38 +0300

On Thu, Jul 19, 2018 at 07:04:31PM +0000, Patton,Christopher J wrote:
> There's now a "strict" flag that, if set, requires the server to
> offer a DC. In Sec. 6.1, I describe why I think this is sufficient.
> Let me know what you think!

Ugh, it occurs to me that to have proper processing in all cases,
including client that does not support DC and client that does and
ignores criticality of supported extensions, you need to have
critical flag and strict flag mirror each other.

-Ilari

---

From: "Patton,Christopher J" <[email-masked]>
Date: Thu, 19 Jul 2018 19:56:05 +0000

So you think we need that the extension is marked critical if and only if the strict flag is set? That wouldn't be ideal. Can you explain your thinking? Which case presents a problem?

________________________________
From: [email-masked] <[email-masked]> on behalf of Ilari Liusvaara <[email-masked]>
Sent: Thursday, July 19, 2018 3:39 PM
To: Patton,Christopher J
Cc: Santosh Chokhani; [email-masked]
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

On Thu, Jul 19, 2018 at 07:04:31PM +0000, Patton,Christopher J wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2Dsubcerts_pull_9&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=_AoKRFspNsT-b4Jjhi1qtaEQ7O68i_qvVS7Gwt9TkB0&s=fZWPg8E9BJ_dXERlQXMDWwzI0uzp5mFFkN9roNzSXpk&e=

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 19 Jul 2018 23:18:46 +0300

On Thu, Jul 19, 2018 at 07:56:05PM +0000, Patton,Christopher J wrote:
> So you think we need that the extension is marked critical if and
> only if the strict flag is set? That wouldn't be ideal. Can you
> explain your thinking? Which case presents a problem?

There are two types of clients:

1) Clients that do not know about DC.

- These clients never use DC.
- These do not understand the DC extension.
- If you want non-strict certificate, it has to have critical=false
  on DC extension.
- If you want strict certificate, it has to have critical=true on
  DC extension.

2) Clients that support DC.

- These clients may or may not use DC.
- These understand the DC extension.
- As consequence, criticality of DC extension is ignored by X.509
  rules.
- So to specify if certificate is strict, you need a flag inside
  the extension.

And in the end, the two flags always end up mirroring each other,
but signifying different things.

-Ilari

---

From: "Patton,Christopher J" <[email-masked]>
Date: Thu, 19 Jul 2018 20:39:11 +0000

Suppose that strict delegation usage is required (strict=true). Is it valid for the extension to be non-critical (crit=false)? No, because the server has to serve a DC, even if the client doesn't request one. Thus, strict=true implies that crit=true.

Now let's check the converse. Suppose that the crit=true. Is it valid for strict to be false? Yes, because the extension being critical only means that the client has to understand DC in order to accept the certificate. But this doesn't mean they must negotiate a DC.

So I agree with one case you point out: If strict delegation usage is required, then the extension must be critical. However, if the extension is critical, both strict and non-strict delegation usage are valid.

Do you agree? If so, I'll amend the draft accordingly.

Chris

Sent: Thursday, July 19, 2018 4:18 PM

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 20 Jul 2018 18:51:27 +0300

On Thu, Jul 19, 2018 at 08:39:11PM +0000, Patton,Christopher J wrote:
> 
> Now let's check the converse. Suppose that the crit=true. Is it valid
> for strict to be false? Yes, because the extension being critical
> only means that the client has to understand DC in order to accept
> the certificate. But this doesn't mean they must negotiate a DC.

It might have well-defined technical meanining, but I consider it
nonsensical. Because it means that if client does not understand DC,
it must reject the certificate, but if client understands DC, it can
accept it even in non-DC contexts. 

The other mismatch case also has well-defined technical meaning, it
means that client that does not understand DC can use the certificate,
but client that understands DC can only use it in DC context.

I do not consider either of these two cases sensible.

-Ilari

---

From: "Patton,Christopher J" <[email-masked]>
Date: Fri, 20 Jul 2018 18:41:14 +0000

> Because it means that if the client does not understand DC, then it must reject the certificate, ...

This is the desired behavior, as far as I understand.

> ... but if client understands DC, it can accept it even in non-DC contexts.
I don't see why this is nonsensical. One way to understand this is that the server is presenting a certificate that it only wants to use with DC-capable clients. Perhaps noone would want to actually use this configuration, but I don't see why it should be deemed invalid.

> but client that understands DC can only use it in DC context.
I don't quite understand. The issue I believe you pointed out is that when the extension is non-critical, but the strict flag is set, the server will be compelled to serve a DC even if the client doesn't support it. The relevant text (you'll have to look at the source on GitHub) is: "The extension MAY be marked crititcal. (See Section 4.2 of [RFC5280].) If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an “illegal_parameter” alert." A client who doesn't speak DC will either abort with an "unexpected_message" alert, or if it ignores the extension, then verification of the handshake will fail, since it's using the end-entity certificate public key, and not the DC public key.

Thus, I believe the only valid configurations are:

  *   strict=true, crit=true;
  *   strict=false, crit=true; and
  *   strict=false, crit=false.

The revised text should be:
"If the strict boolean is set to true, then the extension MUST be marked critical; otherwise it MAY be marked non-crititcal. If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an “illegal_parameter” alert.

-Chris

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Jul 2018 20:16:29 +0300

> Thus, I believe the only valid configurations are:

Sanity check: If DC is not used, then either all clients accept, or all
clients reject.

>   *   strict=true, crit=true;

Both reject. Satistifes the check.

>   *   strict=false, crit=true; and

Clients that support DC accept, clients that do not support DC
reject. This fails the check above.

>   *   strict=false, crit=false.

Both accept. Satisfies the check.

(The fourth, strict=true, crit=false, would also fail the check).

Actually, what usecase do strict certificates serve anyway? I can not
figure out any usecase that would make much sense to me. Dealing with
server endpoints that are capable of LURK but not proof-of-possession
nor is the keyserver capable of format-checking?

The usecase for the X.509 extension to signal support is to signal
the service the needed infrastructure for delegating subcertificates
(including having LURK as standby).

-Ilari

---

From: "Patton,Christopher J" <[email-masked]>
Date: Tue, 24 Jul 2018 18:04:27 +0000

Aww, I see your point. You're right, it should be that crit=true if and only if crit=true.

> nor is the keyserver capable of format-checking?

The point was to enforce that, if a delegation certificate is offered in a handshake, then a DC must be negotiated in that handshake. I wasn't actually there, but I'm told that this feature was brought up at IETF. It doesn't seem like there's a clean way to do this, and I'm not sure this feature is worth the added complexity.

I'm going to propose we drop the strict flag and let the critical bit be optional for the extension. What do you think?

-Chris