Re: [secdir] Secdir review of draft-ietf-quic-tls-48

[Lucas Pardue <[e-mail]>]

Hello,

As mentioned previously, review comments raised during the secdir tls
review were captured as issues on the QUIC WG GitHub repository. These
issues have been assessed by the document editor(s) and shepherd, please
see each individual issue for more-specific discussion. As a summary, the
following resolutions for issues are:

Close with no action
====================
https://github.com/quicwg/base-drafts/issues/4323

Kinds regards
Lars and Lucas
QUIC WG Co-chairs

On Mon, Nov 2, 2020 at 7:42 AM Lars Eggert <[e-mail]> wrote:

> Hi Radia,
>
> thank you for the review. I've opened a GitHub issue for any discussion
> related to this review: https://github.com/quicwg/base-drafts/issues/4323
>
> There is also a milestone at
> https://github.com/quicwg/base-drafts/milestone/7.
>
> Thanks,
> Lars
>
> > On 2020-11-1, at 4:40, Radia Perlman <[e-mail]> wrote:
> >
> > I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
> >
> > This document specifies the cryptographic exchanges and formats
> associated with the QUIC protocol, which in turn is an ambitious protocol
> that could over time replace TCP. quic-transport, quic-tls, and
> quic-recovery represent a triple of I-Ds that are always used together and
> could be combined into a single spec, though the length of the existing
> specs is already daunting. In many cases, it is impossible to evaluate them
> independently.
> >
> > As an interested outsider, I see these protocols as exceptionally well
> designed and the specs exceptionally well written. I could not find even
> any nits in a very long spec.
> >
> > It is misleading to regard this as a specification of running QUIC over
> TLS. It is related to TLS in the same way that DTLS is related to TLS: it
> imports much of the syntax, but there are many differences and its security
> must be evaluated largely independently. My initial reaction to this spec
> was to wonder why it did not simply run QUIC over DTLS . I believe the
> answer is that careful integration improves the performance and is
> necessary for some of the address agility/transition design.
> >
> > Given its potential importance, this deserves a thorough review by our
> best security people. Fortunately, from the acknowledgements list, it
> appears it has gotten that.
> >
> > There are a few aspects of the design that might raise eyebrows. For
> example:
> >
> > 1) TLS exchanges start out in cleartext until a key can be negotiated.
> QUIC data is always encrypted. The initial packets are encrypted with fixed
> keys whose derivation is specified in the I-D until fresh keys are
> negotiated. This isn't a security problem...it will just surprise people.
> >
> > 2) Applications using TLS can usually be configured to run over TCP in
> contexts where cryptographic protection is not needed. (e.g., use HTTP
> instead of HTTPS). Applications using QUIC cannot. That is likely to mean
> in practice that it will more frequently be the case that applications
> using QUIC will need to connect to servers without certificates signed by a
> CA trusted by the client (because that's the substitute when connecting to
> a server without a certificate). It's not clear what the spec should say
> about that, but perhaps the problem should be acknowledged.
> >
> > Radia
> >
>
>