Subject: RE: Bike shed warning: integrity check for unprotected packets

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Mar 2017 12:52:56 +0000

> My personal preference here lies with the algorithms which can be implemented on a typical CPU without a lookup table -- that is to say, not CRC or GHASH.  GHASH might be fine since it's MTI for TLS anyways.

So you want something that can be done in constant-time without data-dependant side-channels?  +1 to that.  GHASH isn't in TLS, unless I'm mistaken tho.

---

From: David Benjamin <[email-masked]>
Date: Wed, 01 Mar 2017 16:10:34 +0000

On Wed, Mar 1, 2017 at 7:53 AM Salz, Rich <[email-masked]> wrote:

> > My personal preference here lies with the algorithms which can be
> implemented on a typical CPU without a lookup table -- that is to say, not
> CRC or GHASH.  GHASH might be fine since it's MTI for TLS anyways.
>
> So you want something that can be done in constant-time without
> data-dependant side-channels?  +1 to that.  GHASH isn't in TLS, unless I'm
> mistaken tho.
>

(GHASH is what AES-GCM uses.)

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Mar 2017 16:11:30 +0000

>  (GHASH is what AES-GCM uses.)

... aand, I was wrong.  Oops.

---

From: Ian Swett <[email-masked]>
Date: Wed, 1 Mar 2017 11:41:20 -0500

+1 to making it version dependent and I agree 32 bits is probably plenty to
filter out internet junk.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 1 Mar 2017 16:57:23 +0000

Ø  +1 to making it version dependent

Ian, so you are not too concerned with the server not being able to tell whether the unknown version number is due to a corruption or just an unknown version? That information informs the server behavior – drop the packet or send a version negotiation packet.

From: Ian Swett [mailto:[email-masked]]
Sent: Wednesday, March 01, 2017 11:41 AM
To: Salz, Rich <[email-masked]>
Cc: Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>; David Benjamin <[email-masked]>
Subject: Re: Bike shed warning: integrity check for unprotected packets

+1 to making it version dependent and I agree 32 bits is probably plenty to filter out internet junk.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 1 Mar 2017 09:14:57 -0800

On Wed, Mar 1, 2017 at 8:57 AM, Lubashev, Igor <[email-masked]> wrote:

> Ian, so you are not too concerned with the server not being able to tell
> whether the unknown version number is due to a corruption or just an
> unknown version? That information informs the server behavior – drop the
> packet or send a version negotiation packet.
>
>
>

If the version number is corrupted and the server responds with a version
negotiation packet, what's the harm?  Presumably the server will respond
with a list of supported versions and the client will pick one (potentially
the same one it picked the first time).  As long as clients don't assume
they have to change version when they get a version negotiation packet from
the server, this seems to be a reasonable result.

Am I missing something that makes this worse?

regards,

Ted

>
>
> *From:* Ian Swett [mailto:[email-masked]]
> *Sent:* Wednesday, March 01, 2017 11:41 AM
> *To:* Salz, Rich <[email-masked]>
> *Cc:* Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>;
> Martin Thomson <[email-masked]>; David Benjamin <
> [email-masked]>
> *Subject:* Re: Bike shed warning: integrity check for unprotected packets
>
>
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 1 Mar 2017 17:36:35 +0000

It just opens up more corner cases to consider and document.  This is by no means an important decision for me.  I tend to prefer keeping things simple where extensibility needs seem very low. But I understand others making different trade-offs.

From: Ted Hardie [mailto:[email-masked]]
Sent: Wednesday, March 01, 2017 12:15 PM
To: Lubashev, Igor <[email-masked]>
Cc: Ian Swett <[email-masked]>; Salz, Rich <[email-masked]>; Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>; David Benjamin <[email-masked]>
Subject: Re: Bike shed warning: integrity check for unprotected packets

On Wed, Mar 1, 2017 at 8:57 AM, Lubashev, Igor <[email-masked]<mailto:[email-masked]>> wrote:

>  +1 to making it version dependent

