Subject: Using different crypto

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Jan 2017 18:26:10 +0000

There's a document structure decision that needs feedback from the WG.  We know that we have a very logical document break between the core transport and how TLS behaves.  The question is how sharp that division needs to be.  There are two obvious paths here:

  *   Quic-transport depends on quic-tls.  A future RFC defining QUIC with a different crypto protocol would describe the deviations from quic-transport required to accommodate the new crypto protocol, and would contain the equivalent of quic-tls for the alternate security protocol.
  *   Quic-transport defines requirements for the crypto protocol, whatever it may be, and specifies an interface.  Quic-tls describes how TLS is used to satisfy those requirements and defines a version of QUIC using TLS.  A future RFC would define how a different crypto protocol could be used to satisfy the same requirements and establishes a different version number for that combination.

At the moment, this is somewhat academic, since TLS is the only crypto protocol we're chartered to actually define.  However, it affects how much quic-transport can "know" about TLS.  For example, the current draft has a section on requirements for the crypto protocol.  Various pending PRs propose replacing this with specific references to TLS.  However, there is anecdotal interest in having other crypto protocols in other scenario.

How abstract do we want to be here?

---

From: Ted Hardie <[email-masked]>
Date: Wed, 11 Jan 2017 10:46:17 -0800

Howdy,

On Wed, Jan 11, 2017 at 10:26 AM, Mike Bishop <[email-masked]>
wrote:

> There’s a document structure decision that needs feedback from the WG.  We
> know that we have a very logical document break between the core transport
> and how TLS behaves.  The question is how sharp that division needs to be.
> There are two obvious paths here:
>
>
>
>    - Quic-transport depends on quic-tls.  A future RFC defining QUIC with
>    a different crypto protocol would describe the deviations from
>    quic-transport required to accommodate the new crypto protocol, and would
>    contain the equivalent of quic-tls for the alternate security protocol.
>    - Quic-transport defines requirements for the crypto protocol,
>    whatever it may be, and specifies an interface.  Quic-tls describes how TLS
>    is used to satisfy those requirements and defines a version of QUIC using
>    TLS.  A future RFC would define how a different crypto protocol could be
>    used to satisfy the same requirements and establishes a different version
>    number for that combination.
>
> So, I personally prefer the second style.  That's partly because we may
someday have other crypto protocols, but mostly because it means that when
TLS evolves an updated RFC describing how to use the new facilities doesn't
need to update the transport document.

>
> At the moment, this is somewhat academic, since TLS is the only crypto
> protocol we’re chartered to actually define.  However, it affects how much
> quic-transport can “know” about TLS.  For example, the current draft has a
> section on requirements for the crypto protocol.  Various pending PRs
> propose replacing this with specific references to TLS.  However, there is
> anecdotal interest in having other crypto protocols in other scenario.
>
>
>

We recently saw PERC depend on a specific set of functions in TLS 1.2, then
discover that 1.3 shifted the ground enough that PERC's methods need to be
rethought or PERC kept to an older version of TLS.  That's a recent enough
proof point, at least in my mind, that we should focus on having the
transport treat the interface to the crypto protocol at a more abstract
level.

Just my personal opinion,

Ted

---

From: Ian Swett <[email-masked]>
Date: Wed, 11 Jan 2017 13:47:40 -0500

I would like Quic-transport to define requirements for a crypto protocol,
otherwise it will become hard or impossible to use another type of
handshake.  WebRTC seems like an obvious example, but I'm sure there are
others.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Jan 2017 14:06:40 -0500

I agree with Ted.

The key agreements in TLS are based on a design started in the 1990s and
are a little odd to say the least. The client auth in particular is...
Ephemeral key agreement is done in a really bad way.

So I would expect to find us doing a redesign of TLS at some point. But
that isn't something I would want to do until after QUIC.

One of the chief requirements for QUIC deployment is going to be having a
negotiation mechanism. And hopefully that makes use of DNSSEC. And
hopefully that mechanism provides for encrypting the domain name during the
connection. It might well be plausible to make use of client auth keys as
well.

Adapting TLS to just one of those requirements is possible but probably not
worth the effort. Trying to meet all three would cause the Jenga tower to
collapse, TLS is already too complex.

So please don't weld QUIC to TLS.

On Wed, Jan 11, 2017 at 1:46 PM, Ted Hardie <[email-masked]> wrote:

