Re: [alto] SECDIR Last Call review of draft-ietf-alto-new-transport-15

HI Kai,

Thanks for your response which sounds good. I'll consider my issues
resolved.

Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

On Wed, Nov 1, 2023 at 9:54 AM Kai GAO <godrickk@gmail.com> wrote:

>
> Hi Donald,
>
> Sorry for the late reply as the mail is not properly forwarded to my
> primary email. Please see our responses inline and feel free to let us know
> if there are further comments.
>
> Best,
> Kai
>
> On Thu, Oct 12, 2023 at 10:38 AM Donald Eastlake <d3e3e3@gmail.com> wrote:
>
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  Document editors and WG chairs should treat these comments just
>> like any other last call comments. Sorry this review is a bit late.
>>
>> The summary of this review is Ready with Issues.
>>
>> (I did an early review of the -07 version of this draft at which time
>> I found only nits all of which were fixed.)
>>
>> *Security*
>>
>> While I'm not all that into ALTO, it seems to me that this draft is all
>> about messages and message exchanges between ALTO entities where the
>> security (authentication, encryption, ...) has been specified in previous
>> standards track documents such as RFC 7285; however, in Section 9.3,
>> it says the spoofed URIs can be avoided by "encrypting the requests"
>> where I think it should say "authenticating" the requests. There are a
>> few additional security considerations which seem to be covered by the
>> Security Considerations section of this draft.
>>
>
> [KAI] You are right. In the meantime, after discussing with the AD and the
> HTTPDIR reviewer, we eventually dropped the design of explicitly deleting a
> TIPS view. So, it seems that spoofed URI is no longer a concern.
>
>
>>
>> *Other possible issues*
>>
>> - In the update from -14 to -15, huge numbers of all caps RFC 2119 key
>> words have been lowercased. In many instances, this does not look
>> right to me. (There are many other cases but one example is that in
>> Section 8.4, all words in all upper case were lowercased.)
>>
>>
> [KAI] We went over the keywords and hopefully they are in the right case
> now. Some of the operational consideration sections are repetitive to
> sections in RFC 8895 and are removed in -17, including Sec 8.4 in -15.
>
>
>> - Although there is correct text elsewhere, the last paragraph of
>> Section 6.4, page 24, seems to say you delete a TIPS view if
>> heartbeats time out on one connection for that view. But shouldn't it
>> be all connections going away as there might be multiple?
>>
>>
> [KAI] Yes indeed. However, the heartbeat mechanism is no longer needed as
> the server now has full control of TIPS views' lifecycles. But similarly,
> the server is
>
>
>> - I am a bit surprised there is nothing about jittering the heartbeat
>> messages to be sure they can't get synchronized between muldtiple
>> clients. Something like the time between them should be varied by an
>> amount randomly selected in the range +0% to -40%.
>>
>>
> [KAI] Previously the idea was to use multiple heartbeat messages to detect
> the liveness of clients. Even for 2 messages, the variation is 100%, which
> should be good enough. Of course, as we no longer have the heartbeat
> mechanism now, this probably will not be an issue anymore.
>
>
>> - Section 2.1, Page 6: I think there is something not quite right with
>> the sentence "Prefetching updates can reduce the time to send the
>> request, making it possible to achieve sub-RTT transmission of ALTO
>> incremental updates." It seems muddled. Transmission speed /
>> transmission time isn't affected by prefetching although, of course,
>> the time to satisfy a request can be vastly reduced. Maybe
>> "Prefetching updates can reduce the time to satisfy a request, makit
>> it possible to achieve rapid, sub-RTT ALTO incremental updates."
>>
>>
> [KAI] Thanks for the proposal. Will use the suggested text.
>
>
>>
>> *Nits*
>>
>> - Section 3.1, page 10, "(tag" -> "(a tag"
>>
>
> [KAI]  Nice catch. Updated as suggested.
>
>
>>
>> - Section 6.2, page 22, "time unit is second" -> "time unit is a second"
>>
>
> [KAI] The sentence is no longer there as heartbeat is removed in the new
> version.
>
>
>>
>> Hope these comments are helpful.
>>
>> Thanks,
>> Donald
>> ===============================
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  2386 Panoramic Circle, Apopka, FL 32703 USA
>>  d3e3e3@gmail.com
>>
>> _______________________________________________
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
>