Subject: Re: [tcpm] Updated SHA-2 AO draft

From: Brandon Williams <[email-masked]>
Date: Sun, 09 Nov 2014 19:36:31 -0500

Hi Sujeet,

I'm still concerned about whether there's enough space in the SYN header 
for this option. My concern is based mostly on a what I think is a flaw 
in the analysis from RFC5925 section 7.2, which leaves out the 4-byte 
MSS option. As the analysis from RFC6824 indicates, SYN packets 
typically include the MSS option, leaving only 21 bytes available in an 
option packed SYN and 16 in a worst-case unpacked SYN. TCP-AO with SHA1 
works in either case, but SHA2 only works (just barely) in an option 
packed stack.

Section 4 of your draft should probably be updated to account for the 
commonality of the MSS option and the related requirement either to drop 
one of the common SYN options or pack the option space.

--Brandon

On 10/28/2014 02:12 AM, Sujeet Nayak A (sua) wrote:
> Hi,
> Thanks everyone for your valuable review comments so far. Brian and
> myself have updated the draft to produce the next version.
> https://tools.ietf.org/html/draft-nayak-tcp-sha2-01
>
> Some of the high level changes made are:
>
>   * Because of TCP option space issue, SHA512 has been moved out of the
>     draft (a note added in the "Security Consideration" for future
>     support, when needed).
>   * Moved the motivation contents into the introduction section.
>   * Taken care of some of the RFC language related comments.
>
> Pl. review and let me know your feedback. On the other hand, if there is
> a consensus that, the contents need to update RFC5926, and if that RFC
> allows such an update, then we are happy to work with Greg on it.
>
> Regards,
>
> Sujeet

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Nov 2014 14:34:15 -0800

On 11/9/2014 4:36 PM, Brandon Williams wrote:
> MSS option.

Yes, that was an oversight. However, there were 9 SYN option bytes
available with the lengths of the hashes defined at the time, so that's
not a problem.

> As the analysis from RFC6824 indicates, SYN packets
> option packed SYN and 16 in a worst-case unpacked SYN.

Options are not required to be (4-byte) word-aligned; they must *end* on
such a boundary only. If they don't otherwise fit, they should be placed
to fit.

> TCP-AO with SHA1

"barely" means it works. Option word alignment is an optimization that
clearly is inappropriate if the options won't otherwise fit.

> one of the common SYN options or pack the option space.

Pack the options space or (IMO) use a shorter hash. It's not viable for
any one option to declare whether to drop other options.

Joe

---

From: "Sujeet Nayak A (sua)" <[email-masked]>
Date: Tue, 11 Nov 2014 17:06:34 +0000

Hi Brandon, Joe,
Thanks a lot for your quick and useful comments.

I will expand section 4 further, with options packing recommendation. If
we cut down on the hash size, that could compromise on the security of
algorithm implementation by increasing the probability of successful
birthday attacks (which could defeat the very purpose of the ask for SHA2).

Regards,

Sujeet

---

From: Brandon Williams <[email-masked]>
Date: Tue, 11 Nov 2014 14:20:43 -0500

> such a boundary only. If they don't otherwise fit, they should be placed

Agreed. But considering how common word alignment was (I don't know 
whether it still _is_ common), it might still be worth pointing out the 
potential compatibility problem.

> clearly is inappropriate if the options won't otherwise fit.

"barely" also means that it consumes all of the remaining space. I think 
that's an important consideration.

> any one option to declare whether to drop other options.

Agreed. Option packing or a shorter hash seem the reasonable choices.

--Brandon