> Howdy,
>
> On Wed, Jan 11, 2017 at 10:26 AM, Mike Bishop <
> [email-masked]> wrote:
>
>> There’s a document structure decision that needs feedback from the WG.
>> We know that we have a very logical document break between the core
>> transport and how TLS behaves.  The question is how sharp that division
>> needs to be.  There are two obvious paths here:
>>
>>
>>
>>    - Quic-transport depends on quic-tls.  A future RFC defining QUIC
>>    with a different crypto protocol would describe the deviations from
> We recently saw PERC depend on a specific set of functions in TLS 1.2,
> then discover that 1.3 shifted the ground enough that PERC's methods need
> to be rethought or PERC kept to an older version of TLS.  That's a recent
> enough proof point, at least in my mind, that we should focus on having the

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 11 Jan 2017 19:07:31 +0000

> So, I personally prefer the second style.  That's partly because we may someday have other crypto protocols, but mostly because it means that when TLS evolves an updated RFC describing how to use the new facilities doesn't need to update the transport document.  

Another reason why I prefer #2 is that it might enabled "stripped down" TLS stacks that are optimized only to support QUIC.  That seems like a good thing to be able to do, e.g., for IoT.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 11 Jan 2017 14:23:36 -0500

Folks interested in this who aren't reading the github comment traffic
(highly recommended fwiw) will find
https://github.com/quicwg/base-drafts/pull/122 useful reading.

To me this largely boils down to whether we want to add a crypto
negotiation mechanism or just tie it to the transport versioning. I think
in a practical sense what we have (transport versioning) is sufficient and
makes it much easier to feel confident and reason about version 1. (That
would be support for option 1.)

-Patrick

On Wed, Jan 11, 2017 at 2:07 PM, Salz, Rich <[email-masked]> wrote:

> Another reason why I prefer #2 is that it might enabled "stripped down"
> TLS stacks that are optimized only to support QUIC.  That seems like a good
> thing to be able to do, e.g., for IoT.
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 11 Jan 2017 11:42:39 -0800

I'm unclear as to how people envision versioning in practice.

Is each non-experimental QUIC version a new RFC? Are there likely to be
lots of these, or only a handful after many years? Certainly, if TCP used
versioning rather than option negotiation there might be many permutations
of options that would result in a high version count, so that might point
to lots of versions.

Relatedly, are we likely to see versions branch out into different use
cases (QUIC for IoT, or whatever), or pretty much have the latest version
be the best common practice?

So in option (1) that Mike lays out, when the crypto handshake changes we
would have a very short RFC that defines QUIC version 5, that says,
"everything is the same as QUIC version 4 except that the handshake uses
the foo protocol". This will get really cumbersome if different versions
support different use cases.

I think it is much less painful to negotiate the handshake separately (e.g.
option 2). Maybe in practice that means we reserve 4 bits (or whatever) of
the version number for the crypto handshake, while the other 28 bits
correspond to the transport RFC.

On Wed, Jan 11, 2017 at 11:23 AM, Patrick McManus <[email-masked]>
wrote:

> (highly recommended fwiw) will find https://github.com/quicwg/
> base-drafts/pull/122 useful reading.
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Jan 2017 11:44:55 -0800

I basically agree with McManus here. It's really much easier to have the
transport versioning
and the crypto protocol advance in sequence, especially because it means
you can reason
about the document concretely.

Responding to a few other points people raised (rather than flooding
everyone's mailbox
with n messages):

> We recently saw PERC depend on a specific set of functions in TLS 1.2,
then discover
> that 1.3 shifted the ground enough that PERC's methods need to be
rethought or PERC
> kept to an older version of TLS.  That's a recent enough proof point, at
least in my mind,
> that we should focus on having the transport treat the interface to the
crypto protocol at
> a more abstract level.

I am familiar with the incident you are familiar with here and I think
you're drawing the
wrong conclusion from it. Specifically, PERC was depending on some
undocumented
assumptions about TLS and when those assumptions were violated, we got into
trouble.
That seems like it's actually fairly likely to happen here if we try to
write down a set of
requirements that are intended to capture what role TLS is playing here,
just because
layer boundaries are never as clear are you really want (and QUIC tends to
push on that
anyway)

> I would like Quic-transport to define requirements for a crypto protocol,
otherwise it will become
>  hard or impossible to use another type of handshake.  WebRTC seems like
an obvious example,
> but I'm sure there are others.

I'm pretty familiar with the case of WebRTC, and I'm having trouble seeing
why it wouldn't continue
to use a TLS-style handshake here. The requirements don't really change if
you replace SRTP
with QUIC.

> Another reason why I prefer #2 is that it might enabled "stripped down"
TLS stacks that are optimized
> only to support QUIC.  That seems like a good thing to be able to do,
e.g., for IoT.

I'm sorry, I'm not following this. Certainly that would be a good thing,
but I'm not seeing how an
abstraction layer helps here. What you need there is a profile of TLS.

With all that said, I can see that this is a discussion we are going to
have to have at the Interim

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 11 Jan 2017 20:04:53 +0000

