Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)

Hi Roman,

Thanks for the review. Please see inline.

Best,
Kai

> -----Original Messages-----
> From: "Roman Danyliw via Datatracker" <noreply@ietf.org>
> Send time:Tuesday, 10/24/2023 10:40:46
> To: "The IESG" <iesg@ietf.org>
> Cc: alto-chairs@ietf.org, draft-ietf-alto-new-transport@ietf.org, alto@ietf.org
> Subject: [alto] Roman Danyliw's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-alto-new-transport-17: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> ** Section 6.2.  Construction of the “tips-view-uri”.
> 
> -- Under what circumstances would it be appropriate to use http (instead of
> https) for the tips-view-uri for this new protocol mechanism?  Why is http
> needed?  Could https be the only option?  I appreciate that there is history of
> an http URL from RFC7285 published in 2014, but has field experience continue
> to dictate a need for this insecure approach for an entirely new service?  If
> it is needed would there be a away to express a preference for secure transport?
> 

[KAI] One reason I can think of to keep http is to allow caching of incremental
updates (whose uri is based on the tips-view-uir) for a given resource whose
content is intended to be publicly accessible, which could happen if the server is
hosted by the ISP and a cost map is intended to be accessible by all its users. How
about we add the following sentence in sec 6.2:

  An ALTO server SHOULD always use "https" unless the ALTO resource is intended to
  be publicly accessible and does not raise any security concerns.

> -- Is there any underlying assumption in how “tips-view-path” is constructed? I
> asked because Section 9.3 says “An outside party that can read the TIPS
> response or that can observe TIPS requests can obtain the TIPS view URI and use
> that to send fraudulent ‘DELETE’ requests thus disabling the service for the
> valid ALTO client.  This can be avoided by encrypting the requests and
> responses (Section 15 of [RFC7285]).”  Observing the tips-view-uri is one way
> to spoof the URI, but what if it could be guessed?  Is there an assumption that
> a unguessable random string is part of the path?  As far as I can find, no text
> explicitly says that, although the examples imply it.  If the string is
> guessable being encrypted doesn’t help but using some kind of authentication
> would.
> 
>

[KAI] In -17, the fraudulent 'DELETE' issue no long exists as we now require
the server to close of TIPS views, as suggested by the HTTPDIR reviewer and the
AD. I think that would address this issue.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Donald Eastlake for the SECDIR review.
> 
> ** Section 6.3.  The example in Figure 10 describes Basic Auth.  Section 8.3.5
> of RFC7295 notes that Digest Auth is MTI.  Recommend using that instead.
> 
> ** Section 9.
>    The security considerations (Section 15 of [RFC7285]) of the base
>    protocol fully apply to this extension.  For example, the same
>    authenticity and integrity considerations (Section 15.1 of [RFC7285])
>    still fully apply;
> 
> Since ALTO TIPS is a new protocol mechanism is it possible to improve on the
> TLS guidance in Section 8.3.5 of RFC7295 (from circa 2014)?  Specifically, can
> RFC9325 be mandated?
> 
> 
> 
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto