Re: [TLS] Application layer interactions and API guidance

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 12 October 2016 18:03 UTC

Return-Path: <ilariliusvaara@welho.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 BB9E4129521 for <tls@ietfa.amsl.com>; Wed, 12 Oct 2016 11:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] 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 ys2WoChpua8Y for <tls@ietfa.amsl.com>; Wed, 12 Oct 2016 11:03:46 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id DE96D12950C for <tls@ietf.org>; Wed, 12 Oct 2016 11:03:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 6ED3413D33; Wed, 12 Oct 2016 21:03:44 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id OjMhzapkYr1r; Wed, 12 Oct 2016 21:03:44 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EF1C02310; Wed, 12 Oct 2016 21:03:43 +0300 (EEST)
Date: Wed, 12 Oct 2016 21:03:37 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Kyle Rose <krose@krose.org>
Message-ID: <20161012180337.GA21390@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CACdeXiK1Wdnd2UaUdPJ6sL-LSW8oQbWyetUJ+3bUQEZY45ax5w@mail.gmail.com> <CAF8qwaDQqceewkg5XoN+8iiHtNO=J9YHH_aRS5+k_4fKTJvfeA@mail.gmail.com> <CACsn0ckz72rhSCQTYRvmWB6n_tdvB5E-V7ssV6qjGO6=qsXY+w@mail.gmail.com> <CAJU8_nWttdcOX=wHOqouZEpFyP3Tok0xTDCzvMrBunkSW9kO+w@mail.gmail.com> <CABkgnnV6YY_GEFKe2C+k67RcJjoPBJoWx1Crat_TMkvB8E-r_Q@mail.gmail.com> <CAJU8_nWtf1sgZ5jQs6zyjU5CotXq42WiYRFpMVU0qbvyy-pGFA@mail.gmail.com> <20161012081145.GA16436@LK-Perkele-V2.elisa-laajakaista.fi> <CAJU8_nWRRyCERorZeMwqXUHsEk2PNWjfD+m1jg0tA=ULV0e2Kg@mail.gmail.com> <20161012170237.GB21085@LK-Perkele-V2.elisa-laajakaista.fi> <CAJU8_nULQnCwcFFo6o-ZH9yc2QVYZ5yTC2Y-SikRs5pJqG7Vaw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAJU8_nULQnCwcFFo6o-ZH9yc2QVYZ5yTC2Y-SikRs5pJqG7Vaw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/i5AeWqD_b8l8pe1MIItwoqaR7yY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Application layer interactions and API guidance
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, 12 Oct 2016 18:03:50 -0000

On Wed, Oct 12, 2016 at 01:51:25PM -0400, Kyle Rose wrote:
> On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> 
> > > By this point in the connection, there is proof that early_data has not
> > > been replayed. The application doesn't necessarily know this when the
> > early
> > > data is first delivered, but it can find out later, which may be all that
> > > some applications want. Clearly not all, as you point out:
> >
> > This is actually only useful if the application can cancel out effects
> > of 0-RTT if handshake fails... Which tends to be fraught with peril to
> > implement.
> >
> 
> Absolutely, but it doesn't seem like it would be any more perilous than the
> danger of accepting 0-RTT data in the first place: at worst you process the
> same replayed data, and at best you process less replayed data. (Unless
> there's a perverse incentive problem created by providing a half-measure.)

If all 0-RTT data is idempotent (including after replay delay!), sure.

However, if it isn't idempotent, you could get issues...
 
> > The 0-RTT data is not part of ClientHello. It is sent in streaming
> > manner (with handshake blocking if it hans't been completely sent by
> > the time ServerFinished is received.
> >
> > ClientFinished does _not_ MAC 0-RTT data, even in case of successful
> > transport.
> >
> 
> There's my confusion. I misinterpreted both the Zero-RTT diagram and the
> table of handshake contexts under "Authentication Messages", specifically
> "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm
> guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is
> accepted, is the second Finished message from the client ("{Finished}") the
> same message encrypted differently (using the handshake traffic secret)?

No, there is no difference in ClientFinished in case of 0-RTT accept or
reject (other than the contents of the CH and EE hashed in).
 
> Is there a succinct explanation for the design choices around what is and
> is not included in the handshake context? Being spread out over a year and
> a half of mailing list messages makes it hard to track. :-) I'm concerned
> that an on-path adversary that can slice-and-dice connections along MAC
> context lines will be able to create mischief, so I'd like to be able to
> convince myself that this isn't the case.

The thing that protects the 0-RTT data from substitution is the record
protection MACs that are made using key derived from the PSK secret. So
if the PSK secret is unknown, the key for 0-RTT can't be derived, and
as consequence, 0-RTT data can't be altered (there's end-of-data marker
too, preventing truncation).

And basically, ServerFinished MAC covers everything up to that point,
and ClientFinished MAC covers the entiere handshake (0-RTT data not
included).

> And also, receiving 1-RTT data does not imply that the 0-RTT data
> > itself was not replayed (just that any replay it is of didn't
> > complete, assuming PSK keys are secret).
> >
> 
> Yeah, I get that now. It seems like a missed opportunity to detect mischief
> after the fact, and could make for some interesting vulnerabilities for
> stateful protocols. E.g., if your early data is "cd /tmp" and your 1-RTT
> data is "rm -rf *", but the adversary is able to swap out the early data
> for a replayed "cd ~". That one is probably too obvious of an example to
> happen in real life, but imagine some developer who maintains his or her
> own tlstunnel hearing about 0-RTT and implementing early data for arbitrary
> applications using that tunnel wrapper because "reduced latency!": if early
> data were later authenticated, it would limit the scope of vulnerability to
> only those things that could fit in that first flight. But because it can't
> catch every possible replay-based attack, maybe such a measure would
> provide only a false sense of security. Sigh. I have no desire to re-ignite
> arguments from a year ago.
 
You can't swap out 0-RTT data (without PSK keys). One can only create
new connection attempts (that fail!) with the same 0-RTT data (and the
same ClientHello) before or after the real connection (if any, it
could be supressed, in which case you would get only failed handshakes
with 0-RTT data).


-Ilari