Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FA512049D for ; Fri, 12 Apr 2019 09:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id segD-yYDdYDT for ; Fri, 12 Apr 2019 09:50:16 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5EF7120816 for ; Fri, 12 Apr 2019 09:50:15 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id p16so9065811iod.2 for ; Fri, 12 Apr 2019 09:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7VLwicLWuiUjEpoZ2pwbTpByE268MCK5CPM4uK4ekQ4=; b=Fs75l9NImYXfrxKIpmSUaLq3CBSjv0y+OfXHazFq19XbbFstUbAdAqDx19Ie6oHNEZ CYACoTlr0mYhTsbBeB2itm8kNLh4zeRu9hwQf3A5FRa8ESw3QCMIuFEVmHd1hXxFuW4a 4frSRfjNTY3ha/YlelLjapJYqJjruBKg6ITrYxZnnCiAiSFgGl3DbJAmdpBvpc6ufMN9 3+nMhx5CdC7ofMQOX9Nxv08Y67EZ0D2CwPyEnizoDdf8d3QChOTSN8gNpaDuiSyK5UES u8MNzZKhx48MeIC2Or9mojWorTzc2Qjc4parPEDZwGCsv8kGdsmM6OcCaET5h3WPcO2H Nc4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7VLwicLWuiUjEpoZ2pwbTpByE268MCK5CPM4uK4ekQ4=; b=DBVRe9Fo7DEF+wF44Fah4EdjhHSpHhAzGtUL6qZI+EkN2hlcSTSTeokqlgzdpPxj7Y E/FEbXgjzp2BlYyvoVo3WW0nSIG/twVnrG2CvjaFiBPe9nmuqxTxVAIfw1H3CdlzmhVJ UoXXgWecofoM6x04p20Ngq/U+rkX+lfacp4jLLoBFac0WHMQRsEbcKzvpxR/25clwjJH TRHCV6ID/HeSTQ/gR1EWJmQoOkv38axzHFJZXlxhH0o6XBaC3L8h78UTUZzCU3JHJhig lS5JTHCLOwGHMgk83dsyMiwNNUsiSbDOxZlHWhHRr+5PJbnZDhezebBGxdqsguUfCgvp xeAQ== X-Gm-Message-State: APjAAAU3yT3LJqD9HELnrYUSH/3mOjrcSg4Fg4m/JMRW0pNEOuFmDcEl W+tqFmBIKzvFwkU7tUOQJ/gh6+hWF21A7eoOWeM= X-Google-Smtp-Source: APXvYqysyhQnpanflSqcTluRWTMZu2luE7rH7pGOShbCpZnz8LyGNxXDpEdq+mpT9LrRBFm/N6mnWF3XcQlDW0Z+ldo= X-Received: by 2002:a6b:e50a:: with SMTP id y10mr16244042ioc.91.1555087815078; Fri, 12 Apr 2019 09:50:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Fri, 12 Apr 2019 09:49:48 -0700 Message-ID: Subject: Re: QUICker connection establishment with out-of-band validation tokens To: sy@informatik.uni-hamburg.de Cc: QUIC WG Content-Type: multipart/alternative; boundary="000000000000cffaa50586581868" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:50:23 -0000 --000000000000cffaa50586581868 Content-Type: text/plain; charset="UTF-8" I would like to suggest that the Chairs rule this out of scope for the QUIC working group to consider during the completion of v1. Given where we are in the process, taking on the security and privacy analyses required will not be a short or simple exercise. To give a flavor of the analysis required, consider this from the proposal: To save a round-trip time via the proposed out-of-band tokens, the client > needs to receive the token before sending the connection request to the corresponding > QUIC server. Furthermore, clients usually do a domain name query to look > up the source address before they send their connection request. Thus, > DNS seems to be a suitable place to distribute out-of-band tokens as the > connection request often directly follows the corresponding DNS lookup > First, this proposal contains major assumptions about the DNS interactions that would appear to run counter to DNS caching semantics and, more generally, its distribution by recursive resolvers. While it might be possible to overcome the implied limitations by the use of short TTLs and very aggressive use of EDNS client-subnet, the performance impact of doing so would be unknown and the privacy implications appear to be poor. Second, it requires a level of trust between the resolver operator and the entity generating the tokens that is near total, acknowledged in the draft here: Note, that to construct valid out-of-band tokens, the resolver needs to be > trusted by the server hosting the specific domain name. Thus, the > respective server operator shared in advance the instructions and the > secret keys required to generate valid tokens for this domain. > There are many additional questions raised by the proposal, including when to consider including the novel RR as additional data, the interaction with DNSSEC, and the potential need to use a STUN-like service to get a view of the IP as it will be seen by the QUIC-speaking server. I appreciate the work of the authors to consider out-of-bind distribution, but I do not believe this proposal should be considered by the working group at this time. regards, Ted Hardie (wearing no hats) On Fri, Apr 12, 2019 at 7:18 AM Erik Sy wrote: > Hi folks, > > I suggest introducing out-of-band validation tokens to save a round-trip > time during QUIC's connection establishment. > These tokens can be distributed via DNS resolvers or other QUIC servers > and can avoid up to 100% of stateless retries during connection > establishments. > Below is a detailed description and evaluation on performance, security, > privacy and scalability of this proposal: > > https://svs.informatik.uni-hamburg.de/publications/2019/2019-04-12-Sy-preprint-QUICker_connection_establishment_with_out-of-band_validation_tokens.pdf > > Best, > Erik > > --000000000000cffaa50586581868 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to suggest that the Chairs rule this out= of scope for the QUIC working group to consider during the completion of v= 1.=C2=A0 Given where we are in the process, taking on the security and priv= acy analyses required will not be a short or simple exercise.
To give a flavor of the analysis required, consider this from t= he proposal:

To save a = round-trip time via the proposed out-of-band tokens, the client needs to receive the token b= efore sending the connection request to the corresponding QUIC server. Furthermore, = clients usually do a domain name query to look up the source address before they send their c= onnection request. Thus, DNS seems to be a suitable place to distribute out-of-b= and tokens as the connection request often directly follows the corresponding DN= S lookup

First, this proposal = contains major assumptions about the DNS interactions that would appear to = run counter to DNS caching semantics and, more generally, its distribution = by recursive resolvers.=C2=A0 While it might be possible to overcome the im= plied limitations by the use of short TTLs and very aggressive use of EDNS = client-subnet, the performance impact of doing so would be unknown and the = privacy implications appear to be poor.=C2=A0 Second, it requires a level o= f trust between the resolver operator and the entity generating the tokens = that is near total, acknowledged in the draft here:

Note, that to construct valid out-of-ba= nd tokens, the resolver needs to be trusted by the server hosting the specific domai= n name. T= hus, the respective server operator shared in advance the instructions and the secre= t keys required to generate valid tokens for this domain.
<= div>
There are many additional questions raised by the propos= al, including when to consider including the novel RR as additional data, t= he interaction with DNSSEC, and the potential need to use a STUN-like servi= ce to get a view of the IP as it will be seen by the QUIC-speaking server.= =C2=A0

I appreciate the work of the authors t= o consider out-of-bind distribution, but I do not believe this proposal sho= uld be considered by the working group at this time.=C2=A0
<= br>
regards,

Ted Hardie
(weari= ng no hats)
=C2=A0

=
On Fri, Apr 12, 2019 at 7:18 AM Erik = Sy <sy@informatik.uni-ha= mburg.de> wrote:
Hi folks,

I suggest introducing out-of-band validation tokens to save a round-trip ti= me during QUIC's connection establishment.
These tokens can be distributed via DNS resolvers or other QUIC servers and= can avoid up to 100% of stateless retries during connection establishments= .
Below is a detailed description and evaluation on performance, security, pr= ivacy and scalability of this proposal:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0
https://svs.informatik.un= i-hamburg.de/publications/2019/2019-04-12-Sy-preprint-QUICker_connection_es= tablishment_with_out-of-band_validation_tokens.pdf

Best,
Erik

--000000000000cffaa50586581868--