> I basically agree with McManus here.

Mozilla group-think :)

> > Another reason why I prefer #2 is that it might enabled "stripped down" TLS stacks that are optimized
> > only to support QUIC.  That seems like a good thing to be able to do, e.g., for IoT.

> I'm sorry, I'm not following this. Certainly that would be a good thing, but I'm not seeing how an

Because the abstraction is really a requirements layer, as Mike said.  Therefore if I know the requirements, I can just do what's needed.  Yes, there are issues about whether that's really practical or not.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Jan 2017 12:19:06 -0800

> > I basically agree with McManus here.

What can I say, we're right-thinking.

-Ekr

> Because the abstraction is really a requirements layer, as Mike said.
> Therefore if I know the requirements, I can just do what's needed.  Yes,
> there are issues about whether that's really practical or not.
>
>

---

From: Ian Swett <[email-masked]>
Date: Wed, 11 Jan 2017 15:20:29 -0500

> would be support for option 1.)

I think making a QUIC version indicate crypto and QUIC RFC at once is
fine.  However, that doesn't mean the QUIC transport doc has to depend upon
the TLS mapping doc.  I would think that we can just swap "TLS 1.3" for
"Crypto handshake" in all places it occurs and have the RFC make sense.  If
others think this is infeasible, it'd be helpful to have examples of why.

Re: Martin's Duke's question of having many versions at once or mostly the
latest-greatest, I would hope that most QUIC users would be on the latest
greatest, but as with TLS, there will be users on older versions for some
time.

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 11 Jan 2017 12:22:30 -0800

> Because the abstraction is really a requirements layer, as Mike said.  Therefore if I know
> the requirements, I can just do what's needed.  Yes, there are issues about whether that's
> really practical or not.

The abstraction also facilitates modular code development and testing. For example, developers could use a trivial crypto layer during tests, so they can test the protocol logic without having a dependency on TLS stack. Then, they can slide in the TLS stack of their choice, without changing the transport code.

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 10:28:42 +1300

On 12 January 2017 at 09:20, Ian Swett <[email-masked]> wrote:
> I think making a QUIC version indicate crypto and QUIC RFC at once is fine.
> However, that doesn't mean the QUIC transport doc has to depend upon the TLS
> mapping doc.  I would think that we can just swap "TLS 1.3" for "Crypto
> handshake" in all places it occurs and have the RFC make sense.  If others
> think this is infeasible, it'd be helpful to have examples of why.

I suggest that you read PR 122 and - critically - PR 120 for concrete
reasons why this isn't as simple as you are making out.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 11:09:17 +1300

I like that people seem to forget engineering basics when it comes to
things like this, preferring to let desire for ponies get the better
of them.

Primarily, talking in terms of abstractions makes writing and
understanding the document considerably harder [0].  If you want to
see how bad this can be, then think about how you might rewrite PR 120
and 122 in terms of abstractions (I would run the exercise for you,
but I would prefer to spend my time getting -01 ready for you to
review).

Understanding the abstraction and the requirements is valuable, but
that's not what is in question. On the contrary, the definition of the
abstraction has been made clearer than before.  See the overview in
the TLS doc [1] or the entire section on the interface [2].

I see this as an editorial question: where do we put the pieces of the
protocol and how do we describe them?

So then, what do we actually gain by maintaining the abstraction as an
editorial construct?  Making it easier to kick TLS to the kerb sounds
like it could be an advantage. But we won't gain that.  Once you have
a protocol that meets the requirements, it's easy to write a document
that replaces TLS, regardless of how our documents are written now.

YAGNI,
Martin

[0] I can't pretend not to care about the writing part, but hope that
we can all agree on the understanding piece.
[1] https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#protocol-overview
[2] https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#interface-to-tls

On 12 January 2017 at 07:26, Mike Bishop <[email-masked]> wrote:
> Quic-transport depends on quic-tls.  A future RFC defining QUIC with a
> different crypto protocol would describe the deviations from quic-transport
> required to accommodate the new crypto protocol, and would contain the
> equivalent of quic-tls for the alternate security protocol.
> Quic-transport defines requirements for the crypto protocol, whatever it may
> be, and specifies an interface.  Quic-tls describes how TLS is used to
> satisfy those requirements and defines a version of QUIC using TLS.  A
> future RFC would define how a different crypto protocol could be used to
> satisfy the same requirements and establishes a different version number for
> that combination.
>
>
>

---

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Jan 2017 22:42:48 +0000

Let’s be clear – neither of these options proposes that the crypto protocol be negotiated separately.  I’m assuming we go with Ian’s suggestion that a QUIC “version” represents a combination of QUIC transport and crypto handshake.  If we want a “menu” approach, that’s potentially harder.

