Re: Stream0 Design Team Proposal

[Eric Rescorla <[e-mail]>]

On Wed, May 23, 2018 at 2:00 PM, Ted Hardie <[e-mail]> wrote:

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

I don't think most of the analyses take padding into account, partly
because basically nobody pads, so nobody was assuming that padding came
from TLS.

-Ekr



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=[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
>>>>
>>>
>>>
>>
>