Re: Stream0 Design Team Proposal

[Ted Hardie <[e-mail]>]

Howdy,

Thanks for sharing the document.  I have a couple of detailed comments, and
then some high level comments which I will put into a separate email.

First, the document says this:

Though proper analysis is needed, it is not likely that the removal of the
TLS record layer will cause a security concern, because the security
properties provided by QUIC packets are identical to what have been
provided by TLS records.


I'm not sure that this is actually the statement we need to analyze,
though. We need to be sure that the security properties of TLS records used
in TCP packets are available in QUIC streams in QUIC packets using UDP as a
multiplexing layer. There appear to be some difference in where the
facilities the overall system provides that may require more description.
As an example, I think the way padding works in this proposal needs more
description. If I understand correctly, each TLS record is encrypted
separately and the presence or absence of padding is indicated by a
padding_length byte present in each record. That means the padding is
related to the record, not the packet; by removing the record layer and
using QUIC frames, though, we seem to have a different padding structure.
QUIC uses padding frames, not padding within other frame types which is
both conceptually and practically different. Similarly, I'd be interested
in more text on the interaction with precedence, since the loss of the
record layer means that the former guarantee that the record layer makes
records available in the order in which they were protected now seems to be
unavailable.


Secondly, I think the advantages of the different number spaces would be
present in many different designs, and I would a prefer that a proposal for
that be decoupled from the other pieces of this. At least to my
understanding, the attacks it mitigates are unrelated to the other stream 0
issues that this addresses.


regards,


Ted





On Tue, May 22, 2018 at 6:30 PM, Ian Swett <
ianswett=[e-mail]> wrote:

>
>
>
>
>
>
>
> *Dear QUIC WG,On behalf of the Stream 0 Design Team, I am pleased to
> report that we have consensus on a proposed approach to share with the WG.
> The DT's proposal will make QUIC and TLS work closer together and
> incorporates ideas from DTLS, but it does not use the DTLS protocol itself.
> The DT believes this solves the important open Stream 0 issues. The
> proposal will be a bit more invasive in TLS, but we believe it is the right
> long-term direction and several TLS stacks (BoringSSL, PicoTLS, NSS, and
> Mint) are willing and able to do the work necessary.. A number of stacks
> are currently working on implementations of this new approach, which we
> hope to have in time for the Interim meeting.A design document describing
> the overall approach can be found
> at:https://docs.google.com/document/d/1fRsJqPinJl8N3b-bflDRV6auojfJLkxddT93j6SwHY8/edit
> <https://docs.google.com/document/d/1fRsJqPinJl8N3b-bflDRV6auojfJLkxddT93j6SwHY8/edit>A
> PR making the changes to the QUIC documents can be found
> at:https://github.com/quicwg/base-drafts/pull/1377
> <https://github.com/ekr/base-drafts/pull/29>A few design details did not
> have clear consensus, but it was felt it would be better to discuss those
> in the wider WG than delay the design team.  A consistent choice was made
> in the PR and these issues are mentioned in Appendix B of the design doc.As
> always, comments and questions welcome. That said, this is a big PR and we
> recognize that some editorial work is going to be needed before merging. In
> the interest of letting people follow along, and to keep github from
> falling over, we ask people to keep discussion on the mailing list and
> refrain from making PR comments.See you in Kista!*
> Ian and Eric
>