There’s very little technical difference here – there will need to be a new RFC and a new version number if someone wants to use a different crypto protocol.  However, it has a major effect on document structure – in particular, that -transport would not explicitly depend on -tls.  That implies moving some content that currently exists in -tls into -transport, and (as Martin alludes to) make the -transport document by itself potentially harder to understand.

From: QUIC [mailto:[email-masked]] On Behalf Of Martin Duke
Sent: Wednesday, January 11, 2017 11:43 AM
To: Patrick McManus <[email-masked]>
Cc: Mike Bishop <[email-masked]>; Ted Hardie <[email-masked]>; Salz, Rich <[email-masked]>; Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: Using different crypto

Is each non-experimental QUIC version a new RFC? Are there likely to be lots of these, or only a handful after many years? Certainly, if TCP used versioning rather than option negotiation there might be many permutations of options that would result in a high version count, so that might point to lots of versions.

Relatedly, are we likely to see versions branch out into different use cases (QUIC for IoT, or whatever), or pretty much have the latest version be the best common practice?

So in option (1) that Mike lays out, when the crypto handshake changes we would have a very short RFC that defines QUIC version 5, that says, "everything is the same as QUIC version 4 except that the handshake uses the foo protocol". This will get really cumbersome if different versions support different use cases.

I think it is much less painful to negotiate the handshake separately (e.g. option 2). Maybe in practice that means we reserve 4 bits (or whatever) of the version number for the crypto handshake, while the other 28 bits correspond to the transport RFC.

On Wed, Jan 11, 2017 at 11:23 AM, Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:
Folks interested in this who aren't reading the github comment traffic (highly recommended fwiw) will find https://github.com/quicwg/base-drafts/pull/122 useful reading.

To me this largely boils down to whether we want to add a crypto negotiation mechanism or just tie it to the transport versioning. I think in a practical sense what we have (transport versioning) is sufficient and makes it much easier to feel confident and reason about version 1. (That would be support for option 1.)
-Patrick

---

From: Ted Hardie <[email-masked]>
Date: Wed, 11 Jan 2017 14:58:47 -0800

On Wed, Jan 11, 2017 at 2:42 PM, Mike Bishop <[email-masked]>
wrote:

> Let’s be clear – *neither* of these options proposes that the crypto
> protocol be negotiated separately.  I’m assuming we go with Ian’s
> suggestion that a QUIC “version” represents a combination of QUIC transport
> and crypto handshake.  If we want a “menu” approach, that’s potentially
> harder.
>
>
>
There’s very little technical difference here – there will need to be a new
> RFC and a new version number if someone wants to use a different crypto
> protocol.  However, it has a major effect on document structure – in
> particular, that -transport would not explicitly depend on -tls.  That
> implies moving some content that currently exists in -tls into -transport,
> and (as Martin alludes to) make the -transport document by itself
> potentially harder to understand.
>
>
>

The other consequence is on what documents need to be opened up when you
have a new crypto handshake.  If TLS 1.N (or 2.0)  has a new handshake, I
would prefer a world in which that can get described in a new version of
quick-tls, without requiring the transport document get revved at the same
time.  At most, it should have to update the transport RFC to list the new
version, but a scoped registry could avoid even that.  That approach avoids
the risk of re-hashing everything just because the crypto changed.

If that means I want a pony, so be it.  Ponies are real animals, not
mythical ones; you can get one if you spend the money.  Yep, there are real
costs to this and to ponies, but it isn't like wishing for a unicorn.  More
realistically, I don't think this is a high end show pony with a video-chat
enabled stable; it's more like a trap pony.
<https://en.wikipedia.org/wiki/Trap_(carriage)> It gets a bit of work done,
and, while there are certainly alternatives, this one is a pretty
well-known quantity..

Two cents,

Ted

*From:* QUIC [mailto:[email-masked]] *On Behalf Of *Martin Duke
> *Sent:* Wednesday, January 11, 2017 11:43 AM
> *To:* Patrick McManus <[email-masked]>
> *Cc:* Mike Bishop <[email-masked]>; Ted Hardie <
> [email-masked]>; Salz, Rich <[email-masked]>; Jana Iyengar <
> [email-masked]>; IETF QUIC WG <[email-masked]>; Martin Thomson <
> [email-masked]>
> *Subject:* Re: Using different crypto
>
>
>
> I think it is much less painful to negotiate the handshake separately
> (e.g. option 2). Maybe in practice that means we reserve 4 bits (or
> whatever) of the version number for the crypto handshake, while the other
> 28 bits correspond to the transport RFC.
>
>
>
>
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 12:24:17 +1300

