Re: MAPRG agenda for IETF-122 posted

Hi,

I do have a further follow up.

The paper by Rautenstrauch et al. tested Apache Tomcat so I took a 
deeper look at the tests where issues were reported for Tomcat. That 
resulted in one enhancement request for Tomcat [1] and three issues 
against the test suite [2], [3], [4].

I haven't looked (and am unlikely to have the time to look) at the tests 
where issues were not reported against Tomcat.

Mark

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=69610
[2] https://github.com/cispa/http-conformance/issues/1
[3] https://github.com/cispa/http-conformance/issues/2
[4] https://github.com/cispa/http-conformance/issues/3


On 12/03/2025 13:43, Mirja Kuehlewind wrote:
> Hi Mark,
> 
> also thanks for your follow-up. Forwarding to maprg and authors as well!
> 
> Mirja
> 
> 
> On 12.03.25, 09:37, "Mark Thomas" <markt@apache.org <mailto:markt@apache.org>> wrote:
> 
> 
> [You don't often get email from markt@apache.org <mailto:markt@apache.org>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/LearnAboutSenderIdentification> ]
> 
> 
> (re-sending from correct address for the list)
> 
> 
> Just to add one more point.
> 
> 
> The versions of servers tested were very old in internet terms. Most
> were released in 2020 with one released in 2019 and one in 2023. There
> has been more of a focus on the behaviour of intermediaries by both
> security researchers and vendors in the last few years. I would expect
> to see very different results if more recent versions were tested.
> 
> 
> Mark
> 
> 
> 
> 
> On 12/03/2025 00:05, Mark Nottingham wrote:
>> Thanks Mirja!
>>
>> I'm not sure I'll be able to attend MAPRG, so I'll give some feedback on the paper here.
>>
>> I'm happy to see a focus on intermediary conformance -- as the paper points out, the community's attention on this has been uneven over the years, and it's been the source of many interoperability and security issues.
>>
>> However, reading through it, I notice a number of what appear to be misunderstandings of how HTTP is specified. Starting here:
>>
>>> Out of our tests, 7 yielded unanimous results, with 5 of them consistently accepting and then retransmitting a non-conforming HTTP message. In the remaining 40 tests, we observed that the majority sometimes agreed on how to handle non-conforming data, resulting in some outliers exhibiting different behaviors.
>>
>> HTTP does not require intermediaries (or any other components) to behave uniformly in every case, because we recognise that there are implementation and deployment requirements for variance. When there are security or interoperability impacts that require behaviours to be identical, we call this out specifically, but often significant discretion is allowed.
>>
>> For example, the paper highlights:
>>
>>> According to RFC 9110, "the HEAD method is identical to GET except that the server MUST NOT send content in the response". In this instance, 11 of the tested proxies modified the non-conformant response by removing the content, Node rejects the response outright, responding with a 500 Internal Server Error.
>>
>> This variance is expected; both the proxies that remove the content to correct the upstream error and the rejection are considered conformant. Likewise,
>>
>>> RFC 9110 states that "a server MUST NOT generate a Content-Range header field in the HTTP header section of a multiple part response". While 11 proxies left the non-conforming response unmodified, Node is again the only proxy to reject the response. This behavior suggests that Node interprets its role as a proxy in the same way it would follow RFC 9110 as a server.
>>
>> However, RFC9110 Section 2.2 says:
>>
>>> The verb "generate" is used instead of "send" where a requirement applies only to implementations that create the protocol element, rather than an implementation that forwards a received element downstream.
>>
>> So, a proxy that merely forwards a non-conformant header field is itself conformant in this case; the specification does not require intermediaries to refuse to forward it.
>>
>> Also:
>>
>>> RFC 9112 also mandates that a "server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message [...] that contains more than one Host header field line" [...] Since the standard does not explicitly define proxy behavior for such requests, proxies either act as a server and reject the request, or pass it to the server for processing
>>
>> A proxy is an intermediary, which is a server, so that requirement does apply to them. See RFC 9110 Sections 3.3 and 3.7.
>>
>> Some historical context is also helpful in reading the specifications. For example:
>>
>>> RFC 9112 states that "A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the content". In cases where a server included a bare CR character in a header value, 3 proxies opted to modify the header.
>>
>> That requirement was introduced in RFC9112, so it's not surprising to see some lag in conformance. Proxies are reluctant to make potentially breaking changes because of the difficulties they introduce, and this requirement, while security-focused in nature, was more preventative than reactionary to a specific vulnerability.
>>
>> A few other observations:
>>
>> * The discussion under 'Inadequate Terminology' fails to account for the impact of the requirement in the following sentence ("Regardless, the server MUST close the connection after responding to such a request to avoid the potential attacks.").
>>
>> * The discussion under 'Lack of Completeness' is predicated upon a misunderstanding of terminology; see RFC 9110 for the appropriate definitions.
>>
>> Cheers,
>>
>>
>>> On 12 Mar 2025, at 4:23 am, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com <mailto:mirja.kuehlewind@ericsson.com>> wrote:
>>>
>>> Hi http maintainers!
>>>
>>> We have a really interesting talk about conformance to the HTTP spec of proxies in MAPRG. Please come by, listen in and ask many questions to the speaker!
>>>
>>> Mirja
>>>
>>>
>>>
>>> On 11.03.25, 18:16, "Mirja Kuehlewind" <mirja.kuehlewind@ericsson.com <mailto:mirja.kuehlewind@ericsson.com> <mailto:mirja.kuehlewind@ericsson.com <mailto:mirja.kuehlewind@ericsson.com>>> wrote:
>>>
>>>
>>> Hi all,
>>>
>>>
>>> we uploaded the agenda for our next session which you can find here (and below for your convenience):
>>>
>>>
>>> https://datatracker.ietf.org/doc/agenda-122-maprg/ <https://datatracker.ietf.org/doc/agenda-122-maprg/> <https://datatracker.ietf.org/doc/agenda-122-maprg/> <https://datatracker.ietf.org/doc/agenda-122-maprg/;>
>>>
>>>
>>> See you all soon in Bangkok, in person or online!
>>>
>>>
>>> Dave and Mirja
>>>
>>>
>>>
>>>
>>> -----------------
>>> IRTF maprg agenda for IETF-122 (Bangkok)
>>> Date: Wednesday, 19 Mar 2025, Session I 9:30-11:30
>>>
>>>
>>> Full client with Video: https://meetecho.ietf.org/conference/?group=maprg&short=maprg&item=1 <https://meetecho.ietf.org/conference/?group=maprg&short=maprg&item=1> <https://meetecho.ietf.org/conference/?group=maprg&amp;short=maprg&amp;item=1> <https://meetecho.ietf.org/conference/?group=maprg&amp;short=maprg&amp;item=1;>
>>> Room: Chitlada 2
>>> IRTF Note Well: https://irtf.org/policies/irtf-note-well-2019-11.pdf <https://irtf.org/policies/irtf-note-well-2019-11.pdf> <https://irtf.org/policies/irtf-note-well-2019-11.pdf> <https://irtf.org/policies/irtf-note-well-2019-11.pdf;>
>>>
>>>
>>> Agenda
>>> ---
>>> Overview and Status - Mirja/Dave (5 min)
>>>
>>>
>>> ImpROV: Measurement and Practical Mitigation of Collateral Damage of RPKI Route Origin Validation - Taejoong Chung (15 mins) (remote)
>>>
>>>
>>> To Adopt or Not to Adopt L4S-Compatible Congestion Control? Understanding Performance in a Partial L4S Deployment - Fatih Berkay Sarpkaya (15 mins) (remote)
>>>
>>>
>>> A Deep Dive into LEO Satellite Topology Design Parameters - Wenyi Zhang (15 mins) (remote)
>>>
>>>
>>> Characterizing Anycast Flipping: Prevalence and Impact - Xiao Zhang (15 minutes) (remote)
>>>
>>>
>>> Simulation study of Quality of Outcome scores in challenging network conditions - Bjørn Ivar Teigen (15 mins) (in-person)
>>>
>>>
>>> HTTP Conformance vs. Middleboxes: Identifying Where the Rules Actually Break Down - Mahmoud Attia (15 mins) (remote)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Mark Nottingham https://www.mnot.net/ <https://www.mnot.net/>
>>
>>
> 
> 
> 
> 
>

Received on Wednesday, 19 March 2025 04:45:54 UTC