On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <[email protected]> wrote: > David, > > Thanks for being patient with me here. Sorry it took so long > > As usual, this seems like a question of whether we're going to want a lot > of flexibility > (thus motivating orthogonal negotiation) versus whether we're going to > want little flexibility > (thus motivating suites). I think that with the historical practice, the > arguments for orthogonal > negotiation were a lot stronger, but now that we seem to be leaning > towards (a) fewer algorithms > and (b) having algorithms which are themselves suites, I do agree that the > pendulum is swinging > more towards suites. >
I would probably characterize it less as suites vs orthogonality, but as wanting to keep divisions in meaningful and universal places and not splitting up tightly-coupled decisions. The flexibility from orthogonality can be handy, but going too far---as I believe TLS 1.2 did with signature, prehash, and curve---complicates everything. Imagine if negotiating AES_128_GCM required separately negotiating block cipher AES-128, mode CTR, and MAC GHASH. On balance, I guess, I'm neutral-to-supportive of this change in general, > if others in the WG want > to make it. On the details: > > - It seems like we could let measurements tell us what code points we > need. If we never see > P256-SHA512 in the wild, then we don't need it (and can add it later if > needed). > I guess this relates to the fun issue of how TLS sigalgs interacts with X.509. If we believe they are at most a hint for X.509, then I think we can freely declare that TLS 1.3+ requires curve/hash matching for NIST curves. Unlike PKCS#1 v1.5, I doubt anyone has smartcards that can only sign P384-SHA256. If we believe that non-matching certificates are forbidden in TLS, then, yeah, it's a concern. I searched CT logs some time ago and found some cases of P384-SHA256, but that was it. https://www.ietf.org/mail-archive/web/tls/current/msg19089.html I went with the small set for the draft text since it's a little cleaner and seemed to be what most preferred, but I would be fine with allocating P384-SHA256 too. Or maybe all 6 non-truncating values. (Or even the full 9 from my original proposal but, as others pointed out to me, P256-SHA384, P256-SHA512, and P384-SHA512 are kinda silly.) - I took a quick look at the PR and I'm not sure that some of the code > points assignments are > right. I made comments. > Fixed those. Apparently I shifted most of the hashes by one. Sorry about that! > - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then we'll > probably want to define > code points for 1.5 in both in-protocol (CertificateVerify) and > certificates to distinguish these. > Oh? Why would they need to be separate? The others defined for both aren't. David > As far as process, it seemed like people were generally positive about > this in this discussion, > but I'll rely on the chairs to determine consensus. > > -Ekr > > > > > > > > > > > > > > On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin <[email protected]> > wrote: > >> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <[email protected]> wrote: >> >>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <[email protected]> >>> wrote: >>> >>>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <[email protected]> >>>> wrote: >>>> >>>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: >>>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In >>>>> TLS >>>>> > 1.2, signature algorithms are spread across the handshake. >>>>> [...] >>>>> > I propose we fold the negotiable parameters under one name. >>>>> [...] >>>>> > 2. Remove HashAlgorithm, SignatureAlgorithm, >>>>> SignatureAndHashAlgorithm as >>>>> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate >>>>> that >>>>> > instead. >>>>> >>>>> I previously proposed this here: >>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >>>>> >>>>> ekr was against it, though it hasn't been discussed that throughly. >>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html >>>> >>>> >>>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it and >>>> forgot. >>>> >>>> ekr, are you still against this sort of thing? I think the new CFRG >>>> signature algorithms tying decisions together is a good argument for why >>>> we'd want this. If we believe this trend is to continue (and I hope it >>>> does. Ed25519 is a nice and simple interface), trying to decompose it all >>>> seems poor. >>>> >>> >>> I'm not sure. I agree that the CFRG thing seems to be a new development. >>> I'll >>> try to confirm my previous opinion or develop a new one over the weekend >>> :) >>> >> >> ekr, did you have confirmed or new thoughts on this change? >> >> From elsewhere in the thread, I put together a draft PR if you wanted >> something to look at in that form. >> https://github.com/tlswg/tls13-spec/pull/404 >> It incorporated some of the suggestions in the thread (not mentioning the >> really legacy values, pairing NIST curves with hashes, etc.), but that's >> not the important part. The meat of the proposal is unifying signature >> algorithms under one number and a shared interface, which I think is a >> valuable simplification. >> >> David >> > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