On 12 January 2017 at 11:58, Ted Hardie <[email-masked]> wrote:
> If TLS 1.N (or 2.0)  has a new handshake, I would prefer a world in which
> that can get described in a new version of quick-tls

If we go with https://github.com/quicwg/base-drafts/pull/138 then TLS
N won't require changes to any document.

Rather than continue to beat about the bushes - we're unlikely to find
any actual ponies there - let's ask the real question.  You only plan
to replace something if you plan to replace it: do you want to replace
TLS?  And why?

---

From: Martin Duke <[email-masked]>
Date: Wed, 11 Jan 2017 15:41:25 -0800

> to replace something if you plan to replace it: do you want to replace

(1) The most likely scenario I can think of is a desire for a lighter (or
nonexistent!) crypto regime for applications that don't care that much
about security. I know SSL-everywhere is an article of faith for many
people, but there are also applications where messing around with
certificates is way more trouble than it's worth (ietf.org doesn't use TLS
:-)).

Whether that is a valid future use case for QUIC is debatable, but that's
the most likely reason to move from TLS.

(2) Some sort of out-of-band key agreement.

(3) Perhaps people who know more about crypto than me can think of a
situation (quantum computing?) where TLS is fundamentally inappropriate.

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Jan 2017 17:42:00 -0800

(Just catching up on this thread.)

Addressing the editorial: The original goal in my mind was to have an
abstract interface in the transport doc, and I've wanted to fill out the
"Crypto Requirements" section to actually define the right interface. I'm
still in favor of keeping TLS out of the transport doc, and I'm happy to
work on text to make it happen. I don't want to belittle the writing issue
here -- I spent many hours on splitting the parts of QUIC into pieces -- I
think it's important enough that I'm willing to spend more hours trying to
keep those pieces separate.

If we assume TLS in the transport doc now, there will be all sorts of
TLS-creep, making it that much harder to change it later. FWIW, it's not
just modularity for the sake of it, but the "right" kind of modularity
that's let us do integration of crypto with transport while allowing us to
replace QUIC crypto in the Google QUIC implementation with TLS. There's no
reason to not allow a handshake that an application bundle decides to use.

Addressing the understanding: The -00 drafts are structured in a way as to
say that HTTPS requires QUIC with TLS. HTTPS using QUIC requires TLS, and a
different application using QUIC might use non-TLS. I don't imagine that
HTTPS is going to require anything but TLS, but that's not the case if
we're leaving QUIC open to other applications (which we are.) Baking TLS
into the transport draft means that a new application that wants to use
QUIC but not TLS will have to (i) define an application mapping doc and
(ii) change the transport doc. That hardly seems sensible.

I'm not sure I follow the logic for combining QUIC and TLS versions as well
-- I expect that TLS version negotiation will happen on Stream 1 as per its
state machine. Why is this an issue?

- jana

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 14:47:56 +1300

> state machine. Why is this an issue?

I think that the plan was to say that QUIC version 1 uses TLS (any version).

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Jan 2017 17:48:25 -0800

> but I would prefer to spend my time getting -01 ready for you to

IIU 120 correctly, this moves the source-address token functionality into
TLS. Why's this necessary? The current -00 draft says:
" Source Address Spoofing Defense: Since QUIC handles source address
  verification, the crypto protocol SHOULD NOT impose a separate
  source address verification mechanism."

This leaves the onus on the transport, which is similar to how TLS 1.3
interacts with TFO.

- jana

> We

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 14:50:47 +1300

> This leaves the onus on the transport, which is similar to how TLS 1.3

Well, there we have a problem: QUIC doesn't define source address
spoofing defense, so what the -00 draft says is at best hopeful (but
mostly just inaccurate).  TLS does/can, so the idea of the PR is to
let TLS do it.

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Jan 2017 17:51:19 -0800

I don't think QUIC needs to say anything about using TLS. The HTTP mapping
draft should pull QUIC and TLS together so that any bits that go to port
443 have the bits delivered on stream 1 be TLS bits, but I don't think this
is necessary for QUIC itself to require.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 14:52:27 +1300

On 12 January 2017 at 14:51, Jana Iyengar <[email-masked]> wrote:
> draft should pull QUIC and TLS together so that any bits that go to port 443
> have the bits delivered on stream 1 be TLS bits, but I don't think this is
> necessary for QUIC itself to require.

That means defining the QUIC version in an application mapping
definition.  Doesn't that go back to baking the QUIC version into the
application protocol negotiation?

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Jan 2017 17:58:45 -0800

> mostly just inaccurate).  TLS does/can, so the idea of the PR is to

Fair enough, and *I think* we should define source address spoofing defense
in QUIC. Since the crypto handshake might provide it (if TLS is used with
the right extension), maybe we could provide an out? (I'll need to read the
TLS extension to ensure that it does all the things we may want to do, such
as encode multiple source IP addresses within one token, to allow client
IPs to change back and forth.)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Jan 2017 21:03:52 -0500

