Re: [TLS] AD Evaluation of draft-ietf-tls-dtls13-39

Eric Rescorla <ekr@rtfm.com> Sun, 07 February 2021 20:37 UTC

Return-Path: <ekr@rtfm.com>
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 CF0593A12E3 for <tls@ietfa.amsl.com>; Sun, 7 Feb 2021 12:37:34 -0800 (PST)
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 X9eDYxmmeY_x for <tls@ietfa.amsl.com>; Sun, 7 Feb 2021 12:37:32 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 E03C93A12E4 for <tls@ietf.org>; Sun, 7 Feb 2021 12:37:31 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id f8so4608300ljk.3 for <tls@ietf.org>; Sun, 07 Feb 2021 12:37:31 -0800 (PST)
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=PHS2j1qTYKqIYQuUDzUP6lrOmEyv4jyUDRZ6E0R8m4k=; b=qYFtqsYujkrcFs4WdC/e3R8g8OLc4BIkgT2lrLX4UTVYFschRTpnbfCTuHnm74bPB/ SYmE+6lcGuWHAZu+GsQWRNQFGTJbxwOTXAzovlSLbC+2sYm94f8OEeJ7v+pDb450UoZ4 oeqXhtB6V83Ph3cHMuchK9kG6mBUDUm8xQj29m0jvyivYJDHbqnrLkDnPXMYtG+MAGHj nh3Mi+j+1ZUP1gs+fWwrTT5q4ri4RnP0j11XhOMOPD7I17EmyEFik9oPipIS/7g2cBeJ 8Eu5DDmgl5aY5oDq5DySO/cPrxSux3SHweoU8TUCimCCwv3qzHxXa5OCc0QxEfbf31li 50Bg==
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=PHS2j1qTYKqIYQuUDzUP6lrOmEyv4jyUDRZ6E0R8m4k=; b=M5oVn1eAtOi2zccKv9Oa/R6b3hoHiRGefr7oAISRALDpG5URaZ2w2ysBfWBtTCkUlu /6HugjrsgR8jZfRjHgdbOpaPjaQuQ3A0UtN1q+FDJhJDb0iYaPoiCWh58cqxJ2Nptlde 0JKEb5Uk32F1s3UiiesbGNekc5zbtA9fymxMQ+vd2pRKOTsW/VFPxbnnn5Y+rG5VxjmY fQW6Je1lwmaXI1Cm7aWU/xbvAKFhdClHQf4pPDkbALcdw8rGIPtHRwfZSGxbCBWuqCrS oarIKWY6dCt4+qBlwMkVNkCzmPI+h5G8yiB6fAz3n0P8qRm/fJwckx5M0X/LaT4mmuDp UiRA==
X-Gm-Message-State: AOAM530zf5jL4YZJoEuY6isALZrNZ+0fHoM713ZTx461p8iJfNiux56p itmB8Gafu8ktj/caDieuXeRiY03XD5kyCQPdKIq5383pkXuhe+BE
X-Google-Smtp-Source: ABdhPJwwHGNysQF98WSmtGZQcpj2ChMBTfbdPufAGkXZcxc+Cv/9q//yhIeDMi7FDsT4PxeH1m2qruaeu732RogVqbA=
X-Received: by 2002:a2e:7f04:: with SMTP id a4mr8533452ljd.3.1612730250060; Sun, 07 Feb 2021 12:37:30 -0800 (PST)
MIME-Version: 1.0
References: <20201113235134.GW39170@kduck.mit.edu> <CABcZeBMZR5hCpqBJFsdwMqYWn8fnR=2Ujxw4Y3Rt16MWeSJqsw@mail.gmail.com> <20210206011618.GM21@kduck.mit.edu>
In-Reply-To: <20210206011618.GM21@kduck.mit.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 7 Feb 2021 12:36:53 -0800
Message-ID: <CABcZeBNSOmAntPbwFDK3rc4kzjJ-d9754D=A7wjj5LCQskSM=A@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-tls-dtls13.all@ietf.org, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ac7c7a05bac50546"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5qSHnpcmDt6lbYhLz0XgKei4kvc>
Subject: Re: [TLS] AD Evaluation of draft-ietf-tls-dtls13-39
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Feb 2021 20:37:35 -0000

On Fri, Feb 5, 2021 at 5:16 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> Hi Ekr,
>
> Thanks for all the updates, and sorry to have dropped the ball over the
> holidays.
>
> The changes in the -40 are basically all good, and I filed several PRs to
> cover a few nits and places where you asked for suggested text.  (I see you
> merged most of them already; thanks!)  For everybody not getting
> notifications for the githb repo, those are:
>
> https://github.com/tlswg/dtls13-spec/pull/208 (general nits)
> https://github.com/tlswg/dtls13-spec/pull/209 (implementation pitfalls)
> https://github.com/tlswg/dtls13-spec/pull/210 (anti-replay window per
> epoch)
> https://github.com/tlswg/dtls13-spec/pull/211 (implicit ACK)
> https://github.com/tlswg/dtls13-spec/pull/212 (more security
> considerations)
>

Thanks. I have merged these.

The only other comment I had on the -40 that I didn't make a PR for is that
> (now that we have the automation working to generate appendixes for the
> procotol-description language) we don't actually show the new value for ACK
> as a ContentType anywhere!  It seems like we'd have to stick that in Figure
> 2 if we put it anywhere, though that's admittedly a bit disjointed from
> where we actually start talking about the message in question.
>

Yeah, I think we can take a pass on this, but if someone has a clever idea,
I'll
take a PR.

>
> > > Section 4.5.3
> > >
> > > As mentioned above, we might mention any reduced limits due to
> > > sequence-number protection (e.g., with ChaCha20) here, if they exist.
> >
> > Filed an issue:
> > https://github.com/tlswg/dtls13-spec/issues/167
>
> It looks like we were maybe going to add a note saying that we don't know
> the confidentiality bounds for multiple applications of RNE, but I don't
> think we necessarily need to hold up for that.
>

MT and I discussed this and came to the conclusion it was OK because the
nonce is 128-bits long and the bounds are much lower.

https://github.com/tlswg/dtls13-spec/issues/167


> > > (I note that a bit further on we say
> > > "MUST create a new ClientHello ... [following] Section 4.1.2 of
> > > [TLS13]", which seems to be enough of a normative requirement that the
> > > "MUST" may not be needed here.)
> > >
> > >    The cookie extension is defined in Section 4.2.2 of [TLS13].  When
> > >
> > > Do we want to add any discussion of what is stored in the cookie (other
> > > than the RFC 2522-like address+ports and the ClientHello1 hash that
> > > [TLS13] mentions), as mentioned in the thread at
> > > https://mailarchive.ietf.org/arch/msg/tls/QbteFvnk1H2K9OjfHGosuG9e9Rk/
> ?
> > > I am somewhat amenable to the stance that it's more appropriately done
> > > in 8446bis.
> >
> > Yes, I think so.
> > https://github.com/tlswg/tls13-spec/issues/1206
>
> This is still open (on 8446bis), but maybe my
> https://github.com/tlswg/dtls13-spec/pull/212 covers some of the key
> points for this document.
>

I think it does.


> > > Section 5.3
> > >
> > > [Discussing ServerHello here for want of a better location.]
> > >
> > > We specify a ClientHello.legacy_version = {254,253}, but we seem to be
> > > inheriting the unmodified TLS 1.3 ServerHello, complete with
> > > ServerHello.legacy_version = 0x0303.  That seems problematic, since the
> > > legacy DTLS 1.2 ServerHello would use the expected {254,253} like the
> > > ClientHello.
> >
> > https://github.com/tlswg/dtls13-spec/issues/170
> >
> >
> > > Similarly, we should probably specify whether the sentinel
> > > downgrade-protection Random values are used as-is from TLS 1.3, or if
> we
> > > have new ones for DTLS.
> > > [end ServerHello topics]
> >
> > I don't think we need new ones. Don't we just inherit it?
>
> I think inheriting the same ones should work, protocol-wise.
> I was only asking about mentioning them specifically sinnce their stated
> semantics are tied to "if negotiating TLS 1.2" and "if negotiating TLS 1.1
> or below", and a literal reading of those requirements doesn't make sense
> for DTLS versions.
>

https://github.com/tlswg/dtls13-spec/pull/213

> I don't think I understand you. This is a lockstep protocol so if you
> > are sending the next flight, then the previous flight must have
> > been received. In the post-handshake, you can run concurrent
> > state machines.
>
> This was just an editorial comment, that the parenthetical "emptying the
> buffer first" seems pretty vague about what is supposed to happen (and if
> the buffer that's getting emptied is the same one used for "buffers them
> for transmission").  My understanding of what's supposed to happen in
> practice matches my understanding of your description here.
>

I changed it to "transmission buffer"

>
> > > The wording here is a bit amusing, as "up to no less than the ...
> > > maximum" is facially nonsensical, but the RFC 6298 setting is in fact
> > > the floor for the implementation-defined maximum.  I don't have a
> clever
> > > wording suggestion, though.
> >
> > Hmm.... I don't think it's nonsensical, because we're not bound
> > by 6298, so that's just explaining where 60s comes from. How
> > about:
> >
> >      and double
> >      the value at each retransmission, up to no less than 60 seconds
> >      (the maximum defined in RFC 6298)
> >
> > How does that sound?
>
> That reads better to me, but it's totally editorial (so, your call).
>

Done.


> > >       encrypted.  This may improve correlation of packets from a single
> > >       connection across different network paths.
> > >
> > > I feel like the small width of the epoch field mitigates this somewhat
> > > (though not fully).
> >
> > Sure.
> >
> >
> > > Section 12.  Changes to DTLS 1.2
> > >
> > > This section is about changes *since* DTLS 1.2 (and I propose some
> > > wording tweaks in my editorial PR).  But I think we should also
> consider
> > > whether we do need a section on "changes to DTLS 1.2", or rather
> > > "changes affecting DTLS 1.2 implementations, along the lines of
> > > https://tools.ietf.org/html/rfc8446#section-1.3 ("Updates Affecting
> TLS
> > > 1.2").
> >
> > Do you have some proposed contents?
>
> Having not actually implemented it, not really :)
>
> But skimming through, it seems like maybe
>
> - the AEAD limits might be worth using for TLS 1.2 as well
>

We didn't do this in 1.3 I don't believe, so I would not do it here either.


- you have to do the downgrade protection HRR random values
>

- [the things that TLS 1.3 changed in TLS 1.2 probably also apply
>

https://github.com/tlswg/dtls13-spec/pull/214

-Ekr