IETF Logo Mail Archive

Re: [TLS] Application layer interactions and API guidance

Kyle Rose <krose@krose.org> Mon, 10 October 2016 20:57 UTC

Return-Path: <krose@krose.org>
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 595EB129759 for <tls@ietfa.amsl.com>; Mon, 10 Oct 2016 13:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 HLXqKOgGspcm for <tls@ietfa.amsl.com>; Mon, 10 Oct 2016 13:57:29 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 AF9251293FE for <tls@ietf.org>; Mon, 10 Oct 2016 13:57:29 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id f128so2887522qkb.1 for <tls@ietf.org>; Mon, 10 Oct 2016 13:57:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pR61lUv5utyj0zsXuBtDYASbFQQ5ekFVdh1d+MKj1YY=; b=YIVjWf3OMbG8aybXjdbxIWbp0/JqHkHLOzkGurVaFoITJ6ER65IrhgYZTDEw8Ms7ls qkFs23HgQRbnShnToiycJvHTxCHGqNMFoMDQolmOGEikwZq0NtsrRoMmps68s0gvjZaP Grmpo6FwXq+uR0DgfB/MqjrujySJLG/XhUpS0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pR61lUv5utyj0zsXuBtDYASbFQQ5ekFVdh1d+MKj1YY=; b=amYErllJHYpQ/R9QTYZgSSc2wPC0iZbMKg76ifmjgrlVDrqDPn/LipHjAFkdC/s0H8 gnII6xKou14gHRuK1m0jzcu897O85iO2AfcQVibxsUoDy02OlcnloUVZrUESa0VgE1YY JJj/VB985ZB6aYFpHq2K2rJ/Ti1016PlYLQ+3PicOysh2V9mRGepxrq1dMXzplymKhWa 6b8bPQlfSLivkNDVKS+Q7DFCrB/Iisv3viCJp+Sj8lZWRckFwlqkH8kcGDvjjNcBO9Zg UyGn/KW38jKsU5Oi+SRFDsrut/jfK9GC6d4mLg/pWgc4XjfSTQNTb/eYjGjp0Ela91xA WZPw==
X-Gm-Message-State: AA6/9RngTtIWrCwulZJ3r2fj8JFd2M2AU7jO3m3+HJhbnw9QgiQLqesYMa0r9kBW3CPnyNRBm26jqbeEvY+HEw==
X-Received: by 10.55.19.36 with SMTP id d36mr137685qkh.247.1476133048698; Mon, 10 Oct 2016 13:57:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.45.68 with HTTP; Mon, 10 Oct 2016 13:57:27 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: <CACsn0ckz72rhSCQTYRvmWB6n_tdvB5E-V7ssV6qjGO6=qsXY+w@mail.gmail.com>
References: <CACsn0c=B0dVGaXKawW5DJCUfJfqFFHkk_cZCzjzKs53n4UKLpg@mail.gmail.com> <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <CACsn0cnpEq_00R37WZOm39dg9dXKSkpNjGt3FWg0uLgTEkwtRw@mail.gmail.com> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNU0HVqkZm6zb63xZzf4+ZQjXb8CacuYH77Fe_=dfFPhw@mail.gmail.com> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> <CACdeXiK1Wdnd2UaUdPJ6sL-LSW8oQbWyetUJ+3bUQEZY45ax5w@mail.gmail.com> <CAF8qwaDQqceewkg5XoN+8iiHtNO=J9YHH_aRS5+k_4fKTJvfeA@mail.gmail.com> <CACsn0ckz72rhSCQTYRvmWB6n_tdvB5E-V7ssV6qjGO6=qsXY+w@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Mon, 10 Oct 2016 13:57:27 -0700
Message-ID: <CAJU8_nWttdcOX=wHOqouZEpFyP3Tok0xTDCzvMrBunkSW9kO+w@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="001a113ffee6027c54053e89022c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-jp1S88VyQKALWAi4cwJT7TC6XA>
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: Mon, 10 Oct 2016 20:57:32 -0000

On Mon, Oct 10, 2016 at 1:49 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

>
> The problem is with poorly-behaved senders and attackers resending
> 0-RTT data. Receivers should be able to ensure side-effectfull
> operations are not carried out by 0-RTT data. Making 0-RTT silent in
> APIs transforms an interoperability issue into a silent security
> issue. This is not a good idea.
>

+1.

FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin
that the web is substantially broken without retry logic in the browsers,
that naturally make application-level replay mitigation a necessity. But I
don't think (nor do I think he claimed) that the same is true of all
protocols or systems that might use TLS. So while 0-RTT-obliviousness may
be okay for browsers in particular given the other constraints under which
they operate, it is probably not good to bake that into the API for the
general case.

Kyle

v2.23.0 | Report a Bug | By Email