Before folk go too far down the TLS rabbit hole. Consider that the Web
isn't just about browsing, it is also about Web Services and TLS isn't
necessarily a suitable security solution for a Web Service.

In process control (i.e. SCADA) security, the concern is authenticity, not
confidentiality. If you talk to process control folk they will often say
that they don't want their packets to have encryption. They want
authentication, not confidentiality. They also tend to run their networks
in a very different style. They don't usually tolerate chatty protocols
that broadcast noise for no particular reason.

For this type of application, QUIC offers a lot of benefits but they are
probably going to want to do authentication at the transaction level rather
than transport.

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Jan 2017 18:21:16 -0800

On Wed, Jan 11, 2017 at 5:52 PM, Martin Thomson <[email-masked]>
wrote:

> 443

I think so, but what do you mean by "going back to"? Did I say something
else at some point? I'm entirely capable :-)

I did say that the HTTP mapping pulls QUIC and TLS together, so I think
that would need the HTTP mapping to know the QUIC version, which seems
reasonable to me. For clarity, as I imagine it:
- an HTTP/x client initiates a QUICvN with TLS1.K. This first creates a
QUIC packet that contains a TLS ClientHello message (which has ALPN set to
"hXq").
- QUIC version negotiation is isolated from anything that happens on Stream
1. Specifically, QUIC will retransmit the TLS ClientHello bits as per QUIC
version negotiation.
- From TLS's point of view, the encapsulating QUIC packet is irrelevant.
Its view is that of the TLS version, and ALPN for negotiating the right
application atop. The ALPN is tied to the version of HTTP mapping which is
tied to a version of both the transport and TLS mapping drafts.

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Jan 2017 18:26:37 -0800

> authentication, not confidentiality.
>

Unencrypted transport is not in scope for the wg. From
https://datatracker.ietf.org/wg/quic/charter/: "The QUIC working group will
provide a standards-track specification for a UDP-based,
stream-multiplexing, encrypted transport protocol ..."

Unencrypted transport unfortunately leads to an ossified transport.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Jan 2017 02:26:57 +0000

At one point, ALPN tokens implied an app protocol + QUIC version + crypto protocol 3-tuple.  We changed this in one of the PRs (already merged?), we changed this because you can't *find* the ALPN token until you've already agreed on version and handshake protocol.  Now it says that ALPN specifies the app protocol ONLY, and the app protocol MAY restrict which versions of QUIC it can be used with.

In the big PR on HTTP, BTW, the TLS restriction has been removed.  If people want it back, we certainly can, but I don't see a hard requirement.

Sent from my Windows 10 phone

From: Jana Iyengar<mailto:[email-masked]>
Sent: Wednesday, January 11, 2017 6:21 PM
To: Martin Thomson<mailto:[email-masked]>
Cc: Ted Hardie<mailto:[email-masked]>; Mike Bishop<mailto:[email-masked]>; Martin Duke<mailto:[email-masked]>; Patrick McManus<mailto:[email-masked]>; Salz, Rich<mailto:[email-masked]>; IETF QUIC WG<mailto:[email-masked]>
Subject: Re: Using different crypto

On Wed, Jan 11, 2017 at 5:52 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

I think so, but what do you mean by "going back to"? Did I say something else at some point? I'm entirely capable :-)

I did say that the HTTP mapping pulls QUIC and TLS together, so I think that would need the HTTP mapping to know the QUIC version, which seems reasonable to me. For clarity, as I imagine it:
- an HTTP/x client initiates a QUICvN with TLS1.K. This first creates a QUIC packet that contains a TLS ClientHello message (which has ALPN set to "hXq").
- QUIC version negotiation is isolated from anything that happens on Stream 1. Specifically, QUIC will retransmit the TLS ClientHello bits as per QUIC version negotiation.
- From TLS's point of view, the encapsulating QUIC packet is irrelevant. Its view is that of the TLS version, and ALPN for negotiating the right application atop. The ALPN is tied to the version of HTTP mapping which is tied to a version of both the transport and TLS mapping drafts.

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Jan 2017 18:43:20 -0800

On Wed, Jan 11, 2017 at 6:26 PM, Mike Bishop <[email-masked]>
wrote:

> At one point, ALPN tokens implied an app protocol + QUIC version + crypto
> protocol 3-tuple.  We changed this in one of the PRs (already merged?), we
> changed this because you can't **find** the ALPN token until you've
> already agreed on version and handshake protocol.  Now it says that ALPN
> specifies the app protocol ONLY, and the app protocol MAY restrict which
> versions of QUIC it can be used with.
>

