MIME-Version: 1.0
In-Reply-To: <5267E276.9050107@gnutls.org>
References: <526797EE.2000206@gnutls.org>
 <CAL9PXLyguGgFtb9NqbkvrL82fV-Aj=HFJiex-Hu32xEec=9SLQ@mail.gmail.com>
 <5267E276.9050107@gnutls.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 23 Oct 2013 08:42:30 -0700
Message-ID: <CABcZeBPGxc8qGOiB2sqk9vnh98=SiH6qvkriOLqdfe-xcxmDMA@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: multipart/alternative; boundary=089e0141a0aecff00404e96a5f3d
Cc: "tls@ietf.org" <tls@ietf.org>,
 =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= <joachim@secworks.se>
Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and
 draft-agl-tls-chacha20poly1305-02
Precedence: list

--089e0141a0aecff00404e96a5f3d
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 23, 2013 at 7:51 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org>wrote:

> as a general comment I think DTLS' resilience on forged packets
>  isn't that good. It makes it a perfect target to lay an attack. I think
> it would be much better to have a limit by default on the allowed
> packets with wrong MAC.


S 4.2.7 provides some guidance in this area, but it's pretty vague:

   Note that Alert messages are not retransmitted at all, even when they
   occur in the context of a handshake.  However, a DTLS implementation
   which would ordinarily issue an alert SHOULD generate a new alert
   message if the offending record is received again (e.g., as a
   retransmitted handshake message).  Implementations SHOULD detect when
   a peer is persistently sending bad messages and terminate the local
   connection state after such misbehavior is detected.

It certainly seems like it would be a good thing to document some
better guidance about how many bad MACs you should tolerate.

Do you have any thoughts about what makes sense?

-Ekr

--089e0141a0aecff00404e96a5f3d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Oct 23, 2013 at 7:51 AM, Nikos Mavrogiannopoulos <span dir=
=3D"ltr">&lt;<a href=3D"mailto:nmav@gnutls.org" target=3D"_blank">nmav@gnut=
ls.org</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(34,34,34)">as a=
 general comment I think DTLS&#39; resilience on forged packets</span><br>

</div>
isn&#39;t that good. It makes it a perfect target to lay an attack. I think=
<br>
it would be much better to have a limit by default on the allowed<br>
packets with wrong MAC.</blockquote><div><br></div><div>S 4.2.7 provides so=
me guidance in this area, but it&#39;s pretty vague:</div><div><br></div><d=
iv>=A0 =A0Note that Alert messages are not retransmitted at all, even when =
they</div>

<div>=A0 =A0occur in the context of a handshake. =A0However, a DTLS impleme=
ntation</div><div>=A0 =A0which would ordinarily issue an alert SHOULD gener=
ate a new alert</div><div>=A0 =A0message if the offending record is receive=
d again (e.g., as a</div>

<div>=A0 =A0retransmitted handshake message). =A0Implementations SHOULD det=
ect when</div><div>=A0 =A0a peer is persistently sending bad messages and t=
erminate the local</div><div>=A0 =A0connection state after such misbehavior=
 is detected.</div>

<div><br></div><div>It certainly seems like it would be a good thing to doc=
ument some</div><div>better guidance about how many bad MACs you should tol=
erate.</div><div><br></div><div>Do you have any thoughts about what makes s=
ense?</div>

<div><br></div><div>-Ekr</div><div><br></div><div>=A0</div></div></div></di=
v>

--089e0141a0aecff00404e96a5f3d--