On Mon, Oct 21, 2019 at 12:11 PM Richard Barnes <r...@ipv.sx> wrote: > On Mon, Oct 21, 2019 at 11:44 AM David Benjamin <david...@chromium.org> > wrote: > >> On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario <hka...@redhat.com> wrote: >> >>> On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: >>> > 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. >>> >>> 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. >>> >> >> 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. >> > > 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. >
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.)
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
