Re: Stream0 Design Team Proposal

[Ted Hardie <[e-mail]>]

On Wed, May 23, 2018 at 1:23 PM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Wed, May 23, 2018 at 12:42 PM, Ted Hardie <[e-mail]> wrote:
>
>> 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.
>>
>
> 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.

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

I'm not quite sure I follow what you are asking about here. In both cases,
TLS sits on top of QUIC's reliable in-order deliver guarantees. Is the
point you are making that formerly, if QUIC violated these guarantees, that
would result in TLS handshake failure, whereas now it does not?

This just related to the general point I was making above.  When the design
shifts where it was getting a function, it would be helpful if it called it
out more directly, to facilitate the analysis.

regards,

Ted

-Ekr
>
>
>
>> regards,
>>
>>
>> Ted
>>
>>
>>
>>
>>
>> On Tue, May 22, 2018 at 6:30 PM, Ian Swett <ianswett=40google.com@dmarc.i
>> etf.org> 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
>>>
>>
>>
>