Re: draft-tiesel-quic-unreliable-streams-01 - comments

["Philipp S. Tiesel" <[e-mail]>]

Hi,

the whole point came up in the security considerations of the draft:

	If one uses unreliable streams as-a-message to cut down
	delay, it is also necessary to send them out right away
	and don’t wait unit a MTU-sized packet is full.

	Despite encryption, this allows an attacker to learn about message
 	sizes and, assuming the protocol within the QUIC connection is known,
	might allow guessing what messages were used.
 
	One _example_ for such an attack was an hypothetical streaming protocol
	which an attacker can drop delivery reports for and thus could influence
	rate adaption.

I came to the conclusion this was not the best example for the message guessing attack.


> On 7. Nov 2017, at 15:47, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi
>  
> OK, then I understand, maybe.. Still don’t get it, sorry. If you are about to selectively discard ACK packets, then the ACK spacing will become larger and the ACK clocking will be degraded. The end effect is that also the media (or whatever) that constitute the large packets will also get a degraded performance ? 
>  
> I assume that we will still be running one congestion control for the connection ?
>  
> /Ingemar
>  
> From: Roni Even [mailto:[e-mail]] 
> Sent: den 7 november 2017 12:50
> To: Ingemar Johansson S <[e-mail]>; Philipp S. Tiesel <[e-mail]>
> Cc: QUIC WG <[e-mail]>
> Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments
>  
> Hi Ingemar,
> It is not CCM the attacker just does heuristics to understand that this is not media but report (RTCP or ACK frames) and drops it, BTW: audio packets may also be small.
> This is an example. The claim is that you can use heuristics to drop “selected” frames even though you do not know what is in the packet.
> Roni
>  
>  
>  
> From: Ingemar Johansson S [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: יום ג 07 נובמבר 2017 09:41
> To: Philipp S. Tiesel; Roni Even
> Cc: QUIC WG
> Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments
>  
> Hi Philip and Roni
>  
> I assume that by reception reports is meant the RTCP CCM messages such as TMMBR or ?
>  
> So.. unless I misunderstood it completely.
> I am not at all convinced that media rate/congestion control in QUIC should rely on TMMBR.
> SCReAM for instance, specified in the RMCAT WG for instance does not depend on TMMBR as it is ACK clocked, the media transmission is reduced to a very low rate if the ACKs are discarded by an attacker.
>  
> I would say that it is more straightforward to use a multipurpose congestion control in QUIC, this is perhaps based on BBR, but SCReAM style is not excluded. In any case this means that it is not possible to prevent rate adaptation.
>  
> /Ingemar
>  
>  
> From: Philipp S. Tiesel [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: den 6 november 2017 10:15
> To: Roni Even <[e-mail] <mailto:[e-mail]>>
> Cc: QUIC WG <[e-mail] <mailto:[e-mail]>>
> Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments
>  
>  
>  
> 
> On 5. Nov 2017, at 08:32, Roni Even <[e-mail] <mailto:[e-mail]>> wrote:
> From: Philipp S. Tiesel [mailto:[e-mail] <mailto:[e-mail]>]
> 
> On 1. Nov 2017, at 14:03, Roni Even <[e-mail] <mailto:[e-mail]>> wrote:
> 
> In the security section “ An active, on path attacker can drop selected
> frames “ . What does it mean selected frames, the whole payload is
> encrypted.
> 
> This is a little complicated:
> - Assume having “stream-as-a-message” streams with two different kins of
> messages sized A,B
> - Assume each message fits into one packet, but two messages will not fit
> - Assume one doesn't want to split packets to fill packets to MTU due to
> latency constrains  => If an attacker know the inside protocol, the attacker
> can distinguish from the packet length wether it is an A or B kind message
> 
> To avoid this, one has to pad all packets… I should clarify this.
> [Roni Even] I understand this case but what does selected frames mean, I assume that the attacker does not know what is in each stream in order to select a specific one, so why will he just drop one and not the other or why not both?
>  
> Assuming the attacker _knows the protocol_, the attacker would also know the sizes of all kinds of messages and may use this knowledge to recover protocol state or selectively drop messages.
>  
> For a protocol like HTTP, the attack vector is rather small.
> If one uses this against video conferencing applications, an attacker could prevent rate adaption  by dropping reception reports (larger than a pure QUIC ACK, smaller than a video frame).
> If one uses this on IoT control stuff, an attacker might be able to learn a lot about the system state by observing sizes and timings.
>  
> This is nothing we can fix within QUIC without massive scarifies, but application developers must keep in mind.
>  
>  
> AVE!
>   Philipp S. Tiesel / phils…
> -- 
>    {phils}--->---([e-mail] <mailto:[e-mail]>)--->---(http://phils.in-panik.de <http://phils.in-panik.de/>)----,
>       wenn w eine   aube ist dn      man au dran dre en                   |
>            o     Schr        an muss     hc         h   (Kurt Schwitters) |
> :wq!  <----(phone: [phone])---<---(jabber: [e-mail] <mailto:[e-mail]>)----'

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([e-mail])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: [phone])---<---(jabber: [e-mail])----'