It looks like we have rough consensus to accept this PR. We should make sure we note the limitations that Karthink brought up for PSK and RSA, https://mailarchive.ietf.org/arch/msg/tls/sZX9ursx4ePK2Zr-yflO2nUtiQY. Procedurally, we should document the requirements for TLS 1.2 in a separate draft to update TLS 1.2 in parallel. This may be necessary to get us out of the situation where we have to update and obsolete a specification at the same time.
Thanks, J&S On Mon, Nov 9, 2015 at 4:44 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema <huit...@microsoft.com> > wrote: > >> On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote: >> >> > On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema < >> huit...@microsoft.com> wrote: >> > >> >... >> >> Editorial: your proposed text says "...MUST set the first six bytes >> of its Random value >> >> to the the bytes 44 4F 57 4E 47 52 44 01." I assume you mean the first >> 8 bytes, and that >> >> you do not really want to have "the" twice. >> > >> > Fixed. >> >> Thanks >> >> >> Could you also add a reference to the document that specifies using 44 >> 4F 57 4E 47 52 >> >> 44 00 by "TLS 1.2 servers which are negotiating TLS 1.1 or below" ? >> > >> > We don't have one. Wasn't totally sure how to handle that. >> >> I suspected that. Spent sometimes looking for text in published RFC, >> could not find it. I suspect that many readers will fall in the same trap >> and lose some time. Could you add text explaining that this is an >> undocumented feature of some implementations, and that we are recommending >> its use? Or something to that effect... >> > > Worse, we just invented it. What about if I say "TLS 1.2 servers SHOULD..." > > -Ekr > > >> >> -- Christian Huitema >> >> >> >> > > _______________________________________________ > 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
