Do we want to stick some simple new constraints on SNI in the TLS 1.3 draft spec? e.g. SHOULD have exactly one host_name which SHOULD be less than N bytes (significantly less than the current theoretical 64kB ceiling). Just adding a quick blurb for this in there somewhere seems like the simplest solution to me.
Dave On Thursday, March 03, 2016 06:16:25 pm Martin Thomson wrote: > If we actually have a volunteer for sni-bis, then that would be OK with me. > > However, I don't regard the errors as important. Any hope that they > might be used in some automated fashion died a long time ago. Mainly > due to this complete lack of consistency. I assume that the last > error indicates that you didn't get an alert, which I find is > alarmingly common in TLS. > > On 4 March 2016 at 09:52, Richard Moore <r...@kde.org> wrote: > > If you're fixing that then maybe standardising the errors makes sense too. > > My fingerprinter sees the following: > > > > For an empty name: > > > > SNIEmptyName: *(301)alert:DecodeError:fatal| > > SNIEmptyName: *(301)alert:HandshakeFailure:fatal| > > SNIEmptyName: *(301)alert:IllegalParameter:fatal| > > SNIEmptyName: *(303)alert:UnexpectedMesage:fatal| > > SNIEmptyName: error:Unexpected EOF receiving record header - server closed > > connection| > > > > For a long name (x repeated 500 times): > > > > SNILongName: *(301)alert:HandshakeFailure:fatal| > > SNILongName: *(301)alert:IllegalParameter:fatal| > > SNILongName: *(301)alert:UnrecognizedName:fatal| > > SNILongName: *(303)alert:UnexpectedMesage:fatal| > > SNILongName: error:Unexpected EOF receiving record header - server closed > > connection| > > > > Rich. > > > > > > On 3 March 2016 at 22:44, Martin Thomson <martin.thom...@gmail.com> wrote: > >> > >> On 4 March 2016 at 05:49, Adam Langley <a...@imperialviolet.org> wrote: > >> > (I think the lesson here is that protocols should have a single joint, > >> > and that it should be kept well oiled. For TLS, that means that > >> > extensions should have minimal extensionality in themselves and that > >> > we should generally rely on the main extensions mechanism for these > >> > sorts of things.) > >> > >> Big +1 > >> > >> Note that the NSS bug also entailed non-zero SNI name types > >> overwriting the actual SNI. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
