On Mon, Sep 05, 2016 at 10:17:58AM +0200, Nikos Mavrogiannopoulos wrote: > On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla wrote: > > > > > I also am not following why we need to do this now. The reason we > > > defined SHA-2 in > > > > a new RFC was because (a) SHA-1 was looking weak and (b) we had > > > to make significant > > > > changes to TLS to allow the use of SHA-2. This does not seem to > > > be that case. > > > > > > I don't think we strictly _need_ to do this now, however I think > > > it's a good idea given that we'll need to do it eventually > > > > I'm not sure that that's true. > > It is unclear to me what is the intention. Due to the semantics of the > signatureAlgorithms extension in TLS 1.3, if the TLS 1.3 draft doesn't > define SHA3, it effectively _bans_ the usage of SHA3 in all certificate > chains intended to be used by TLS 1.3. If that's the intention then > yes, SHA3 should not be included.
Huh? Can you explain your logic on how you arrived at that conclusion? AFAICT, there is nothing preventing assigning new SignatureAlgorithm IDs from 0705...FDFF range, with possible legacy type specified (for TLS 1.2 compatiblity). So SHA-3 SignatureSchemes can be added to TLS 1.3 _and_ 1.2 post-hoc. If the above is wrong, there is IMO a serious issue with the draft. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
