Subject: Subject TBD (Branched from thread Re: Using different crypto)

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

I'm separating this thread out, since it seems to be a separate
conversation. I'm also not sure what this topic is, so please rename the
thread.

On Wed, Jan 11, 2017 at 9:35 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

> 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.
>

Not being facetious: I honestly don't know what your point is.

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

So, preventing others from reading/modifying bits does not prevent
ossification, but designing for them them does?

> 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.
>

QUIC is a transport. We're talking about encrypting QUIC. We are not
talking about encrypting below it. This is above UDP.

> 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.
>

I'm quite certain that we are not talking about the same thing anymore. I'm
talking about encrypting QUIC headers, and QUIC is not a 1990s protocol.
What are you talking about?

- jana

On Wed, Jan 11, 2017 at 10:56 PM, Jana Iyengar <[email-masked]> wrote:
>
>> ​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.
>>
>> 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.
>>>
>>
>> Monitoring is in the charter. The answer to monitoring is not "don't
>> encrypt."
>>
>> Security does not respond well to sloganeering or one size fits all
>>> 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.
>>
>>
>>
>