Re: Stream0 Design Team Proposal

[Jana Iyengar <[e-mail]>]

Ted,

I agree that we should be careful and describe differences in detail where
they exist before making any conclusions about a security analysis. Perhaps
we ought to bring this in front of the tlswg and make sure that folks there
get a chance to poke holes in this proposal.

That said, I don't believe your mapping from records to frames is right. As
I see it, the equivalent of a TLS record in this proposal is a QUIC packet.
Both are encrypted similarly, and both contain pieces of or one or multiple
messages. Padding in TLS is present within the records but outside
messages. Equivalently, padding in this proposal is present within packets
but outside frames carrying TLS messages.

- jana

On Wed, May 23, 2018 at 2:20 PM, Mikkel Fahnøe Jørgensen <[e-mail]
> wrote:

> I believe you have misunderstood. In this document, there are no TLS
>> records and TLS handshake messages are carried in CRYPTO_HS frames.
>> Accordingly, padding is provided in the same fashion as QUIC ordinarily
>> does, i.e., using PADDING frames.
>>
>> That's what I understood from the design document.  The point I'm making
> is that this actually a substantive change to the padding structure that
> was previously present (in TLS records), and the security analysis has to
> take that into account, so it (and similar things) should be described.
>
> As an example of things to consider, padding is probably a fair point.
> From a practical perspective, padding could be seen as a pain from older
> crypto formats that needs to be dealt with in TLS while the crypto
> primitives of QUIC already has an answer to this problem.
>
> But if TLS messages contain encryption primitives beyond what QUIC
> provides in early handshake that assumption breaks down while the QUIC
> crypto is still weak. For example concerning the encoding of key exchange
> parameters. So at the very least it must be stated that this is not an
> issue and why it is not issue.
>