[AFS3-std] Re: afs3-rxgk-updates for 03
Thomas Keiser
tkeiser@gmail.com
Fri, 2 Nov 2012 19:03:34 -0400
--bcaec54c5270253ef704cd8b2505
Content-Type: text/plain; charset=ISO-8859-1
On Nov 2, 2012 6:16 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
>
> On Thu, 1 Nov 2012, Simon Wilkinson wrote:
>
>>
>> On 1 Nov 2012, at 04:08, Benjamin Kaduk wrote:
>>
>>> On Mon, 29 Oct 2012, Andrew Deason wrote:
>>>>
>>>>
>>>> On Thu, 25 Oct 2012 09:58:03 -0400 (EDT)
>>>> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>>>>
>>>>> commit 8e0451de7dbdc3abb335bffc79e30d7c51d6c78b
>>>>> Author: Ben Kaduk <kaduk@mit.edu>
>>>>> Date: Wed Oct 24 17:17:42 2012 -0400
>>>>>
>>>>> The value zero is special for (byte)lifetime
>>>>
>>>>
>>>
>>> That makes sense. I am not particularly inclined to keep rewording
this part of the document, though, so you'll forgive me if I don't try to
put this view in the document.
>>
>>
>> I think I'm happy with Ben's reworked wording, too.
>
>
> It's really Tom Keiser's wording (or nearly so), but glad to see
agreement.
>
>
>>
>>>>> commit 74bc8de3886728c5ace1a28a4c0eacf0c2d68275
>>>>> Author: Ben Kaduk <kaduk@mit.edu>
>>>>> Date: Wed Oct 24 22:22:10 2012 -0400
>>>>>
>>>>> Use RXGK_Levels more appropriately
>>>>
>>>> [...]
>>>>>
>>>>> @@ -403,7 +403,9 @@ enum RXGK_Level {
>>>>> </t>
>>>>> <t>To reduce the potential for denial of service attacks,
servers
>>>>> SHOULD only offer the CombineTokens operation to clients
connecting
>>>>> - over an rxgk secured connection.</t>
>>>>> + over an rxgk secured connection. The RXGK_Level of the rxgk
>>>>> + connection does not affect the resiliance against denial of
>>>>> + service attacks.</t>
>>
>>
>> Actually, this change is incorrect. The RXGK_Level does affect our
resilience against denial of service attacks. If the connection level is
"clear", then an attacker can make the server perform an arbitrary number
of CombineTokens operations by hijacking an existing connection.
>>
>> I'd proposed adding something like
>> "over an rxgk secured connection, with an RXGK_Level of auth or better."
>
>
> Good point. I've got in my local copy:
>
> SHOULD only offer the CombineTokens operation to clients
connecting
> - over an rxgk secured connection.</t>
> + over an rxgk secured connection, with an RXGK_Level of
RXGK_LEVEL_AUTH
> + or higher.</t>
>
> I'm wavering on higher vs. better (or something else).
>
Higher would imply a hierarchy of levels. I cannot recall offhand: did we
elide the (experimental) 'bind' level for the moment? (For those
unfamiliar, my recollection from Edinburgh is that 'bind' was envisioned to
permit future boot-strapping of, e.g., rxgk-protected rxtcp on top of TLS.)
If we've removed 'bind' from the working document, then your implication
may be defensible. Failing that, I think we would need to reach a decision
on whether the 'bind' level warrants the additional complexity of
prescribing a means to evaluate relative level strength. If we decide to
deal with the complexity attendant with 'bind', then perhaps 'stronger'
would be the best term?
-Thomas
--bcaec54c5270253ef704cd8b2505
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p>On Nov 2, 2012 6:16 PM, "Benjamin Kaduk" <<a href=3D"mailto=
:kaduk@mit.edu" target=3D"_blank">kaduk@mit.edu</a>> wrote:<br>
><br>
> On Thu, 1 Nov 2012, Simon Wilkinson wrote:<br>
><br>
>><br>
>> On 1 Nov 2012, at 04:08, Benjamin Kaduk wrote:<br>
>><br>
>>> On Mon, 29 Oct 2012, Andrew Deason wrote:<br>
>>>><br>
>>>><br>
>>>> On Thu, 25 Oct 2012 09:58:03 -0400 (EDT)<br>
>>>> Benjamin Kaduk <<a href=3D"mailto:kaduk@MIT.EDU" target=
=3D"_blank">kaduk@MIT.EDU</a>> wrote:<br>
>>>><br>
>>>>> commit 8e0451de7dbdc3abb335bffc79e30d7c51d6c78b<br>
>>>>> Author: Ben Kaduk <<a href=3D"mailto:kaduk@mit.edu"=
target=3D"_blank">kaduk@mit.edu</a>><br>
>>>>> Date: =A0 Wed Oct 24 17:17:42 2012 -0400<br>
>>>>><br>
>>>>> =A0 =A0The value zero is special for (byte)lifetime<br=
>
>>>><br>
>>>><br>
>>><br>
>>> That makes sense. =A0I am not particularly inclined to keep re=
wording this part of the document, though, so you'll forgive me if I do=
n't try to put this view in the document.<br>
>><br>
>><br>
>> I think I'm happy with Ben's reworked wording, too.<br>
><br>
><br>
> It's really Tom Keiser's wording (or nearly so), but glad to s=
ee agreement.<br>
><br>
><br>
>><br>
>>>>> commit 74bc8de3886728c5ace1a28a4c0eacf0c2d68275<br>
>>>>> Author: Ben Kaduk <<a href=3D"mailto:kaduk@mit.edu"=
target=3D"_blank">kaduk@mit.edu</a>><br>
>>>>> Date: =A0 Wed Oct 24 22:22:10 2012 -0400<br>
>>>>><br>
>>>>> =A0 =A0Use RXGK_Levels more appropriately<br>
>>>><br>
>>>> [...]<br>
>>>>><br>
>>>>> @@ -403,7 +403,9 @@ enum RXGK_Level {<br>
>>>>> =A0 =A0 =A0 </t><br>
>>>>> =A0 =A0 =A0 <t>To reduce the potential for denia=
l of service attacks, servers<br>
>>>>> =A0 =A0 =A0 =A0 SHOULD only offer the CombineTokens op=
eration to clients connecting<br>
>>>>> - =A0 =A0 =A0 =A0over an rxgk secured connection.</=
t><br>
>>>>> + =A0 =A0 =A0 =A0over an rxgk secured connection. The =
RXGK_Level of the rxgk<br>
>>>>> + =A0 =A0 =A0 =A0connection does not affect the resili=
ance against denial of<br>
>>>>> + =A0 =A0 =A0 =A0service attacks.</t><br>
>><br>
>><br>
>> Actually, this change is incorrect. The RXGK_Level does affect our=
resilience against denial of service attacks. If the connection level is &=
quot;clear", then an attacker can make the server perform an arbitrary=
number of CombineTokens operations by hijacking an existing connection.<br=
>
>><br>
>> I'd proposed adding something like<br>
>> "over an rxgk secured connection, with an RXGK_Level of auth =
or better."<br>
><br>
><br>
> Good point. =A0I've got in my local copy:<br>
><br>
> =A0 =A0 =A0 =A0 =A0SHOULD only offer the CombineTokens operation to cl=
ients connecting<br>
> - =A0 =A0 =A0 =A0over an rxgk secured connection.</t><br>
> + =A0 =A0 =A0 =A0over an rxgk secured connection, with an RXGK_Level o=
f RXGK_LEVEL_AUTH<br>
> + =A0 =A0 =A0 =A0or higher.</t><br>
><br>
> I'm wavering on higher vs. better (or something else).<br>
></p>
<p>Higher would imply a hierarchy of levels.=A0 I cannot recall offhand: di=
d we elide the (experimental) 'bind' level for the moment? =A0(For =
those unfamiliar, my recollection from Edinburgh is that 'bind' was=
envisioned to permit future boot-strapping of, e.g., rxgk-protected rxtcp =
on top of TLS.) =A0If we've removed 'bind' from the working doc=
ument, then your implication may be defensible.=A0 Failing that, I think we=
would need to reach a decision on whether the 'bind' level warrant=
s the additional complexity of prescribing a means to evaluate relative lev=
el strength. =A0If we decide to deal with the complexity attendant with =
9;bind', then perhaps 'stronger' would be the best term?</p>
<p>-Thomas</p>
--bcaec54c5270253ef704cd8b2505--