On Wed, Mar 16, 2016 at 5:47 PM, David Benjamin <david...@chromium.org> wrote:
> On Tue, Mar 15, 2016 at 7:06 PM Eric Rescorla <e...@rtfm.com> wrote: > >> On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin <david...@chromium.org> >> wrote: >> >>> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <e...@rtfm.com> wrote: >>> >>>> - 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. >>> >> >> The idea here would be that we want to be able to deprecate the use of >> v1.5 in >> CertificateVerify before its us in certs (which we can't deprecate for >> quite some >> time). >> > > Gotcha. This is true independent of this change, right? Without it, we'd > need to define two v1.5 SignatureAlgorithm values instead. > Correct. I'm not sure this is worth the nuisance. If we expect to deprecate it soon, > we should just keep it out of 1.3. If not, we only need to advertise > removal if there are v1.5-preferring servers that can sign anything else, > in which case why aren't they signing that to begin with? Otherwise > rejecting v1.5 is going to break those servers regardless. (Then again, > with SHA-1 vs. SHA-256 in ServerKeyExchange, I myself found > SHA-1-preferring SHA-256-capable servers, which is baffling. Would be good > if 1.3 implementers didn't repeat that one...) Should we split all other > code points in anticipation of deprecating them? Why not a separate > extension altogether then? > I don't think we will be deprecating 1.5 for certs soon. I do see your point about 1.5 for CertificateVerify > Anyway, I think this is orthogonal. We can certainly allocate more v1.5 > code points in either universe if people want that. *shrug* > > David > > >> -Ekr >> >> >>> >>> 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 <david...@chromium.org> >>>> wrote: >>>> >>>>> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <e...@rtfm.com> wrote: >>>>> >>>>>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin < >>>>>> david...@chromium.org> wrote: >>>>>> >>>>>>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <davemgarr...@gmail.com> >>>>>>> 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