If the version number is corrupted and the server responds with a version negotiation packet, what's the harm?  Presumably the server will respond with a list of supported versions and the client will pick one (potentially the same one it picked the first time).  As long as clients don't assume they have to change version when they get a version negotiation packet from the server, this seems to be a reasonable result.
Am I missing something that makes this worse?
regards,
Ted

From: Ian Swett [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 01, 2017 11:41 AM
To: Salz, Rich <[email-masked]<mailto:[email-masked]>>
Cc: Victor Vasiliev <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; David Benjamin <[email-masked]<mailto:[email-masked]>>
Subject: Re: Bike shed warning: integrity check for unprotected packets

---

From: Ian Swett <[email-masked]>
Date: Wed, 1 Mar 2017 13:00:33 -0500

I think the logic is still fairly simple:
1) Look at version, if you support it, check the hash and move forward.
2) If you don't support the version, don't check the hash and sent a
version negotiation packet.

#2 would change to "do check the hash" if we made the hash fixed.

On Wed, Mar 1, 2017 at 12:36 PM, Lubashev, Igor <[email-masked]> wrote:

> It just opens up more corner cases to consider and document.  This is by
> no means an important decision for me.  I tend to prefer keeping things
> simple where extensibility needs seem very low. But I understand others
> making different trade-offs.
>
>
>
> *From:* Ted Hardie [mailto:[email-masked]]
> *Sent:* Wednesday, March 01, 2017 12:15 PM
> *To:* Lubashev, Igor <[email-masked]>
> *Cc:* Ian Swett <[email-masked]>; Salz, Rich <[email-masked]>;
> Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>;

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 08:27:46 +1100

On 1 March 2017 at 23:52, Salz, Rich <[email-masked]> wrote:
> So you want something that can be done in constant-time without data-dependant side-channels?

The key would be public, the data is going to be also.  That's not a
requirement.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 08:30:37 +1100

On 2 March 2017 at 04:14, Ted Hardie <[email-masked]> wrote:
> Presumably the server will respond with a list of supported versions and the
> client will pick one (potentially the same one it picked the first time).

Actually, I think that the right approach here is to ignore a version
negotiation packet that includes your already-chosen version.  The
client can just keep retransmitting it's initial packet.

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 1 Mar 2017 16:55:38 -0500

On Wed, Mar 1, 2017 at 12:57 AM, Martin Thomson <[email-masked]>
wrote:

> On 1 March 2017 at 15:55, Victor Vasiliev <[email-masked]> wrote:
> > I am not entirely clear -- are you suggesting to use CRC-32 (as defined
> in
> > V.42), or CRC-32Cc (as used in SCTP)?
>
> My mistake, I intended to state CRC32, the SCTP thing was in error
> (it's a different polynomial and I failed to recognize that).
>
> You don't think that support in recent processors for CRC32
> instructions is enough to meet your requirement?
>

As far as I recall, SSE 4.2 uses CRC-32C and not CRC-32.  One can use CLMUL
for this, but it's not as widespread as SSE 4.2.

On a second reflection, lookup tables are not that much of a problem as a
polyfill.  We won't be able to find a solution which works well for all
embedded applications, because some of them would be very unhappy with
lookup
tables (required to polyfill CRC32 and GHASH), while others will be
allergic to
any form of integer multiplication (required for FNV1a and Poly1305).

  -- Victor.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 1 Mar 2017 22:39:02 +0000

> The client can just keep retransmitting it's initial packet.

That may be a problem, if the path causes a persistent, deterministic corruption (a bad line card, etc -- these things happen).  Would the server then reply with a versions negotiation packet again? And the client retransmit again?  This is the kind of complexity and corner cases I was worried about.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, March 01, 2017 4:31 PM
To: Ted Hardie <[email-masked]>
Cc: Lubashev, Igor <[email-masked]>; Ian Swett <[email-masked]>; Salz, Rich <[email-masked]>; Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>; David Benjamin <[email-masked]>
Subject: Re: Bike shed warning: integrity check for unprotected packets

On 2 March 2017 at 04:14, Ted Hardie <[email-masked]> wrote:
> Presumably the server will respond with a list of supported versions 
> and the client will pick one (potentially the same one it picked the first time).

Actually, I think that the right approach here is to ignore a version negotiation packet that includes your already-chosen version.  The client can just keep retransmitting it's initial packet.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 09:54:23 +1100

> That may be a problem, if the path causes a persistent, deterministic corruption (a bad line card, etc -- these things happen).  Would the server then reply with a versions negotiation packet again…

If the path is doing that, then I suspect that QUIC is not going to
work.  Arguably the path is busted and learning this is the first step
in fixing it.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 1 Mar 2017 23:02:04 +0000

>> That may be a problem, if the path causes a persistent, deterministic corruption (a bad line card, etc -- these things happen).
>> Would the server then reply with a versions negotiation packet again? And the client retransmit again?
>> This is the kind of complexity and corner cases I was worried about.
>
> If the path is doing that, then I suspect that QUIC is not going to work

Yes, that's for sure.  But I would like to avoid client's and server's QUIC stacks automatically sending an unending series of packets to each other as quickly as they can.  I.e. client retransmitting, path corrupting, server replying with a version negotiation packet, repeat.  I'd be much better of one side would just stop quickly and bounce the error up to the client's application.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, March 01, 2017 5:54 PM
To: Lubashev, Igor <[email-masked]>
Cc: Ted Hardie <[email-masked]>; Ian Swett <[email-masked]>; Salz, Rich <[email-masked]>; Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>; David Benjamin <[email-masked]>
Subject: Re: Bike shed warning: integrity check for unprotected packets

> That may be a problem, if the path causes a persistent, deterministic corruption (a bad line card, etc -- these things happen).  Would the server then reply with a versions negotiation packet again…

If the path is doing that, then I suspect that QUIC is not going to work.  Arguably the path is busted and learning this is the first step in fixing it.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 10:02:55 +1100

> for this, but it's not as widespread as SSE 4.2.

You are right.  Despite being advertised as CRC32, it is indeed using
the CRC32c polynomial.  ARM has both from 8.1 onward.

While this is an entertaining diversion, I don't think that speed is
especially relevant to the choice of checksum algorithm.  The bulk of
QUIC packets will be protected with an AEAD.  Speed concerns are less
relevant here than things like code size, maintainability, and reuse.

I'm thinking that CRC32c is the better choice here given its
apparently greater prevalence.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 10:03:57 +1100

> Yes, that's for sure.  But I would like to avoid client's and server's QUIC stacks automatically sending an unending series of packets to each other as quickly as they can.  I.e. client retransmitt…

Given that your example was a pathological error, I am perfectly happy
to let the client time this one out.  That should only take a few
seconds and a handful of exchanges.

---

From: Ian Swett <[email-masked]>
Date: Wed, 1 Mar 2017 20:35:35 -0500

It may be a pathological error, but I think we'd like to fail a bit more
quickly on this one, because tight loops, particularly in low-latency
environments, can be really nasty.

If I send a packet with a version, and then receive a version negotiation
packet, one of two cases arises:
1) The version I sent is not in the list of versions the server sent, and I
start over.
2) The version I sent is in the list of versions the server sent, and the
handshake fails, because that indicates something is very broken.

If one was worried about #2 being a potential path for censorship, the
client could ignore the version negotiation packet entirely as being
invalid?

On Wed, Mar 1, 2017 at 6:03 PM, Martin Thomson <[email-masked]>
wrote:

> > Yes, that's for sure.  But I would like to avoid client's and server's
> QUIC stacks automatically sending an unending series of packets to each
> other as quickly as they can.  I.e. client retransmitting, path corrupting,
> server replying with a version negotiation packet, repeat.  I'd be much
> better of one side would just stop quickly and bounce the error up to the
> client's application.
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 13:59:51 +1100

> 1) The version I sent is not in the list of versions the server sent, and I

This only happens once.

> handshake fails, because that indicates something is very broken.

I'm suggesting that you ignore this on the basis that either the
server is reacting to corruption, or its an attack (yes, censorship
being one example).  I'd happily recommend that this be treated as
fatal if it happened often.