From nobody Tue Apr 20 16:24:28 2021 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC513A246B for ; Tue, 20 Apr 2021 16:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 iNGR8X5sxurd for ; Tue, 20 Apr 2021 16:24:18 -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 2C9893A2410 for ; Tue, 20 Apr 2021 16:24:18 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id e186so40245246iof.7 for ; Tue, 20 Apr 2021 16:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DnsYtDew6QzeYmOvcIStY5gzKovBMfmDd2gwEXdcrwo=; b=bkaCqXuhFI7rN1v9Q7IY+HwvWjT/5mQuXvIgkFvYNTQOrrmoNGqM2ogTpJthJ6ykTB nPUOp7t3thw9SXdYcIM3tS2YyPXd9rwG8OsVETNObr4XAFH903yb5U13WQ87oD+1BHtt rSrBjOtoIA+f70Gywc2qhapyRpmQ0frzjpENZSGwppvxeDYa8OjBSwtrNs9xNtlPxnFf CBXLZORuqO3oPj4gU8R/eqtmRjRC1iXBqbzYj1SQrT3pm8/pU8BJj2nplHqOsRaDP0Qh xlqeKukT1GG4khurqKI5yQcsijmoTc0u63AntTlovrhqVeT+LqtVneTDW4mAk65rfJZJ 6LLA== 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=DnsYtDew6QzeYmOvcIStY5gzKovBMfmDd2gwEXdcrwo=; b=nrCajXubMurpcM0dDGLMtoleSOMuxuRoabctRVDmxsyD9E6/K1LjA57/RrKeoKS2Me inH4upWyIxkQQUQ6isjr4Oq/eCnHa+xjeagwg4VsUc2xgigAD0ThZ+jLyAFMe7YVk7rF XPTJPzll+gh5L6BFo5DSgdlB0yHs3u8fepKBS084kjFOaiORA/3P4Y9jr2wUzohRLfbw Rq1MFiLBD39iogc6fRjvFGQlG/+9MQ00Fc/COXS9HF5aceLaJwkqPb06srWw2z7a464w H7+jQVSm9+f7SPdnY1AL2P5I1NQ3wRLjYcG12cUEvZ7YFArHmjj8XzL2ZZm2IvJnRvTd Zd7w== X-Gm-Message-State: AOAM532VzNoNTL2hIN8kIBZALHvZzeBfKGD7Q4hl+28ku1D5Ff+iKzkF lcTt1ipFq/+ETfPMuLHsB+6ZAzMVsnadgiPBa2Sxwg== X-Google-Smtp-Source: ABdhPJxgWJGfAO+dT+lu+Q6E+LHj7CQPuZBkqI/7pZgNcNAgikisi5nqgDePexr0eDTJS96neLQh+BlQXhT2SOFcl78= X-Received: by 2002:a05:6602:3342:: with SMTP id c2mr7271967ioz.98.1618961056975; Tue, 20 Apr 2021 16:24:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 20 Apr 2021 16:23:40 -0700 Message-ID: To: John Scudder Cc: The IESG , "draft-ietf-tls-dtls-connection-id@ietf.org" , tls-chairs , "tls@ietf.org" , Joseph Salowey Content-Type: multipart/alternative; boundary="000000000000b4e06605c06fbe95" Archived-At: Subject: Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 23:24:25 -0000 --000000000000b4e06605c06fbe95 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 20, 2021 at 3:42 PM John Scudder wrote: > On Apr 20, 2021, at 5:32 PM, Eric Rescorla wrote: > > 3. Section 6: >> >> * There is a strategy for ensuring that the new peer address is able >> to receive and process DTLS records. No such strategy is defined >> in this specification. >> >> This is a little mind-boggling to me. I understand this to mean I can=E2= =80=99t >> send >> the new address a DTLS record unless I=E2=80=99ve already ensured it can= receive >> and >> process that record, right? This seems almost like a classic Catch-22. I >> feel >> like I must be missing something. > > > This specification *only* allows you to mux, but doesn't allow you to > migrate. > We could probably make this point clearer. > > > Yes, I think so. Various things led me to think this was supposed to be a > feature. For starters, the abstract: > > A CID is an identifier carried in the record layer header that gives > the recipient additional information for selecting the appropriate > security association. In "classical" DTLS, selecting a security > association of an incoming DTLS record is accomplished with the help > of the 5-tuple. If the source IP address and/or source port changes > during the lifetime of an ongoing DTLS session then the receiver will > be unable to locate the correct security context. > > > It=E2=80=99s true the abstract doesn=E2=80=99t promise that I can migrate= to the new > address, but I felt led in that direction. But more to the point, =C2=A76= itself: > > When a record with a CID is received that has a source address > different than the one currently associated with the DTLS connection, > the receiver MUST NOT replace the address it uses for sending records > to its peer with the source address specified in the received > datagram unless the following three conditions are met: > > > If I understand your reply correctly, the quoted sentence could end =E2= =80=9C=E2=80=A6 > unless the following three conditions are met (which will never happen):= =E2=80=9D. > Since that seems both capricious and pointless, I still think I=E2=80=99m= missing > something. Is it that you envision a future specification that does defin= e > a strategy that will fulfill the third condition? > Yes. -Ekr --000000000000b4e06605c06fbe95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 20, 2021 at 3:42 PM John = Scudder <jgs@juniper.net> wrot= e:
On Apr 20, 2021, at 5:32 PM, Eric Rescorla <ekr@rtfm.com> wrote:=
3. Section 6:

=C2=A0 =C2=A0*=C2=A0 There is a strategy for ensuring that the new peer add= ress is able
=C2=A0 =C2=A0 =C2=A0 to receive and process DTLS records.=C2=A0 No such str= ategy is defined
=C2=A0 =C2=A0 =C2=A0 in this specification.

This is a little mind-boggling to me. I understand this to mean I can=E2=80= =99t send
the new address a DTLS record unless I=E2=80=99ve already ensured it can re= ceive and
process that record, right? This seems almost like a classic Catch-22. I fe= el
like I must be missing something.

This specification *only* allows you to mux, but doesn't allow you= to migrate.
We could probably make this point clearer.

Yes, I think so. Various things led me to think this was supposed to b= e a feature. For starters, the abstract:

   A CI=
D is an identifier carried in the record layer header that gives
   the recipient additional information for selecting the appropriate
   security association.  In "classical" DTLS, selecting a securi=
ty
   association of an incoming DTLS record is accomplished with the help
   of the 5-tuple.  If the source IP address and/or source port changes
   during the lifetime of an ongoing DTLS session then the receiver will
   be unable to locate the correct security context.

It=E2=80=99s true the abstract doesn=E2=80=99t promise that I can migr= ate to the new address, but I felt led in that direction. But more to the p= oint, =C2=A76 itself:

   When a record with a CID is received that has a source addres=
s
   different than the one currently associated with the DTLS connection,
   the receiver MUST NOT replace the address it uses for sending records
   to its peer with the source address specified in the received
   datagram unless the following three conditions are met:

If I understand your reply correctly, the quoted sentence could end = =E2=80=9C=E2=80=A6 unless the following three conditions are met (which wil= l never happen):=E2=80=9D. Since that seems both capricious and pointless, = I still think I=E2=80=99m missing something. Is it that you envision a future specification that does define a strategy that will fulf= ill the third condition?
Yes.

-Ekr

--000000000000b4e06605c06fbe95--