I missed it. I'll go take a look, but this definitely sounds like something
that needs to be discussed, perhaps at the interim. But I don't follow the
problem -- it seems obvious that you can't find the ALPN token until the
TLS version is agreed upon. So, in my imaginary world, the ALPN token
indicates the version of the HTTP mapping document, which specifies the
QUIC and TLS versions.

*I think* it's reasonable to expect that the HTTP layer confirms the
current TLS version being used meets the requirements of the one specified
through the ALPN tag, and the QUIC version in use meets the requirements of
the ALPN tag.

In the big PR on HTTP, BTW, the TLS restriction has been removed.  If
> people want it back, we certainly can, but I don't see a hard requirement.
>

I don't understand what it means to remove the TLS restriction. It seems
odd to have HTTP running on top of an encrypted transport but not have a
TLS requirement. Is the idea that we could use something other than TLS for
HTTPS?

- jana

> *From: *Jana Iyengar <[email-masked]>
> *Sent: *Wednesday, January 11, 2017 6:21 PM
> *To: *Martin Thomson <[email-masked]>
> *Cc: *Ted Hardie <[email-masked]>; Mike Bishop
> <[email-masked]>; Martin Duke <[email-masked]>; Patrick
> McManus <[email-masked]>; Salz, Rich <[email-masked]>; IETF QUIC
> WG <[email-masked]>
> *Subject: *Re: Using different crypto
>
>
> - QUIC version negotiation is isolated from anything that happens on
> Stream 1. Specifically, QUIC will retransmit the TLS ClientHello bits as
> per QUIC version negotiation.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Jan 2017 21:46:32 -0500

On Wed, Jan 11, 2017 at 9:43 PM, Jana Iyengar <[email-masked]> wrote:

> On Wed, Jan 11, 2017 at 6:26 PM, Mike Bishop <[email-masked]
> > wrote:
>
> I missed it. I'll go take a look, but this definitely sounds like
> something that needs to be discussed, perhaps at the interim. But I don't
> follow the problem -- it seems obvious that you can't find the ALPN token
> until the TLS version is agreed upon. So, in my imaginary world, the ALPN
> token indicates the version of the HTTP mapping document, which specifies
> the QUIC and TLS versions.
>

​Yes.

TLS is built with TCP in mind using 1990s crypto. It has been extended
multiple times. At some point you either profile or start from scratch. ​

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Jan 2017 21:51:18 -0500

On Wed, Jan 11, 2017 at 9:26 PM, Jana Iyengar <[email-masked]> wrote:

> https://datatracker.ietf.org/wg/quic/charter/: "The QUIC working group
> will provide a standards-track specification for a UDP-based,
​The WG scope says what the WG is to work on now. Nobody should ever read a
charter to mean that the design must not be capable of extension to other
use cases in the future.

They do have good reason for not wanting encryption. It is more important
to them to be able to debug their networks and stop their plan blowing up
than to protect confidentiality.

Security does not respond well to sloganeering or one size fits all
solutions.​

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Jan 2017 18:53:35 -0800

+1. The charter is absolutely clear on this point.

-Ekr

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Jan 2017 02:54:38 +0000

I agree.  However, I’m not sure that quite fits the current discussion.  If the crypto protocol is factored out, the packet protection being done with the keys it provides probably moves to the transport doc.  In that case, you would need to rev the transport protocol anyway to not encrypt packets, if that was a desired property of a different QUIC version.

From: Phillip Hallam-Baker<mailto:[email-masked]>
Sent: Wednesday, January 11, 2017 6:51 PM
To: Jana Iyengar<mailto:[email-masked]>
Cc: Martin Thomson<mailto:[email-masked]>; Mike Bishop<mailto:[email-masked]>; Ted Hardie<mailto:[email-masked]>; Salz, Rich<mailto:[email-masked]>; Patrick McManus<mailto:[email-masked]>; IETF QUIC WG<mailto:[email-masked]>; Martin Duke<mailto:[email-masked]>
Subject: Re: Using different crypto

On Wed, Jan 11, 2017 at 9:26 PM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

In process control (i.e. SCADA) security, the concern is authenticity, not confidentiality. If you talk to process control folk they will often say that they don't want their packets to have encryption. They want authentication, not confidentiality.

Unencrypted transport is not in scope for the wg. From https://datatracker.ietf.org/wg/quic/charter/: "The QUIC working group will provide a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol ..."

?The WG scope says what the WG is to work on now. Nobody should ever read a charter to mean that the design must not be capable of extension to other use cases in the future.

They do have good reason for not wanting encryption. It is more important to them to be able to debug their networks and stop their plan blowing up than to protect confidentiality.

