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. In that case implementations of TLS 1.3 will have to wait for a SHA3 RFC to be published in order to enable the algorithm. That would introduce a delay, and in certain occasions (e.g., firmware) we will have TLS 1.3 implementations which may never support SHA3. IMO, unless there are doubts about SHA3's adoption as a certificate algorithm, it should be part of the TLS 1.3 spec. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
