Subject: [TLS] Adoption call for draft-davidben-tls13-pkcs1

From: "Christopher Wood" <[email-masked]>
Date: Fri, 18 Oct 2019 11:44:03 -0700

This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, which can be found here:

   https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00

It will run until November 1, 2019. Please indicate whether or not you would like to see this draft adopted and whether you will review and provide feedback on it going forward.

Thanks,
Chris, Joe, and Sean

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Oct 2019 18:46:24 +0000

I support adoption, will contribute.

---

From: David Benjamin <[email-masked]>
Date: Fri, 18 Oct 2019 16:15:36 -0400

I also support adoption and will contribute, unsurprisingly. :-)

On Fri, Oct 18, 2019 at 2:46 PM Salz, Rich <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hubert Kario <[email-masked]>
Date: Mon, 21 Oct 2019 15:42:39 +0200

On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote:
> It will run until November 1, 2019. Please indicate whether or not you would
> like to see this draft adopted and whether you will review and provide
> feedback on it going forward.

Yes, requiring RSA-PSS causes interoperability issues with smartcards that 
don't implement this 16 year old algorithm. But being able to say "if you're 
using TLS 1.3 that means you are not using legacy crypto" has non 
insignificant value too.

This document erodes that.

So I'm against adoption of this draft by the WG.

If it is adopted, I will review and provide feedback on it.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Mon, 21 Oct 2019 11:43:52 -0400

> This document erodes that.

The document goes into the rationale here under Security Considerations.
I'm unhappy about this too, but our experience is that devices without PSS
support are fairly common in client certificates. The negotiation order
means that accounting for such devices effectively means servers hold back
TLS 1.3 for *all* their clients, not just those that are affected.
Additionally, even if one could get the negotiation order correct, TLS 1.3
fixes a serious privacy leak with client certificates. Keeping those
clients on TLS 1.2 means they continue to leak their identity over the
network.

To mitigate the second-order effects, the document intentionally makes the
code points client-only (the above motivations don't apply for server
keys), as well as allocating separate code points from the existing PKCS#1
values. If a client or server wishes to not use[*] PKCS#1 signatures in TLS
1.3, it doesn't need to advertise/accept those code points. TLS libraries
probably should also disable them by default.

Given all that, I think adding code points for deployments that need them
is the right tradeoff.

[*] PKCS#1 signatures in certificates and the downgrade-sensitivity of the
TLS 1.2 signature aside.

> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic_______________________________________________
> TLS mailing list
> [email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Oct 2019 12:11:19 -0400

> Given all that, I think adding code points for deployments that need them

I think I agree with both of you here.  Eroding the modernity of TLS 1.3
makes me sad, but the draft does a good job of scoping the change to be
minimal.

The latter points you make here could be stronger in the document.  Where
you talk about the signature_algorithms in the CertificateRequest, you
could also note that if a PKCS#1 signature is received using an algorithm
not in that list, then the server MUST reject it (even though this is
probably duplicative of RFC 8446).  You could probably also say that server
implementations SHOULD disable these code points by default.

--Richard

---

From: Hubert Kario <[email-masked]>
Date: Mon, 21 Oct 2019 18:13:10 +0200

On Monday, 21 October 2019 17:43:52 CEST David Benjamin wrote:
> > > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00,
> > > 
> > > which can be found here:
> > > It will run until November 1, 2019. Please indicate whether or not you
> > 
> > would
> > 

yes, I've read it.

1. I don't expect that heterogeneous deployments of clients (where some 
   smartcards can do RSA-PSS and some can't) will be a significant portion, 
   let alone the majority, of deployments.
2. servers that do use client certificates for authentication are not 
   generally deployed for the public, on the internet. Those are closed 
   systems, so impact for publicly facing servers is minimal if they need to 
   downgrade to TLS 1.2.
3. while client certificate authentication /may/ leak client certificates in 
   plaintext in TLS 1.2, by sending them in initial handshake, is not the only 
   configuration that provides certificate based authentication. Adding client 
   certificates through renegotiation does not leak them and is fairly common 
   deployment model.
 
> probably should also disable them by default.

yes, that's a very good part of this i-d (I will suggest making the language 
around it more strict than it is now, if the i-d is adopted), but the problem 
I have is that they are allowed at all, as that means the legacy hardware is 
given another decade if not two to get replaced

Having configurations that need to downgrade to TLS 1.2 for interoperability 
is a good thing because it raises obvious red flags during audits. Algorithms 
advertised by server in CertificateVerify are not an obvious red flag.

---

From: David Benjamin <[email-masked]>
Date: Mon, 21 Oct 2019 12:19:57 -0400

On Mon, Oct 21, 2019 at 12:11 PM Richard Barnes <[email-masked]> wrote:

>> To mitigate the second-order effects, the document intentionally makes
>> the code points client-only (the above motivations don't apply for server

Sounds good to me.  I'll include something to that effect in the next
revision.

(What's the usual order of operations here? It seems weird to change a
document mid-adoption-call, and, if the document is adopted, it also seems
weird to make the first TLSWG revision different from the document from the
adoption call. That suggests tabling this for a little while.)

---

From: Sean Turner <[email-masked]>
Date: Mon, 21 Oct 2019 13:08:37 -0400

> On Oct 21, 2019, at 12:19, David Benjamin <[email-masked]> wrote:
> 
> (What's the usual order of operations here? It seems weird to change a document mid-adoption-call, and, if the document is adopted, it also seems weird to make the first TLSWG revision different from the document from the adoption call. That suggests tabling this for a little while.)

Yep, I’d hold off on making any changes until we finish the adoption call.  The individual draft is really just a starting place.  Assuming nobody starts screaming “no”, I would submit the renamed version that matches the individual one to move it to the WG and then submit a revised version including these changes.  I.e., as you said sit on it for bit.

spt