Re: Getting to consensus on packet number encryption

[Ian Swett <[e-mail]>]

As expressed previously, I tend to think PN encryption is the most
pragmatic way forward at the moment.

However, is anyone who would prefer a different solution(ie: packet number
jumps or separate spaces) willing to send out a PR they think solves the
link-ability issue PN encryption solves?

My mental model is there are a fair number of thorny edge cases, but maybe
if I saw them in a PR, it wouldn't be as scary as I think?

On Wed, Apr 4, 2018 at 5:28 PM Mark Nottingham <[e-mail]> wrote:

> Mirja,
>
> On 4 Apr 2018, at 8:27 pm, Mirja Kühlewind <
> [e-mail]> wrote:
> >
> > Hi Mark,
> >
> > without intending to state a technical opinion, I think I need to
> disagree with your assessment of the situation. Please see below.
> >
> >> Am 04.04.2018 um 06:58 schrieb Mark Nottingham <[e-mail]>:
> >>
> >> Hi everyone,
> >>
> >> The editors have told your chairs that this issue is starting to block
> progress on other aspects of QUIC. Coming to consensus on it soon (i.e.,
> before Stockholm, if possible) would be good.
> >>
> >> It looks like this thread has come to a natural pause. Reading through
> it, I think we agree there are some unpleasant tradeoffs here, but so far
> we have only one concrete proposal -- PR#1079.
> >
> > The other proposal is to use a random offset that can/should be changed
> when the connection ID is changed. Which is mostly inline with what the
> draft currently says.
>
> As I understand it, the status quo has caused a significant amount of
> pain, complexity and potential bugs. PN encryption was proposed by Kazuho
> in Melbourne as a way to work around that.
>
> We can, of course, decide that the status quo is the right approach.
> However, my current reading of the WG is that it isn't acceptable.
>
>
> >> My AU$.05 - While we're chartered to produce a protocol that's
> encrypted as much as operational concerns allow,
> >
> > I don’t think this is what the charter say. The charter says "Providing
> always-secure transport, using TLS 1.3 by default.“ plus another paragraph
> that talks about TLS1.3. It does not spell out the desire of some
> individual to „encrypt as much as possible“.
>
> I think that depends on how you read "always-secure." The charter also
> says we will provide "confidentiality and integrity protection of both
> application data and QUIC headers."
>
>
> >> and that privacy is a natural extension of that (especially in light of
> RFC7258 and RFC6973), there is no *requirement* that we produce a protocol
> that is able to be accelerated by hardware.
> >
> > Not there is no requirement that the protocol need to be accelerated by
> hardware. However, not all requirement are listed in the charter. We as a
> group have to define the requirement. However, there is of course an
> implicit requirement for all work in the IEFT that is must be deployable
> and serve the needs of those people who want to deploy it.
>
> Yes - a discussion that I'm trying to draw out. Thanks.
>
>
> >> That being the case, I think we need to ask ourselves if we believe
> that inclusion of PR#1079 will significantly inhibit deployment of the
> protocol. Based on the discussion so far, that doesn't seem to be the case,
> but I'd be interested to hear what others think.
> >
> > Here my assessment is also different. There are multiple people that
> have raised concerns that this could hinder deployment.
>
> As you know, we don't assess consensus just by the number of people that
> have raised concerns, but also the technical merit of the arguments. So
> far, the arguments have been all over the map, and I want them to converge.
>
> The data that's been provided has been very helpful, but we need to
> evaluate that in the context of how QUICv1 will actually be deployed and
> used -- something which a few threads have touched upon.
>
> Overall, I do not think it is a goal of QUIC to be deployable on any
> system for any purpose; if we try to design it for all purposes, we're
> going to fail. The question, then, is how much deployment / implementation
> / adoption we need to make it succeed -- and to design for that.
>
>
> >> If we can get to consensus to incorporate the PR, and folks come back
> later with a more hardware-friendly replacement that doesn't change the
> Invariants or increase linkability, I suspect the WG will be amenable to
> that.
> >
> > I don’t think to just go with what we have even though there are
> concerns, is the right approach and definitely not the approach that was
> chosen for other proposals. In the sake of getting version v1 out quickly,
> I would think that not incorporating another change that does not have
> consensus is the proposer approach.
>
> I wasn't proposing that we incorporate a change without consensus --
> please re-read my statement. You may disagree with how the chairs
> eventually call consensus on this issue, and there are mechanisms for you
> to appeal (or even DISCUSS) that, but it's premature to start that now.
>
> That said -- One way to prove that PNE hurts deployability is to try it;
> implementers have a very strong incentive to make sure their code can be
> deployed, so if those who have concerns are correct, it's probably the
> easiest way for them to be proven right.
>
> Thanks,
>
>
> > Mirja
> >
> >
> >
> >>
> >> What do folks think?
> >>
> >> Cheers,
> >>
> >>
> >>> On 29 Mar 2018, at 11:39 am, Ian Swett <ianswett=
> [e-mail]> wrote:
> >>>
> >>> Thanks for the nice summary Jana.
> >>>
> >>> As much as I'd love to have easier crypto HW acceleration, I've ended
> up arriving at the same conclusion.  I don't want to bite off the work to
> do proper multipath in QUIC v1, which I think is the only other reasonable
> option of those Christian outlined.
> >>>
> >>> If someone comes up with a way to transform packet number to make it
> non-linkable, but doesn't have the downside of making hardware offload
> difficult, then I'm open to it.  But we've been talking about this for 2
> months without any notable improvements over Martin's PR.
> >>>
> >>> Given we never talk about any issue only once in QUIC, I'm sure this
> will come up again, but for the time being I think #1079 is the best option
> we have.
> >>>
> >>>
> >>>
> >>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <[e-mail]>
> wrote:
> >>> A few quick thoughts as I catch up on this thread.
> >>>
> >>> I spent some time last week working through a design using multiple PN
> spaces, and it is quite doable. I suspect we'll head towards multiple PN
> spaces as we consider multipath in the future. That said, there is
> complexity (as Christian notes). This complexity may be warranted when
> doing multipath in v2 or later, but I'm not convinced that this is
> necessary as a design primitive for QUICv1.
> >>>
> >>> We may want to creatively use the PN bits in v2, say to encode a path
> ID and a PN, for multipath. We want to retain flexibility in these bits
> going into v2. We've used encryption to ensure that we don't lose
> flexibility elsewhere in the header, and it follows that we should use PNE
> to retain flexibility in these bits as well. (Simplicity of design is the
> other value in using PNE, since handling migration linkability is
> non-trivial without it.)
> >>>
> >>> This leaves the question of HW acceleration being at loggerheads with
> the design in PR #1079. First, I expect that the primary benefit of
> acceleration will be in DC environments. Yes, there are some gains to be
> had in serving the public Internet as well, but I'm unconvinced that this
> is the driving use case for hardware acceleration. I understand that others
> may disagree with me here.
> >>>
> >>> AFAIK, QUIC has not been used in DC environments yet. I expect there
> are other things in the protocol that we'd want to change as we gain
> experience deploying QUIC in DCs. Spinning up a new version to try QUIC
> within DCs is not only appropriate, I would recommend it. This allows for
> rapid iterations internally, and the experience can drive subsequent
> changes to QUIC. It's what *I* would do if I was to deploy QUIC inside a DC.
> >>>
> >>> So, in short, I think we should go ahead with PR# 1079. This ensures
> that future versions are guaranteed the flexibility to change the PN bits
> for better support of HW acceleration or multipath or what-have-you.
> >>>
> >>> - jana
> >>>
> >>> On Mar 26, 2018 9:41 AM, "Christian Huitema" <[e-mail]>
> wrote:
> >>>
> >>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote:
> >>>> Looking at
> https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architecture
> it seems to imply a large range of server, desktop and mobile chips all
> have a CPU instruction set available to do AES acceleration and other
> similar operations (other instruction sets are also available).
> >>>>
> >>>> If we are considering the AES instructions then it looks like it is
> (or at least will be in the near future) a sizeable proportion of the
> public internet have it to be used.
> >>>>
> >>>
> >>> Certainly, but that's not the current debate. PR #1079 is fully
> compatible with use of the AES instructions. The issue of the debate is
> that the mechanism in PR #1079 required double buffering, first encrypt the
> payload, then use the result of the encryption to encrypt the PN. This is
> not an issue in a software implementation that can readily access all bytes
> of the packet from memory, but it may be an issue in some hardware
> implementations that are designed to do just one pass over the data.
> >>>
> >>>
> >>> -- Christian Huitema
> >>>
> >>>
> >>>
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >>
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>