Re: [TLS] DTLS 1.3
Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 06 July 2016 19:26 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 CB98512D5C9 for <tls@ietfa.amsl.com>; Wed, 6 Jul 2016 12:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level:
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no
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 lTzEFBuSuFGe for <tls@ietfa.amsl.com>; Wed, 6 Jul 2016 12:26:07 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9268F12D5D2 for <tls@ietf.org>; Wed, 6 Jul 2016 12:25:21 -0700 (PDT)
Received: from [192.168.10.131] ([80.92.121.176]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lg5kl-1bf5uR49Vr-00pdoj; Wed, 06 Jul 2016 21:25:17 +0200
To: Ilari Liusvaara <ilariliusvaara@welho.com>, tls@ietf.org
References: <577A38A2.2090209@gmx.net> <20160704140312.GC4287@LK-Perkele-V2.elisa-laajakaista.fi> <577ABCE2.9050409@gmx.net> <20160704204603.GA4837@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBMYQ=SWfEwFVjpmO3Pzh78VTrdqXKF26TDnSA-nR-k=rQ@mail.gmail.com> <20160704211805.GC4837@LK-Perkele-V2.elisa-laajakaista.fi> <577CFABF.4020502@gmx.net> <20160706144708.GA28022@LK-Perkele-V2.elisa-laajakaista.fi>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <577D5B1B.1030609@gmx.net>
Date: Wed, 06 Jul 2016 21:25:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <20160706144708.GA28022@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="3tWAPXq5HgqH8DBSnasVMFXcL93i7fDqu"
X-Provags-ID: V03:K0:W+8ckchNhMW4J30HCquchrBI3sRJdqC6dZMSfgkirZwNfNyQ7Ud WmaSvjyeS5Kugek32/j464XOW3nVujgzkGwDuRSFsKsMRoeQXTI9gvGahWzhVG9muiIweW2 2cnmmg5+2A1mtDGpGTn3EQVoI2koCWaQKu132+2g+kf+A5U5rJ5kz6nd/LFVOfhXO2ZGl6L hXl19hpeeAy17ZtFlSZGg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:lZYKklt2JQE=:yRSupFNXrIOBQO1kyUbtDy Jj/0plzk2rtlGBh5Tz/ejG7LbewuwU/pU2kKVK9f3N/9Vnh2Yb4eCnh32xYhr4tkYHu7pxnCp DcPNrGBwtkVmp+rO7CQUeO3EMr/l5XrYsf17yfqoja9JsAwC0DPw8yuB4z2weQN31/DrntFi6 KJ9buBoiZF4GFFVC/hSbYxUrjwTxHvjhYPh40SSviVZAYATIl0HDmg8jp5Ad0V2PXonPx+B3j 7c8oAeG9qgyiANRFlncunKoTDSps4dC+lnPgM1q6ZsgdkulLPWWFEXifKXeDubkc5k6jw33xz tlKc3Zh7Y8SVNnaEM7Iuir7tflQBY18aJlfMmse+6IVr0gb4sbN+bCPdE1aHUHocTAeOvsMBY eCchBr045FvRW9d7EdduWEx8ERzDeNPfuPa2U4vFqvjDb7vOzqqfEjDrkUdDh7bVEP0mjly8b 0NA9v/uZbZ9lYv5cOITOAmFgKmzJms1Slk40EmXRE+PfJNW/TAIDVeeOu5M8RGniepAViFIbZ Fe9tIXCNMRm9wiwf0I0TazfpSpqAC7SqPFbelEFuQhNCGypC96tH4K4uQaKVrDqnKepY9r6Fg bP4sPkQk4egO796olJRb1f0FN0lZaJbIEqdYGGJXUs7UoCLIAoJ2qBXagAi0yTwg8y6JjIQJv GnBQuP2QIvyNTLUAA0N/bXm7C6hdQCZ4+FsT7/9vKp6sE0mtTroAUaHv+OOXxtHYx/tG1YMIO 7ZwYvBNtlvNRWASa8pfVjo4GIDtsnH8coq7bUR+ompPmKO7JSYSMDw/J+Ms=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XeRpMzynwmq-1vBdpAyVqRY9z1Y>
Subject: Re: [TLS] DTLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 06 Jul 2016 19:26:10 -0000
Hi Ilari, a few remarks inline: On 07/06/2016 04:47 PM, Ilari Liusvaara wrote: > On Wed, Jul 06, 2016 at 02:34:07PM +0200, Hannes Tschofenig wrote: >> >> I was wondering about one design decision regarding the ack. >> >> If we don't use the epoch instead of the KeyUpdate then there is only >> one other message that does not have an ack, namely the NewSessionTicket >> message. (I might be worthwhile to think about why the server can send >> it at any time and why it isn't sent as part of the regular handshake >> instead. This would make the issue with acks potentially go away.) > > Being part of regular handshake is problematic, since those are assumed > to be tickets, and as such one needs the dynamic PSK key. But the dynamic > PSK key includes the entiere handshake up to Client Finished. And this > can't really be changed (or things start going badly wrong). > > So the minimum time to send some tickets is 4th flight, whereas normal > handshake is only 3 flights. Was just an idea. The TLS 1.2 ticket mechanism was also transmitted during the handshake. > >> The post-handshake authentication with the CertificateRequest comes with >> an ack (even though it may be delayed), namely Certificate, >> CertificateVerify, and Finished (and in case of a decline with a >> certificate and a finished). Would it be worthwhile to ack them as well >> due to the potential delay caused by user interaction? >> >> Let us say that we provide an ack for the NewSessionTicket message then >> it is sufficient to specify a very simple ack, namely one that is >> defined as: struct {} Ack; >> >> If we also ack the post-handshake authentication then it is necessary to >> include some identifier in the Ack message to indicate which message is >> acked. > > Certificate requests have context identifiers... I was more thinking about including the HandshakeType to distinguish the ack for a NewSessionTicket from an ack to a CertificateRequest. > >> I believe that using epoch for updating the cryptographic keys is pretty >> much like a key update. Essentially, we are talking about taking the >> epoch value from the incoming packet and then figuring out what security >> context is applicable. Correct? > > Yeah. > >> An alternative design would be to require the receiver of a KeyUpdate to >> return a KeyUpdate as well. This would then constitute a flight. >> Wouldn't this be better? > > I don't think this works, because KeyUpdate is not idempotent (causes > problems if reply is lost) and worse yet, because of potential desyncs > with the main data flow (IP packet reordering!). Maybe it should be made idempotent... > >>> How many special epochs we need? >>> >>> 0 => Unencrypted messages >>> 1 => 0-RTT control messages (just one finished[1]!) >>> 2 => 0-RTT data messages >>> 3 => primary handshake >>> 4 => application data >>> 5-N => rekey connection >> >> I guess you want to introduce these different epoch values and associate >> them with different phases during the handshake since the TLS 1.3 key >> derivation is more sophisticated than the TLS 1.2 version. >> >> Is this correct? > > Each listed one essentially corresponds to one key connection can use: > > - Unencrypted (CH/SH/HRR) > - 0-RTT handshake key (Finished) > - 0-RTT data key (0-RTT appdata) > - Handshake key (Encrypted Extensions to Client Finished) > - Application key from initial traffic_secret_0. > - Application key from traffic_secret_N (N>0). > Thanks. Makes sense. Ciao Hannes > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Fossati, Thomas (Nokia - GB)
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Fossati, Thomas (Nokia - GB)
- Re: [TLS] DTLS 1.3 Fossati, Thomas (Nokia - GB)
- Re: [TLS] DTLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] DTLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] DTLS 1.3 Fossati, Thomas (Nokia - GB)
- Re: [TLS] DTLS 1.3 Stephen Farrell
- Re: [TLS] DTLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] DTLS 1.3 Stephen Farrell
- Re: [TLS] DTLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Hannes Tschofenig
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Stephen Farrell
- Re: [TLS] DTLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] DTLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Hannes Tschofenig
- Re: [TLS] DTLS 1.3 Hannes Tschofenig
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Hannes Tschofenig
- Re: [TLS] DTLS 1.3 Stephen Farrell
- Re: [TLS] DTLS 1.3 Eric Rescorla
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] DTLS 1.3 Hannes Tschofenig
- Re: [TLS] DTLS 1.3 Ilari Liusvaara
- Re: [TLS] DTLS 1.3 Eric Rescorla
- [TLS] DTLS 1.3 Hannes Tschofenig
- Re: [TLS] DTLS 1.3 Hannes Tschofenig
- Re: [TLS] DTLS 1.3 Mike Copley
- Re: [TLS] DTLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] DTLS 1.3 Fossati, Thomas (Nokia - GB)