[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Accepting that other SNI name types will never work.
From:       Richard Moore <rich () kde ! org>
Date:       2016-03-03 22:52:36
Message-ID: CAMp7mVtwrF9CL-MqyF0UZJemBOMyFieAy++-_539fE5eAB_KMQ () mail ! gmail ! com
[Download RAW message or body]

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.thomson@gmail.com> wrote:

> On 4 March 2016 at 05:49, Adam Langley <agl@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
>

[Attachment #3 (text/html)]

<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">If \
you&#39;re fixing that then maybe standardising the errors makes sense too. My \
fingerprinter sees the following:</div><div class="gmail_default" \
style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" \
style="font-family:verdana,sans-serif">For an empty name:</div><div \
class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div \
class="gmail_default" style=""><div class="gmail_default" \
style="font-family:verdana,sans-serif">SNIEmptyName: \
*(301)alert:DecodeError:fatal|</div><div class="gmail_default" \
style="font-family:verdana,sans-serif">SNIEmptyName: \
*(301)alert:HandshakeFailure:fatal|</div><div class="gmail_default" \
style="font-family:verdana,sans-serif">SNIEmptyName: \
*(301)alert:IllegalParameter:fatal|</div><div class="gmail_default" \
style="font-family:verdana,sans-serif">SNIEmptyName: \
*(303)alert:UnexpectedMesage:fatal|<br></div><div class="gmail_default" \
style="font-family:verdana,sans-serif">SNIEmptyName: error:Unexpected EOF receiving \
record header - server closed connection|</div><div \
style="font-family:verdana,sans-serif"><br></div><div \
style="font-family:verdana,sans-serif">For a long name (x repeated 500 \
times):</div><div style="font-family:verdana,sans-serif"><br></div><div style=""><div \
style=""><font face="verdana, sans-serif">SNILongName: \
*(301)alert:HandshakeFailure:fatal|</font></div><div style=""><font face="verdana, \
sans-serif">SNILongName: *(301)alert:IllegalParameter:fatal|</font></div><div \
style=""><font face="verdana, sans-serif">SNILongName: \
*(301)alert:UnrecognizedName:fatal|</font></div><div style=""><span \
style="font-family:verdana,sans-serif">SNILongName: \
*(303)alert:UnexpectedMesage:fatal|</span><br></div><div style=""><font \
face="verdana, sans-serif">SNILongName: error:Unexpected EOF receiving record header \
- server closed connection|</font></div></div><div \
style="font-family:verdana,sans-serif"><br></div><div \
style="font-family:verdana,sans-serif">Rich.</div><div \
style="font-family:verdana,sans-serif"><br></div></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On 3 March 2016 at 22:44, Martin \
Thomson <span dir="ltr">&lt;<a href="mailto:martin.thomson@gmail.com" \
target="_blank">martin.thomson@gmail.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On 4 March 2016 at 05:49, Adam Langley &lt;<a \
href="mailto:agl@imperialviolet.org">agl@imperialviolet.org</a>&gt; wrote:<br> &gt; \
(I think the lesson here is that protocols should have a single joint,<br> &gt; and \
that it should be kept well oiled. For TLS, that means that<br> &gt; extensions \
should have minimal extensionality in themselves and that<br> &gt; we should \
generally rely on the main extensions mechanism for these<br> &gt; sorts of \
things.)<br> <br>
</span>Big +1<br>
<br>
Note that the NSS bug also entailed non-zero SNI name types<br>
overwriting the actual SNI.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br> \
</div></div></blockquote></div><br></div>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic