On Tue, Nov 22, 2016 at 11:06 AM, Olivier Levillain < olivier.levill...@ssi.gouv.fr> wrote:
> Hi list, > > I am sorry for the very late answer concerning draft 18, but we > (ANSSI) have several remarks after proof-reading the current > specification. > > We are sorry for the multiple long messages. > > If the WG is interested by some of our concerns/proposals, we would be > glad to propose some PRs. > > > = PSK and PSK Binder = > > P.35 (4.2), it is specified that the pre_shared_key extension must be > the last extension in the ClientHello, because of the way the PSK > Binder is computed. This seems very hackish and will most certainly > lead to implementation errors. However, I understand that it was not > easy to propose a cleaner mechanism while keeping a common flow > between *DHE and PSK modes. > I agree that this is piece is a little structurally unfortunate. It was a compromise between a number of different imperatives and this ended up being the best. Yet, we would have preferred that PSK would not be MTI as stated in > the end of the document (P.81, section 8.2). In previous versions PSK > and resumption was not MTI, so it might be logical to keep it this > way. Alternatively, we might propose a profile defining a simpler TLS > subset. > I agree with this comment. I don't think the WG ever had consensus to require PSK, it was just a side effect of trying to specify a list of MTI extensions. I have filed https://github.com/tlswg/tls13-spec/issues/771 to keep track of this. Regarding the definition of the PSK Binder (P. 45 and 46, section > 4.2.6.1), we found it very hard to read, since the binding value is > said to be computed as the Finished message, but differently. In > particular, it would be useful to give the relevant information (I > believe the Handshake Context is called transcript in this section, > and it would be important to explicit the Hash to use), instead of > implying it. It would not take much space in the document, but it > would ensure implementers know how to compute the binder. > OK. I will see if I can figure out how to rewrite this to make it clearer. -Ekr > > > Olivier Levillain > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