Security does not respond well to sloganeering or one size fits all solutions.?

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Jan 2017 19:37:15 -0800

> multiple times. At some point you either profile or start from scratch. ​

I wasn't clear: I was asking if we expect the use of HTTP in the HTTP
mapping draft to expect anything other than TLS. My expectation is that if
you use something other than TLS, then the HTTP mapping draft should change
to reflect this.

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Jan 2017 19:56:05 -0800

>
> ​The WG scope says what the WG is to work on now. Nobody should ever read
> a charter to mean that the design must not be capable of extension to other
> use cases in the future.
>

That misses why encryption of QUIC was put in the charter in the first
place. That wasn't to scope the problem, it was a pre-requisite for
building a deployable and maintainable transport.

If Google-deployed QUIC was not encrypted, it would have seen ossification
by now. We would have no way to evolve it in the IETF, and this wg would be
simply documenting it.

> than to protect confidentiality.

Monitoring is in the charter. The answer to monitoring is not "don't
encrypt."

> solutions.​

Agreed. Which is why we are relying on deployment experience and not
expecting that QUIC will be used for everything in all cases. I'm happy
that TCP's going to be around for situations where an encrypted transport
cannot be used.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 11 Jan 2017 21:30:06 -0800

> N won't require changes to any document.
If we go with a non-abstract description, I think that's a good pull
request, but I think it's assuming the result of the abstraction discussion
too much to try and close the discussion with it at this point.

> to replace something if you plan to replace it: do you want to replace

I _plan_ for replacing things when I see a history of those things getting
replaced.  In this particular case, we know that multiple applications may
eventually run over this transport and they may have their own histories.
If folks start running DNS over this, for example, I suspect someone will
at least look at adapting DSNCrypt to work with QUIC.

That particular example may not make come to pass, but hopefully it is
illustrative of where our thinking apparently differs here.

regards,

Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Jan 2017 00:35:57 -0500

No, I fully understand the reasons why a small unrepresentative monoculture
with one perspective on a problem would insist on one solution. But that
doesn't make it right.

Putting encryption into things is not a way to prevent ossification.
Modular design with clear separations of concerns is.

Historically, IPSEC was a conformance requirement for IPv6 and vice versa.
Then people realized that was a mistake. My preference is to encrypt at the
transport, message and often at multiple levels inside the message layer.

Your rhetoric really doesn't match your argument. You are arguing to ossify
use of a 1990s protocol that is designed for one purpose and does it well.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Jan 2017 00:53:14 -0500

Another possible outcome is that we end up in an SSH/TLS situation. They
were originally one protocol but they diverged as TLS was not willing to
adapt to SSH demands or the SSH people particularly interested in
participation.

Having two QUIC like protocols that are slightly different for different
purposes is not necessarily a disaster. But it is not something that should
be casually accepted. A charter is not intended to allow people to say 'it
says here that we can screw you, yah boo sucks'. The point of a charter is
to allow work to get done by focusing on a narrow scope. But extensibility,
layering and separation of concerns are always in scope.

---

From: Martin Duke <[email-masked]>
Date: Thu, 12 Jan 2017 05:58:52 +0000

Jana, can you elaborate as to why unencrypted Google QUIC would have
ossified by now? I cannot connect that argument, and must be missing
something basic.

To be clear, I am not suggesting that this iteration of QUIC should allow
unencrypted traffic. I am providing an example, to answer Martin's
question, of something our IETF successors might want to do other than use
TLS 1.x. The immediate impact is to make the transport document as
crypto-agnostic as possible.

---

From: Martin Duke <[email-masked]>
Date: Thu, 12 Jan 2017 06:00:20 +0000

Sorry, never mind. I see now that the encryption is needed to block
middlebox nonsense.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Jan 2017 16:12:34 +1300

On 12 January 2017 at 18:30, Ted Hardie <[email-masked]> wrote:
> If folks start running DNS over this, for example, I suspect someone will at
> least look at adapting DSNCrypt to work with QUIC.

I think that we are largely disagreeing on the nature of the plan and
the degree of up-front work.  Both plans hinge on defining a new QUIC
version number, so - as I said before - it's largely a matter of paper
shuffling.  I would rather let those future people deal with a little
more work, especially given that P < 1 of that ever happening.

Like I said, YAGNI applies.

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 12 Jan 2017 20:01:21 -0800

> Like I said, YAGNI applies.

​I should mention that internal to Google we are already using QUIC with a
different handshake protocol, one which keys are delivered out-of-band.​ It
has been a vision from the very early days of QUIC that the handshake
protocol could be swapped out. (And of course we're doing this in the "QUIC
crypto" to TLS 1.3 conversion). As such, I strongly agree with Mike's
option #2.