Re: Stream0 Design Team Proposal

[Eric Rescorla <[e-mail]>]

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.


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?

-Ekr



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