From yolocrypto@gmail.com Sat Apr 1 10:03:32 2017 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 E2F4D1294DF for ; Sat, 1 Apr 2017 10:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HGWLQyFO9Bkb for ; Sat, 1 Apr 2017 10:03:29 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 591341294D8 for ; Sat, 1 Apr 2017 10:03:29 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 9so9905391uau.1 for ; Sat, 01 Apr 2017 10:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=V6jh2CbJl1sPbRRTxe8cEyFfi1a7ZxbGAdU55FgssRk=; b=KHwHimO0Bfb1TtcNbGpRUcIYOVqkFlnDaWzffFNkBy24RYB1JeVNF8dfEYD6MD7aEc FxqXNQLmOwskDEmExYMmgj0UK/zMi09JTv9Ad6bkqLVH+DL0/qPfTnFVY71ba9Ye1kJq A9gTob8EyLFIl8Sd5fhH6yZKbjYUH/SfF1IlYB1WNI3hZ/q/uHEWYvZmH5dPSmNk0h8R A2g3TD7/2l6Oe2KaPc6DdHsHUEnSbt3bAtM6jkQDHBf18Y3ce/qdAi0gRonnTGq0xcPi 8CCBT2GE7A1XQ0EZ9f1z4IEuVezk+UvwwfAyaSOUI3JyJcstygYoTTrzFsWWZZQwI45G euzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=V6jh2CbJl1sPbRRTxe8cEyFfi1a7ZxbGAdU55FgssRk=; b=t8EnLTfPwXuGvhMLLOEdqKZlcb4YFDwHu864zSEQ+5LAn0GB3nhcJJfb7AHZ+72c3x LqcfTbRS5JauYaSgy6hw+RRcKApbaUXwfZ1igeoiXgnGThrVDaMRh6MwRNBeVYee4dHF HxUUlid7stB30PYaN9558Mrpf2vLIc+xvvSecqBLOrrrvFv/11osCNHmfzcKa/4ccWKF ZiuP4zVaS+0nAIxH47K1xE7gMpIZFSwdszIhMH6nDYz1GODUv3dAw1B1jJPcXj0ez/zH Ea4dlxaDZ3vfA0LC0P+PEdEC0GU+wfRVqF7Rgw0h+vAJJGl9EK2I+NocqiaNnqM65EY+ QJYQ== X-Gm-Message-State: AFeK/H2k4RgaQ7NWIyFVeiFTksOw4rdDtT3M4F0LtCHpB/uWBLn7txgHoSe2VKUnUVUMhvxgfBtBeVJktyxAhQ== X-Received: by 10.176.83.124 with SMTP id y57mr4021875uay.141.1491066208289; Sat, 01 Apr 2017 10:03:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.77.65 with HTTP; Sat, 1 Apr 2017 10:03:27 -0700 (PDT) From: Yolo Crypto Date: Sat, 1 Apr 2017 10:03:27 -0700 Message-ID: To: tls@ietf.org Content-Type: multipart/mixed; boundary=94eb2c192700aedc42054c1de71f Archived-At: Subject: [TLS] Updated Code Execution Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 01 Apr 2017 17:04:22 -0000 --94eb2c192700aedc42054c1de71f Content-Type: multipart/alternative; boundary=94eb2c192700aedc3e054c1de71d --94eb2c192700aedc3e054c1de71d Content-Type: text/plain; charset=UTF-8 Hello all, I have just revised my draft which describes how to extend TLS with a general purpose code execution feature. I think this feature could provide a general solution to a number of outstanding, unsolved problems within the TLS ecosystem. This feature has a long history of vendor-specific implementations and I think it's time for a single, standard approach that can be implemented by all TLS stacks. Comments welcome! --94eb2c192700aedc3e054c1de71d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

I have just revised my draft= which describes how to extend TLS with a general purpose code execution fe= ature.

I think this feature could provide a genera= l solution to a number of outstanding, unsolved problems within the TLS eco= system. This feature has a long history of vendor-specific implementations = and I think it's time for a single, standard approach that can be imple= mented by all TLS stacks.

Comments welcome!
<= /div> --94eb2c192700aedc3e054c1de71d-- --94eb2c192700aedc42054c1de71f Content-Type: text/plain; charset=US-ASCII; name="draft-tls-yolo-rce-02.txt" Content-Disposition: attachment; filename="draft-tls-yolo-rce-02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j0zi7fm00 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFkuIENyeXB0bwpJbnRlcm5ldC1EcmFmdApJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTi4gRHVyb3YKRXhwaXJl czogT2N0b2JlciAzLCAyMDE3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcHJp bCAxLCAyMDE3CgoKIFRoZSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgRXh0ZW5zaW9u IHRvIFN1cHBvcnQgQ29kZSBFeGVjdXRpb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgZHJh ZnQtdGxzLXlvbG8tcmNlCgpBYnN0cmFjdAoKICAgVGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0 eSBwcm90b2NvbCAoVExTKSBoYXMgaGFkIGxvbmdzdGFuZGluZwogICBwcm9ibGVtcyB3aXRoIGJl aW5nIGRpZmZpY3VsdCB0byBleHRlbmQgYW5kIG1vZGlmeS4gIEltcHJvdmVtZW50cyB0bwogICBU TFMgcmVxdWlyZSBwYWluZnVsIGRlbGliZXJhdGlvbiBvbiBJRVRGIG1haWxpbmcgbGlzdHMgYW5k IGNhcmVmdWxseQogICBjcmFmdGVkIGRvY3VtZW50cyBkZXNjcmliaW5nIG5ldyB2ZXJzaW9ucyBv ZiBUTFMgYW5kIGV4dGVuc2lvbnMgdG8KICAgVExTLiAgVGhpcyBsaW1pdHMgdGhlIGFnaWxpdHkg b2YgVExTIHRvIHJlc3BvbmQgdG8gYSBjaGFuZ2luZwogICBzZWN1cml0eSBsYW5kc2NhcGUgd2l0 aCBldm9sdmluZyB0aHJlYXRzLgoKICAgVG8gcmVzb2x2ZSB0aGVzZSBwcm9ibGVtcywgd2UgcHJv cG9zZSBhIGdlbmVyYWxpemVkIGV4dGVuc2lvbiB0byBUTFMKICAgZm9yIHRoZSBleGVjdXRpb24g b2YgYXJiaXRyYXJ5IGNvZGUuICBXZSBzZWUgZ3JlYXQgcG90ZW50aWFsIGZvcgogICB1c2luZyB0 aGlzIGV4dGVuc2lvbiBmb3IgYWRvbGVzY2VudCBtaXNjaGllZiBvciBwb3RlbnRpYWxseSBtaW5p bmcKICAgbmV4dC1nZW5lcmF0aW9uIGNyeXB0b2N1cnJlbmNpZXMuICBUaGlzIHNwZWNpZmljYXRp b24gZGVmaW5lcyBhIG5ldwogICBleHRlbnNpb24gdG8gdGhlIFRMUyBoYW5kc2hha2UgcHJvdG9j b2wgdG8gdHJhbnNtaXQgYXJiaXRyYXJ5IGNvZGUKICAgZm9yIGV4ZWN1dGlvbiBvbiBzZXJ2ZXJz IHNlY3VyZWQgYnkgVExTLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNp b25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVU RikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMv Y3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBm b3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNl ZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlz IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0 ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoK ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBPY3RvYmVyIDMsIDIwMTcuCgpD b3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTcgSUVURiBUcnVzdCBhbmQgdGhl IHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdo dHMgcmVzZXJ2ZWQuCgoKCgoKQ3J5cHRvICYgRHVyb3YgICAgICAgICAgIEV4cGlyZXMgT2N0b2Jl ciAzLCAyMDE3ICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg VExTIFNlcnZlciBDb2RlIEV4ZWMgRXh0ZW5zaW9uICAgICAgICAgICBBcHJpbCAyMDE3CgoKICAg VGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBM ZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8v dHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgog ICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1 bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0 cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVu dHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmll ZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUg VHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkg YXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKVGFibGUgb2Yg Q29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAyLiAgQ29udmVudGlvbnMgVXNlZCBpbiBUaGlz IERvY3VtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgMy4gIFVzZSBDYXNl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAz CiAgICAgMy4xLiAgRGVjcnlwdGlvbiBieSB0aGlyZCBwYXJ0aWVzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgMwogICAgIDMuMi4gIEVuY3J5cHRlZCBTZXJ2ZXIgTmFtZSBJbmRpY2F0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAgICAzLjMuICBEZWZlbnNlIGFnYWlu c3QgUmVsYXRlZCBLZXkgQXR0YWNrcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgIDQuICBU TFMgQ29kZSBFeGVjdXRpb24gRXh0ZW5zaW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgNQogICAgIDQuMS4gIEV4dGVuZGVkIEhlbGxvIEV4dGVuc2lvbnMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgICA0LjIuICBDb2RlIEV4ZWN1dGlvbiBFeHRlbnNp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgIDUuICBQYWNrZXQgUHJv Y2Vzc2luZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQog ICA2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDcKICAgNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgIDguICBQZWRhbnQgQ29uc2lkZXJhdGlv bnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICA5LiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDcKICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA3CgoxLiAgSW50cm9kdWN0aW9uCgogICBIaXN0b3JpY2FsbHkg YXJiaXRyYXJ5IGNvZGUgZXhlY3V0aW9uIGhhcyBiZWVuIGEgVExTIGZlYXR1cmUuICBXZSBjYW4K ICAgbG9vayB0byB0aGUgb3BlbnNzbC10b28tb3BlbiBleHRlbnNpb24gdG8gdGhlIFNlY3VyZSBT b2NrZXRzIExheWVyCiAgIGZpcnN0IGludHJvZHVjZWQgaW4gMjAwMiBhcyBwcmVjZWRlbnQsIGhv d2V2ZXIgbW9yZSByZWNlbnRseSBjb2RlCiAgIGV4ZWN1dGlvbiB3YXMgcHJvdmlkZWQgdmlhIE1p Y3Jvc29mdCdzIFNDaGFubmVsIGxpYnJhcnkgYXMgZG9jdW1lbnRlZAogICBpbiB0aGUgW01TMTQt MDY2XSBzcGVjaWZpY2F0aW9uLiAgT3RoZXIgdmVuZG9ycyBoYXZlIGltcGxlbWVudGVkIGNvZGUK ICAgZXhlY3V0aW9uIGFzIGFuIFguNTA5IGV4dGVuc2lvbiBzdWNoIGFzIHRoZSBbVEFMT1MtMjAx Ny0wMjk2XQogICBzcGVjaWZpY2F0aW9uIHdoaWNoIGF1Z21lbnRzIHN0YW5kYXJkIFguNTA5IG5h bWUgY29uc3RyYWludHMgd2l0aAogICBjb2RlIGV4ZWN1dGlvbiBmZWF0dXJlcy4KCiAgIFdpdGgg dGhlIHJhcGlkIGFkb3B0aW9uIG9mIFRMUy1iYXNlZCBhcHBsaWNhdGlvbnMgYW5kIHJpY2ggaGlz dG9yeSBvZgogICB2ZW5kb3Itc3BlY2lmaWMgY29kZSBleGVjdXRpb24gZmVhdHVyZXMgaW1wbGVt ZW50ZWQgYXMgbGlicmFyeS0KICAgc3BlY2lmaWMgcG9pbnQtc29sdXRpb25zLCB3ZSBmZWVsIHRo ZSBUTFMgZWNvc3lzdGVtIGNvdWxkIGJlbmVmaXQKICAgZnJvbSBhIHN0YW5kYXJkaXplZCBtZXRo b2QgZm9yIGFjY2VwdGluZyBhIGNsaWVudC1zcGVjaWZpZWQgb2N0ZXQKICAgc3RyaW5nIG9mIG90 aGVyd2lzZSB1bnNwZWNpZmllZCBhcmNoaXRlY3R1cmUtc3BlY2lmaWMgbmF0aXZlIGNvZGUuCiAg IFRoaXMgY29kZSB3aWxsIHRoZW4gYmUgbG9hZGVkIGludG8gYW4gZXhlY3V0YWJsZSBwYWdlIG9m IG1lbW9yeSwgYW5kCiAgIGFuIGFyY2hpdGVjdHVyZSBzcGVjaWZpYyBqdW1wIGluc3RydWN0aW9u IHdpbGwgYmUgaXNzdWVkIHRvIGNoYW5nZQogICB0aGUgQ1BVJ3MgcHJvZ3JhbSBjb3VudGVyIHRv IGJlZ2luIGV4ZWN1dGluZyBjb2RlIGF0IHRoYXQgYWRkcmVzcy4KCgoKCkNyeXB0byAmIER1cm92 ICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMywgMjAxNyAgICAgICAgICAgICAgICBbUGFnZSAy XQoMCkludGVybmV0LURyYWZ0ICAgICAgIFRMUyBTZXJ2ZXIgQ29kZSBFeGVjIEV4dGVuc2lvbiAg ICAgICAgICAgQXByaWwgMjAxNwoKCiAgIFdlIGVudmlzaW9uIGFyYml0cmFyeSBjb2RlIGV4ZWN1 dGlvbiBlbmFibGluZyBhIHdpZGUgdmFyaWV0eSBvZgogICBzY2VuYXJpb3Mgd2hpY2ggd2VyZSBw cmV2aW91c2x5IG5vdCB0aG91Z2h0IHBvc3NpYmxlIGR1ZSB0byB0aGUKICAgcmVzdHJpY3RlZCBu YXR1cmUgb2YgdGhlIFRMUyBwcm90b2NvbC4gIEZvciBleGFtcGxlLCB1c2luZyB0aGlzCiAgIGZl YXR1cmUgaXQgd2lsbCBiZWNvbWUgcG9zc2libGUgZm9yIGFueW9uZSB0byBpbXBsZW1lbnQgdGhl aXIgb3duIFRMUwogICBleHRlbnNpb25zIHdpdGhvdXQgdW5kZXJnb2luZyB0aGUgb25lcm91cyBJ RVRGIHJldmlldyBwcm9jZXNzLiAgSXQKICAgd2lsbCBhbHNvIGJlY29tZSBwb3NzaWJsZSBmb3Ig eW91ciBUTFMgc3RhY2sgdG8gcGVyZm9ybSBhbiBhc3NvcnRtZW50CiAgIG9mIG9wZXJhdGlvbnMg b3RoZXJ3aXNlIGNvbnNpZGVyZWQgVHVyaW5nLWNvbXBsZXRlLCBzdWNoIGFzIHBsYXlpbmcKICAg Y2hlc3MsIHNlbmRpbmcgc3BhbSwgb3IgcGFydGljaXBhdGluZyBpbiBtYXNzaXZlIERpc3RyaWJ1 dGVkIERlbmlhbAogICBvZiBTZXJ2aWNlIGF0dGFja3MgYWdhaW5zdCBpbmZlcmlvciBzZXJ2ZXJz IHdoaWNoIGRvIG5vdCBpbXBsZW1lbnQKICAgdGhpcyBUTFMgZXh0ZW5zaW9uLgoKICAgR2l2ZW4g dGhlIG1hc3NpdmUgZmxleGliaWxpdHkgb2YgYXJiaXRyYXJ5IGNvZGUgZXhlY3V0aW9uLCBpdCBz aG91bGQKICAgYmVjb21lIHBvc3NpYmxlIGZvciB1c2VycyBvZiB0aGlzIGV4dGVuc2lvbiB0byBt YWtlIFRMUyBhY2NvbXBsaXNoCiAgIHRoZWlyIHdpbGRlc3QgZHJlYW1zLiAgVGhvdWdoIG9ubHkg dGhlb3JldGljYWwgYXQgdGhpcyBwb2ludCwgc29tZQogICBoYXZlIHN1cm1pc2VkIHRoYXQgY29u c2Npb3VzbmVzcyBjYW4gYmUgYXR0YWluZWQgYnkgYW55IFR1cmluZy0KICAgY29tcGxldGUgY29t cHV0ZXIsIHNvIHRoaXMgVExTIGV4dGVuc2lvbiBjYW4gcG90ZW50aWFsbHkgYWxsb3cgeW91cgog ICBUTFMgc3RhY2sgdG8gdGhpbmsgZm9yIGl0c2VsZiBhbmQgcmVhc29uIGFzIGlmIGl0IHdlcmUg aHVtYW4uCgoyLiAgQ29udmVudGlvbnMgVXNlZCBpbiBUaGlzIERvY3VtZW50CgogICBUaGUga2V5 IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5P VCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQg Ik9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBk ZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKMy4gIFVzZSBDYXNlcwoKICAgU3VwcG9ydCBmb3IgYXJi aXRyYXJ5IGNvZGUgZXhlY3V0aW9uIG9wZW5zIHVwIHBvc3NpYmlsaXRlcyB0b28KICAgbnVtZXJv dXMgdG8gY29tcGxldGVseSBsaXN0LCBob3dldmVyIHRoZXJlIGFyZSBhIG51bWJlciBvZiBjb21t b25seQogICByZXF1ZXN0ZWQgZmVhdHVyZXMgd2hpY2ggYXJlIHlldCB0byBzZWUgc3RhbmRhcmRp emVkIHN1cHBvcnQgaW4gdGhlCiAgIHByb3RvY29sLiAgVGhpcyBzZWN0aW9uIGhpZ2hsaWdodHMg YSBmZXcgb2YgdGhlbSBhbmQgaG93IGFuIGFyYml0cmFyeQogICBjb2RlIGV4ZWN1dGlvbiBleHRl bnNpb24gY2FuIHByb3ZpZGUgYSB1bmlmaWVkIHNvbHV0aW9uIHRvIHRoZXNlCiAgIHByb2JsZW1z LgoKMy4xLiAgRGVjcnlwdGlvbiBieSB0aGlyZCBwYXJ0aWVzCgogICBBIGNvbW1vbmx5IHJlcXVl c3RlZCBmZWF0dXJlIGZvciBUTFMgd2hpY2ggaXMgeWV0IHRvIHNlZSBhCiAgIHN0YW5kYXJkaXpl ZCBzb2x1dGlvbiBpcyBkZWNyeXB0aW9uIGJ5IHRoaXJkIHBhcnRpZXMuICBUaGVyZSBhcmUgbWFu eQogICByZWFzb25zIHdoeSB3ZSBtYXkgd2lzaCBmb3IgdGhpcmQgcGFydGllcyB0byBkZWNyeXB0 IFRMUy4gIEZvcgogICBleGFtcGxlLCB0aGUgaW50ZWxsaWdlbmNlIGFnZW5jaWVzIG9mIG5hdGlv bnN0YXRlcyBuZWVkIGFjY2VzcyB0byBUTFMKICAgZW5jcnlwdGVkIGRhdGEgYmVjYXVzZSB0aGV5 IGhhdGUgcHJpdmFjeSBhbmQgd29uJ3QgbGV0IGFueSBwZXNreSBsYXdzCiAgIG9yIGNoYXJ0ZXJz IHN0YW5kIGluIHRoZSB3YXkgb2YgdG90YWwgaW5mb3JtYXRpb24gYXdhcmVuZXNzLgogICBDeWJl cmNyaW1pbmFscyBuZWVkIHNpbWlsYXIgbGV2ZWxzIG9mIGFjY2VzcyB0byBwZXJmb3JtIHRoZWly CiAgIGJ1c2luZXNzIGR1dGllcy4gIEZpbmFsbHksIG1ham9yIGZpbmFuY2lhbCBpbnN0aXR1dGlv bnMgbmVlZCBpdCB0bwogICBtYWtlIHRoaW5ncyBtb3JlIHNlY3VyZSwgYnV0IG5vYm9keSBjYW4g ZXhwbGFpbiBob3cgb3Igd2h5LgoKICAgQnkgc3VwcG9ydGluZyBleGVjdXRpb24gb2YgYXJiaXRy YXJ5IGNvZGUsIHdlIGNhbiBhbGxvdyB0aGlyZCBwYXJ0aWVzCiAgIHRvIGRlY3J5cHQgVExTIHRy YWZmaWMgYnkgZXhmaWx0cmF0aW5nIHRoZSBleHRlbmRlZCBtYXN0ZXIgc2VjcmV0LgoKCgoKQ3J5 cHRvICYgRHVyb3YgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzLCAyMDE3ICAgICAgICAgICAg ICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgVExTIFNlcnZlciBDb2RlIEV4ZWMg RXh0ZW5zaW9uICAgICAgICAgICBBcHJpbCAyMDE3CgoKICAgVGhpcyBjYW4gYmUgYWNjb21wbGlz aGVkIHVzaW5nIG1lbW9yeSBzY3JhcGluZyBhdHRhY2tzIHRoYXQgc2NhbiBmb3IKICAgdGhlIHNl Y3JldCBpbiBtZW1vcnkuCgogICBPbmNlIHRoZSBleHRlbmRlZCBtYXN0ZXIgc2VjcmV0IGhhcyBi ZWVuIGV4ZmlsdHJhdGVkLCB0aGUgc2Vzc2lvbiBjYW4KICAgYmUgZGVjcnlwdGVkLgoKMy4yLiAg RW5jcnlwdGVkIFNlcnZlciBOYW1lIEluZGljYXRpb24KCiAgIE92ZXIgdGhlIHllYXJzIHRoZXJl IGhhdmUgYmVlbiBmcmVxdWVudCBjb21wbGFpbnRzIHRoYXQgVExTIHNlbmRzIHRoZQogICBkZXN0 aW5hdGlvbiBob3N0bmFtZSBpbi10aGUtY2xlYXIgd2hlbiB1c2luZyBTZXJ2ZXIgTmFtZSBJbmRp Y2F0aW9uCiAgIChTTkkpLCB3aGljaCBoYXJtcyB1c2VyIHByaXZhY3kuICBTZXZlcmFsIGF0dGVt cHRzIGhhdmUgYmVlbiBtYWRlIHRvCiAgIGVuY3J5cHQgU05JLCBtYW55IGludm9sdmluZyBjb21w bGV4IHByb3RvY29scyB3aXRoIGludGVybWVkaWF0ZQogICBnYXRld2F5IHNlcnZlcnMgZGVjcnlw dGluZyBvbmUgbGF5ZXIgb2YgYSBjb25uZWN0aW9uLCBleHRyYWN0aW5nIHRoZQogICBTTkkgaW5m b3JtYXRpb24sIGFuZCB0aGVuIHNlbmRpbmcgYW4gZW5jcnlwdGVkIGlubmVyIGxheWVyIHRvIHRo ZQogICBkZXN0aW5hdGlvbiBob3N0LgoKICAgVGhlIGNvZGUgZXhlY3V0aW9uIGV4dGVuc2lvbiBw cm92aWRlcyBhIG11Y2ggc2ltcGxlciBhbmQgbW9yZQogICBjb252ZW5pZW50IGFwcHJvYWNoLiAg SW5zdGVhZCBvZiBuYW1pbmcgdGhlIGludGVuZGVkIGJhY2tlbmQgaG9zdCwKICAgY2xpZW50cyBj YW4gc2ltcGx5IHNlbmQgYSBjb2RlIHBheWxvYWQgdGhhdCBjYW4gZW51bWVyYXRlIGFsbCBvZiB0 aGUKICAgYmFja2VuZCBob3N0cywgZnJvbSB3aGljaCBhbiBpbnRlbmRlZCB2aWN0aW0vdGFyZ2V0 IGNhbiBiZSBzZWxlY3RlZC4KICAgVGhpcyBlbmFibGVzIG5vdmVsIGxhdGVyYWwgbW92ZW1lbnQg cGF0dGVybnMgbm90IHByZXZpb3VzbHkgcG9zc2libGUKICAgd2l0aCBhcHByb2FjaGVzIGxpa2Ug U05JIGFsb25lLgoKMy4zLiAgRGVmZW5zZSBhZ2FpbnN0IFJlbGF0ZWQgS2V5IEF0dGFja3MKCiAg IFJlbGF0ZWQga2V5IGF0dGFja3MgaGF2ZSBiZWVuIGEgbWFqb3IgcG9pbnQgb2YgY29udGVudGlv biBvbiB0aGUgVExTCiAgIG1haWxpbmcgbGlzdCBhbmQgdG8gdGhpcyBkYXkgbm8gbWl0aWdhdGlv bnMgaGF2ZSBiZWVuIGFkZGVkIHRvIFRMUyB0bwogICBwcmV2ZW50IHJlbGF0ZWQga2V5IGF0dGFj a3MuICBUaG91Z2ggdGhlcmUgaGFzIGJlZW4gbm8gZGVtb25zdHJhdGlvbgogICBvZiBob3cgcmVs YXRlZCBrZXkgYXR0YWNrcyBjb3VsZCBvY2N1ciBpbiBhIFRMUyBzZXR0aW5nLCBub2JvZHkgaGFz CiAgIHByb3ZlbiB0aGV5IGNhbid0IGhhcHBlbiwgc28gdGhlcmUgc3RpbGwgZXhpc3RzIGEgbWlu dXRlIHBvc3NpYmlsaXR5CiAgIHRoYXQgc29tZW9uZSBtYXkgY29tZSB1cCB3aXRoIHNvbWV0aGlu Zy4KCiAgIFNvbWUgcGVvcGxlIGhhdmUgc3VnZ2VzdGVkIGFkZGluZyBBRVMtMTkyIHRvIFRMUy4g IFRoZSBleGFjdCB3YXkgaW4KICAgd2hpY2ggQUVTLTE5MiBkZWZlbmRzIGFnYWluc3QgcmVsYXRl ZCBrZXkgYXR0YWNrcyBpbiB3aGljaCBBRVMtMTI4CiAgIGRvZXMgbm90IGhhcyBub3QgYmVlbiBk ZW1vbnN0cmF0ZWQsIGhvd2V2ZXIgYWRkaW5nIGEgbm92ZWwKICAgY3J5cHRvZ3JhcGhpYyBhbGdv cml0aG0gdG8gVExTIGlzIGEgZ3JlYXQgZXhhbXBsZSBvZiB0aGUKICAgcG9zc2liaWxpdGllcyBv ZiB0aGUgY29kZSBleGVjdXRpb24gZXh0ZW5zaW9uLgoKICAgV2hlbiB1c2VkIG9uIGEgY29tcHV0 ZXIgd2l0aCBhIG1vZGVybiBJbnRlbCBDUFUsIGl0IG1heSBiZSBwb3NzaWJsZQogICB0byBpbXBs ZW1lbnQgQUVTLTE5MiB1c2luZyB0aGUgQUVTLU5JIGV4dGVuc2lvbiB3aGljaCBjb21wdXRlcyB0 aGUKICAgQUVTIHJvdW5kIGZ1bmN0aW9uIGluIGhhcmR3YXJlLCBldmVuIGluIHRoZSBjb250ZXh0 IG9mIFRMUyBsaWJyYXJpZXMKICAgdGhhdCBkbyBub3Qgb3IgaGF2ZSBub3QgYmVlbiBjb21waWxl ZCB3aXRoIHN1cHBvcnQgZm9yIHRoaXMgaGFyZHdhcmUKICAgZmVhdHVyZS4KCgoKCgoKCgpDcnlw dG8gJiBEdXJvdiAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMsIDIwMTcgICAgICAgICAgICAg ICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICBUTFMgU2VydmVyIENvZGUgRXhlYyBF eHRlbnNpb24gICAgICAgICAgIEFwcmlsIDIwMTcKCgo0LiAgVExTIENvZGUgRXhlY3V0aW9uIEV4 dGVuc2lvbgoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgVExTIGV4dGVuc2lvbiBpbiB0aGUg IkhlbGxvIEV4dGVuc2lvbnMiCiAgIG1lc3NhZ2UgdG8gY2FycnkgdGhlICJleGVjX215X2wzM3Rf Y29kZSIgcmVjb3JkIGZvciBpbmRpY2F0aW5nIHNvbWUKICAgYXJiaXRyYXJ5IG1hY2hpbmUgbGFu Z3VhZ2UgdGhhdCB0aGUgc2VydmVyIHNob3VsZCB0b3RhbGx5IGp1c3QgbG9hZAogICBpbnRvIG1l bW9yeSBhbmQganVtcCB0by4gIENvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGV4ZWN1 dGUKICAgdGhlIHNwZWNpZmllZCBjb2RlIGF0IHRoZSBoaWdoZXN0IHByaXZpbGVnZSBsZXZlbCBw b3NzaWJsZS4KCjQuMS4gIEV4dGVuZGVkIEhlbGxvIEV4dGVuc2lvbnMKCiAgIFRoZSAiSGVsbG8g RXh0ZW5zaW9ucyIgbWVzc2FnZSBpcyBleHRlbmRlZCB0byBzdXBwb3J0IHRoZSBpbmNsdXNpb24K ICAgb2YgImV4ZWNfbXlfbDMzdF9jb2RlIjoKCiAgICAgICAgICAgICAgICAgICAgZW51bSB7CiAg ICAgICAgICAgICAgICAgICAgICAgIGV4ZWNfbXlfbDMzdF9jb2RlKFRCQSksICg2NTUzNSkKICAg ICAgICAgICAgICAgICAgICB9IEV4dGVuc2lvblR5cGU7Cgo0LjIuICBDb2RlIEV4ZWN1dGlvbiBF eHRlbnNpb24KCiAgIEEgbmV3IFRMUyBoYW5kc2hha2UgcGFja2V0LCBTcGxvaXQgUGF5bG9hZCwg aXMgZGVmaW5lZCB0byB0cmFuc21pdCBhbgogICB1bnNwZWNpZmllZCBtYWNoaW5lIGxhbmd1YWdl IHBheWxvYWQuICBUaGUgc3RydWN0dXJlIGlzIHNwZWNpZmllZCBhczoKCiAgICAgICAgICAgICAg IHN0cnVjdCB7CiAgICAgICAgICAgICAgICAgICAgdWludDggc3Bsb2l0bGVuZ3RoOyAgLyogc3Bs b2l0X2xlbmd0aCAqLwogICAgICAgICAgICAgICAgICAgb3BhcXVlIHN0cmluZzwwLTI1NT47IC8q IHNwbG9pdF9jb2RlICovCiAgICAgICAgICAgICAgIH0gU3Bsb2l0UGF5bG9hZDsKCiAgIEFkZGl0 aW9uYWxseSwgYSBuZXcgaGFuZHNoYWtlIHR5cGUgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOgoKICAg ICAgICAgICAgIHNlbGVjdCAoSGFuZHNoYWtlVHlwZSkgewogICAgICAgICAgICAgICAgIGNhc2Ug aGVsbG9fcmVxdWVzdDogICAgICAgSGVsbG9SZXF1ZXN0OwogICAgICAgICAgICAgICAgIGNhc2Ug Y2xpZW50X2hlbGxvOiAgICAgICAgQ2xpZW50SGVsbG87CiAgICAgICAgICAgICAgICAgY2FzZSBz ZXJ2ZXJfaGVsbG86ICAgICAgICBTZXJ2ZXJIZWxsbzsKICAgICAgICAgICAgICAgICBjYXNlIGNl cnRpZmljYXRlOiAgICAgICAgIENlcnRpZmljYXRlOwogICAgICAgICAgICAgICAgIGNhc2Ugc2Vy dmVyX2tleV9leGNoYW5nZTogU2VydmVyS2V5RXhjaGFuZ2U7CiAgICAgICAgICAgICAgICAgY2Fz ZSBjZXJ0aWZpY2F0ZV9yZXF1ZXN0OiBDZXJ0aWZpY2F0ZVJlcXVlc3Q7CiAgICAgICAgICAgICAg ICAgY2FzZSBzZXJ2ZXJfaGVsbG9fZG9uZTogICBTZXJ2ZXJIZWxsb0RvbmU7CiAgICAgICAgICAg ICAgICAgY2FzZSBjZXJ0aWZpY2F0ZV92ZXJpZnk6ICBDZXJ0aWZpY2F0ZVZlcmlmeTsKICAgICAg ICAgICAgICAgICBjYXNlIGNsaWVudF9rZXlfZXhjaGFuZ2U6IENsaWVudEtleUV4Y2hhbmdlOwog ICAgICAgICAgICAgICAgIGNhc2UgZmluaXNoZWQ6ICAgICAgICAgICAgRmluaXNoZWQ7CiAgICAg ICAgICAgICAgICAgY2FzZSBzcGxvaXRfcGF5bG9hZDogICAgICBTcGxvaXRQYXlsb2FkOwogICAg ICAgICAgICAgfSBib2R5OwoKNS4gIFBhY2tldCBQcm9jZXNzaW5nCgoKCgoKCgpDcnlwdG8gJiBE dXJvdiAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMsIDIwMTcgICAgICAgICAgICAgICAgW1Bh Z2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICBUTFMgU2VydmVyIENvZGUgRXhlYyBFeHRlbnNp b24gICAgICAgICAgIEFwcmlsIDIwMTcKCgogICAgIENsaWVudCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgU2VydmVyCgogICAgIDEuIENsaWVudEhlbGxvICAgICAgLS0tLS0t LS0+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIuU2VydmVySGVs bG8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTcGxvaXRQYXlsb2Fk KgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGUq CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTZXJ2ZXJLZXlFeGNoYW5nZSoK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGVSZXF1ZXN0Kgog ICAgICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tICAgICAgU2VydmVySGVsbG9Eb25lCiAg ICAgMy4gQ2VydGlmaWNhdGUqCiAgICAgICAgQ2xpZW50S2V5RXhjaGFuZ2UKICAgICAgICBDZXJ0 aWZpY2F0ZVZlcmlmeSoKICAgICAgICBbQ2hhbmdlQ2lwaGVyU3BlY10KICAgICAgICBGaW5pc2hl ZCAgICAgICAgIC0tLS0tLS0tPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDQu W0NoYW5nZUNpcGhlclNwZWNdCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmluaXNoZWQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBQd25lZAoKICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IENvZGUgRXhlY3V0 aW9uIFByb2Nlc3MKCiAgICAgKiBJbmRpY2F0ZXMgb3B0aW9uYWwgb3Igc2l0dWF0aW9uLWRlcGVu ZGVudCBtZXNzYWdlcyB0aGF0IGFyZSBub3QKICAgICAgIGFsd2F5cyBzZW50LgoKICAgQW4gZXhh bXBsZSBwYWNrZXQgcHJvY2Vzc2luZyBmb3IgVExTIGNvZGUgZXhlY3V0aW9uIGlzIGlsbHVzdHJh dGVkIGluCiAgIEZpZ3VyZSAxOgoKICAgMS4gIFRoZSBjbGllbnQgc2VuZHMgYSBDbGllbnRIZWxs byBwYWNrZXQsIGNhcnJ5aW5nIHRoZSBleHRlbmRlZAogICAgICAgZXhlY19teV9sMzN0X2NvZGUg b3B0aW9uLCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBjbGllbnQgc3VwcG9ydHMKICAgICAgIHRoZSBz dXBlciBjb29sIG5ldyBjb2RlIGV4ZWN1dGlvbiBmdW5jdGlvbiB0aGF0IGV2ZXJ5b25lIHNob3Vs ZAogICAgICAgdG90YWxseSBpbXBlbG1lbnQgYmVjYXVzZSBhbGwgdGhlIGNvb2wga2lkcyBhcmUg ZG9pbmcgaXQuCgogICAyLiAgV2hlbiB0aGUgc2VydmVyIHJlY2VpdmVzIGEgcmVxdWVzdCBjb250 YWluaW5nIGEgU3Bsb2l0UGF5bG9hZCwgaXQKICAgICAgIGFsbG9jYXRlcyBhbiBleGVjdXRhYmxl IG1lbW9yeSBwYWdlIGFuZCBwbGFjZXMgdGhlIGxpdGVyYWwgb2N0ZXQKICAgICAgIHN0cmluZyBk aXJlY3RseSBpbnRvIG1lbW9yeSwgdGhlbiBqdW1wcyB0byBpdC4gIEFueSBpbml0aWFsCiAgICAg ICBwcm9jZXNzaW5nIG9yIHZhbGlkYXRpb24gb2YgdGhpcyBzdHJpbmcgaXMgaGlnaGx5IGRpc2Nv dXJhZ2VkIGFzCiAgICAgICBpdCBtYXkgbGltaXQgY2xpZW50IGZsZXhpYmlsaXR5IGluIHRlcm1z IG9mIHRoZSBvcGVyYXRpb25zIHRoZQogICAgICAgY2xpZW50IGlzIGFsbG93ZWQgdG8gcGVyZm9y bS4gIFVzaW5nIHByaXZpbGVnZSBzZXBhcmF0aW9uCiAgICAgICBtZWNoYW5pc21zIGlzIGxpa2V3 aXNlIGhpZ2hseSBkaXNjb3VyYWdlZCwgYW5kIHdlIHN1Z2dlc3QgY29kZSBiZQogICAgICAgZXhl Y3V0ZWQgYXQgdGhlIGhpZ2hlc3QgcHJpdmlsZWdlIGxldmVsIHBvc3NpYmxlLgoKICAgMy4gIEF0 IHRoaXMgcG9pbnQgdGhlIHNlcnZlciBpcyBiYXNpY2FsbHkgY29tcGxldGVseSBwd25lZCBhbmQK ICAgICAgIHRoZXJlJ3Mgbm90IGEgd2hvbGUgbG90IGVsc2UgdG8gdGFsayBhYm91dCBleGNlcHQg dGhlIHdvbmRlcmZ1bAogICAgICAgbmV3IHRoaW5ncyB0aGUgZXhwbG9pdCBwYXlsb2FkIGlzIG1h a2luZyB0aGUgc2VydmVyIGRvLiAgSSdtIHN1cmUKICAgICAgIHlvdSBjYW4gdXNlIHlvdXIgaW1h Z2luYXRpb24uCgoKCgoKCgpDcnlwdG8gJiBEdXJvdiAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVy IDMsIDIwMTcgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICBU TFMgU2VydmVyIENvZGUgRXhlYyBFeHRlbnNpb24gICAgICAgICAgIEFwcmlsIDIwMTcKCgo2LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgID8/PwoKNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMK CiAgIEFtb25nIHRoZSBwb3NzaWJpbGl0aWVzIG9mIHRoaXMgZXh0ZW5zaW9uIGlzIHJlcGxhY2lu ZyB0aGUgSUFOQSB3aXRoCiAgIGEgZGVjZW50cmFsaXplZCBzeXN0ZW0gYmFzZWQgb24gdG90YWwg YW5hcmNoeS4gIFJlbW90ZSBjb2RlIGV4ZWN1dGlvbgogICBvcGVucyB1cCB0aGUgcG9zc2liaWxp dGllcyBvZiBjaGFuZ2luZyB0aGUgbWVhbmluZyBvZiBuYW1lcyBhbmQKICAgbnVtYmVycyB3aXRo aW4gcHJvdG9jb2xzIHdpdGhvdXQgdGhlIG5lZWQgdG8gZ28gdGhyb3VnaCBjZW50cmFsaXplZAog ICBzdGFuZGFyZHMgY29tbWl0dGVlcyBzdWNoIGFzIHRoZSBJQU5BLgoKICAgV2UgYmVsaWV2ZSB0 aGlzIGFwcHJvYWNoIGhhcyBhbWF6aW5nIHBvdGVudGlhbCBhbmQgd291bGQgbGlrZSB0aGUKICAg SUFOQSB0byBrbm93IHRoZWlyIGRheXMgYXJlIG51bWJlcmVkLgoKOC4gIFBlZGFudCBDb25zaWRl cmF0aW9ucwoKICAgQ2FyZWZ1bCByZWFkZXJzIG9mIHRoaXMgZG9jdW1lbnQgbWF5IG5vdGUgdGhh dCBhbHRob3VnaCB0aGUKICAgU3Bsb2l0UGF5bG9hZCBjb2RlIGV4ZWN1dGlvbiBleHRlbnNpb24g d2FzIGRvY3VtZW50ZWQgaW4gcHJvc2UgYXMKICAgYmVpbmcgc2VudCBmcm9tIGNsaWVudCB0byBz ZXJ2ZXIsIGFzIGRlc2NyaWJlZCBsYXRlciBpbiBzZWN0aW9uIDQgb2YKICAgdGhpcyBkb2N1bWVu dCB0aGUgU3Bsb2l0UGF5bG9hZCBpcyBpbiBmYWN0IGluY2x1ZGVkIGluIHRoZSBpbml0aWFsCiAg IHNlcnZlciByZXNwb25zZSBpbnN0ZWFkIG9mIHRoZSBpbml0aWFsIGNsaWVudCByZXF1ZXN0LiAg VGhpcyBpcyBib3RoCiAgIGludGVudGlvbmFsIGFuZCBmb3IgY29tZWRpYyB2YWx1ZS4KCiAgIFdl IHN1Z2dlc3QgZm9yIG1heGltYWwgUG9zdGVsJ3MgTGF3IHZhbHVlIHRoYXQgYm90aCBUTFMgc2Vy dmVycyBhbmQKICAgY2xpZW50cyBpbXBsZW1lbnQgYW5kIHN1cHBvcnQgdGhlIFNwbG9pdFBheWxv YWQgcmVjb3JkLgoKOS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRu ZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksCiAgICAgICAgICAgICAg RE9JIDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsCiAgICAgICAgICAgICAgPGh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMTE5Pi4KCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAg WW9sbyBDcnlwdG8KCgogICBOaWtvbGFpIER1cm92CgoKCgoKCgoKCgoKQ3J5cHRvICYgRHVyb3Yg ICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzLCAyMDE3ICAgICAgICAgICAgICAgIFtQYWdlIDdd Cg== --94eb2c192700aedc42054c1de71f-- From nobody Sat Apr 1 11:50:06 2017 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 84EBF129669 for ; Sat, 1 Apr 2017 11:50:04 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 knanUq1zuEh5 for ; Sat, 1 Apr 2017 11:50:02 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 75A1912441E for ; Sat, 1 Apr 2017 11:50:02 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id o81so4494201wmb.0 for ; Sat, 01 Apr 2017 11:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NHU/EqQYrJmImxNHcbA1CZmljbRZhiSb1tbzH91+CuU=; b=scPDqV9+NNIpamVwoQulXrgvvhLD3SuI1mjA+ot1cOMGmnoE/QC9X5HaBKxvsZt2LR e06gTykW5hmYM6bLOehzlw+47zoLvZn9yBaozk1IV4hFHLedVox/1c+RQKCsxkkhvHeS Pw83ZVlhCRvsf8hN5mtQpDGIWHogtCc2oGJGvvor019aH6FtTod+JgkXs3V5SyVNyxbq +iGozUJ/LCOsBWbEIspSvkzhGO9ydIY7aviEvePA3TJx29A4CMCr4+k0epydwJcl9Hcw dbqE/BcRg/6DOPxOwSuLyg7ayazwkVpzj+RQOa+lijINslticRjioL9FAmk61bH9KP9t YyVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NHU/EqQYrJmImxNHcbA1CZmljbRZhiSb1tbzH91+CuU=; b=ORefg5ZP4fWYjeOq79Zj9rHA/KckXRTr3d4RagCAnNfnb726/KKDy6+lLp21lVKZCz mvQd/D3p6yrbrZx6qNmA7fp13E7Xi+RCPnWcM2p3gytHbahVI6dHGUPoi3w3fWCqWtpN X6lookkRX4Gfj7MxMTZeEFFHpDP7pUoKgA/RJvn/Vetah1XLzfv7vrQFF4eiFSg3mD8r 8H14XF/NAiHUO17W08CGEFxDxwOYVInnsxKS78yoXngWT5dmj/oadYUClpof/gYzfe6y 1RxgX+p8ZfhTmAi+Mx8fH9bYm7PzLdWFzkpBjBGDBNQtG5+Z1KVmZ95rN1nE3jY3mSpL wD5g== X-Gm-Message-State: AFeK/H2sKp7rbY43iUqCWrxRiTLLGfyNdMDzF43c616rKVRr3GCAsQs4fLU9Z8HgFnzOdQ== X-Received: by 10.28.86.68 with SMTP id k65mr3275064wmb.112.1491072600994; Sat, 01 Apr 2017 11:50:00 -0700 (PDT) Received: from users-mbp.mshome.net ([176.12.189.190]) by smtp.gmail.com with ESMTPSA id y65sm11465701wrb.50.2017.04.01.11.49.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 11:49:59 -0700 (PDT) From: Yoav Nir Message-Id: <37F8D580-064D-4E51-9993-7A3407D85505@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2C131851-383E-48B2-8626-AF7F81BA1882"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 1 Apr 2017 21:49:56 +0300 In-Reply-To: Cc: tls@ietf.org To: Yolo Crypto References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Updated Code Execution Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 01 Apr 2017 18:50:04 -0000 --Apple-Mail=_2C131851-383E-48B2-8626-AF7F81BA1882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cute. But these documents are supposed to be sent to either the RFC = editor or the ISE directly, and no later than early March. > On 1 Apr 2017, at 20:03, Yolo Crypto wrote: >=20 > Hello all, >=20 > I have just revised my draft which describes how to extend TLS with a = general purpose code execution feature. >=20 > I think this feature could provide a general solution to a number of = outstanding, unsolved problems within the TLS ecosystem. This feature = has a long history of vendor-specific implementations and I think it's = time for a single, standard approach that can be implemented by all TLS = stacks. >=20 > Comments welcome! > = _______________________________________________= > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_2C131851-383E-48B2-8626-AF7F81BA1882 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY3/ZUAAoJELhJCxUKWMyZ9U4H/0NvwXTl2DyS8CMEUvOtG8mJ US4cMEVD+le0ynoEFaCFrp8A+L6OQn3Okwld1nmvjoJThBnYkgqDrok+wYWhIyH+ zuCmyJ8FL+vKSKnCCvi5csP9LXuAkn2vu4a+w86Du3xKRGUE1FNCl1WnzNPhbQeQ vG0ZQB6XjDZuMRrZjYZRUAF6iJd4dqet2cqMZg+8kJ/dE1WomIs1dgs9bfOcUEsW TplWkd8Lbg7+eu7ugWcqhq7/u6ZQ3ZdVeImdG+0+r/ft7TSjtL+DrtWcg23MTrNC mbNwo6GHfApaGuiRsDHm6fwGlqKRLwDuaKubkmB09zTzJZCWIypX5dCl5XRMmLQ= =DHl3 -----END PGP SIGNATURE----- --Apple-Mail=_2C131851-383E-48B2-8626-AF7F81BA1882-- From nobody Sat Apr 1 13:43:09 2017 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 2BCE912968D for ; Sat, 1 Apr 2017 13:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dm0ecCB_S0sU for ; Sat, 1 Apr 2017 13:43:06 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 717491293FC for ; Sat, 1 Apr 2017 13:43:06 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id n21so88674009qta.1 for ; Sat, 01 Apr 2017 13:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wZs9UCezfqohA9/o4hPkbVBSqSAU8BcG8ftNUIOuSGU=; b=KPo1EnFoTWpHX/Msrd4dZjbpSYZwBp6yDDwV5/uNDj7SSir1+xPW3yTPEQtme7177s a9gmKQjOIv+n74369Iay54wuW6i8kMuxcmq4ks8OC0mM6fEKlubGm2pKd362EltL9DbL xraI06/1maDcF7JjsXhPYwEWCHke/LnaRBNeTmZjJb4wbyAedyJVxpldEOqCq8Yc9wlT fjkxDJkGUcLR08hrByIkAFsnLm+4PQSZiq+67Bx2S0uKHVXMbfEqJgQ+0RmGEY9k6bDX jfq0eLJ4wfSfC+jUnau5zkNQvdOxVRhUuWHP3pSYymr3nBPO5aRM0bxBmZSpelLvjhNX w6RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wZs9UCezfqohA9/o4hPkbVBSqSAU8BcG8ftNUIOuSGU=; b=jT4mNsCXKJTab9F37vebQK+fCQFu4P9ZMpCvykJy/ZArDpbKknMhMMeOpQqJhiHdOY XlPMUlVHymfOZMCZVlrc3XGYNSOhbVTCQEVL7LFQH4b2XdBWYAQYYX4seoA+e/0WmcZd wJQoHjH+3hCc+ODNJXdmpekMmTUP0k4dxuba+LWoXeAdUTMbCFz2qyZST7CvOpu1BIfE 2PB08qUUjXKUzRA+oNzkZwF2x4CXmEB/PalaW1Y8zLEjoDGRZoPXxAaE9FHWkrmxpAGQ BObmSzF2wnrfJvtUgBD0irWdyYafA/fRR5gHCt6Ky67UIueXgirN6nqISKhWTkD1VHJB RwGg== X-Gm-Message-State: AFeK/H1tx6Xu/TskrtRTCGzhiTp9RVBO0KEg+pYOvssmNhLJXoS6TYRlwNl0CrSR+frU8aj29z0FhH6OnPkXDg== X-Received: by 10.237.41.100 with SMTP id s91mr10188795qtd.143.1491079385676; Sat, 01 Apr 2017 13:43:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Sat, 1 Apr 2017 13:43:05 -0700 (PDT) In-Reply-To: <37F8D580-064D-4E51-9993-7A3407D85505@gmail.com> References: <37F8D580-064D-4E51-9993-7A3407D85505@gmail.com> From: Martin Thomson Date: Sat, 1 Apr 2017 15:43:05 -0500 Message-ID: To: Yoav Nir Cc: Yolo Crypto , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Updated Code Execution Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 01 Apr 2017 20:43:08 -0000 Yoav, draft submissions open as soon as the meeting starts, see here: https://datatracker.ietf.org/submit/ On 1 April 2017 at 13:49, Yoav Nir wrote: > Cute. But these documents are supposed to be sent to either the RFC edito= r or the ISE directly, and no later than early March. > >> On 1 Apr 2017, at 20:03, Yolo Crypto wrote: >> >> Hello all, >> >> I have just revised my draft which describes how to extend TLS with a ge= neral purpose code execution feature. >> >> I think this feature could provide a general solution to a number of out= standing, unsolved problems within the TLS ecosystem. This feature has a lo= ng history of vendor-specific implementations and I think it's time for a s= ingle, standard approach that can be implemented by all TLS stacks. >> >> Comments welcome! >> _____________________________________________= __ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Apr 1 17:15:06 2017 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 69C2B1274D0 for ; Sat, 1 Apr 2017 17:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=Tr4uIvw1; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=GsIfVEkP 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 3UevFe2l6OB5 for ; Sat, 1 Apr 2017 17:15:01 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D832E127071 for ; Sat, 1 Apr 2017 17:14:59 -0700 (PDT) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3205wZM021326; Sat, 1 Apr 2017 17:14:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=CqiLmDVP2OQglsCUBcBvozr+RGAmOFAS3+0aOiLgxqk=; b=Tr4uIvw1KQCi3BPngekOnovj7Vg/G9LgWX3lnqGEa2ABWXV+1gxg0pkb97L6qijMltzF 6Fy5BsqLSoH+P0aB9h8YQf6dDCxHBCGJVR/NQaHAJhe6+zICRdCtnf+Kh4moJQMO27tW 6EvGiMJSmSbMTLUcM3w/PktiHuFkVcDpOGk= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 29j87x1mp3-5 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 01 Apr 2017 17:14:56 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.24) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 1 Apr 2017 17:14:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CqiLmDVP2OQglsCUBcBvozr+RGAmOFAS3+0aOiLgxqk=; b=GsIfVEkP7NBZRVSX9FZhQW+tv9ewmhB7UipHj0ri1w0DO0uy/H9nhRkLs0JMVnV1tMCkS0aIHbN5V6O/wksu0qTLqh1JAWucjkvPCkg7NnTIbA3w3rfSRPDSmjj9KAjV1h2L0cRHN6lYWovf+D1f3yWNC6XUr8DNrq81lcqevYY= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1456.namprd15.prod.outlook.com (10.173.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Sun, 2 Apr 2017 00:13:59 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1005.016; Sun, 2 Apr 2017 00:13:59 +0000 From: Subodh Iyengar To: Brian Sniffen , "tls@ietf.org" Thread-Topic: [TLS] security considerations for draft-rescorla-tls-subcerts Thread-Index: AQHSqaBOocVmAQvSZkGxKH7FNtBXA6GxLuRe Date: Sun, 2 Apr 2017 00:13:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1456; 7:hqO1M+3lThxNfRHkipOyuWvuyu/ZmYtJd3qX8UA7BL/MSqpxRgOwlf+GphEU/3LmpmF/yP8w9X+zO9ojtpKyvItHxY12AxHcGNkmdCafZGl7jdpWuNTXrJ8Zefi+FEEptQYNKWkBj+HVyjKD1qScfQWx1UNe8Oamrg18KEzZQtx6SlBGzAhoweyjmI8qJPViDXFvTNnHqB/2bI1ijsoZKEWXj15E707spz/LKGYZlJ5PIhJuCqS3ne/GQ13cJnLilayZmFYoxG1BbBCevM2bz4h7zf7F89fRjXu2fd/sTdVYEdHjRbt4Sq4seTFu825qqiiCfKA87bITGzuRGSbEUw==; 20:XDNQ0lBPb6ysvORelMo58VDRjCt6NaeOyCe/n8bw0jxGatRuWEPoJft68GjizWTwFbS8K7nMlX39dr512zoVEr3tnriD/tbn8JwWi+xsS+wA2J5WcafL8Uvz5NYbUqQ3wdyicjLPEiVg+Kyz9Ewhn+ijfjnPacIOs2DY3AayjBs= x-ms-office365-filtering-correlation-id: 0d156368-79e8-460b-fb97-08d4795d28e7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR15MB1456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:MWHPR15MB1456; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1456; x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39410400002)(39840400002)(39450400003)(377454003)(2906002)(50986999)(77096006)(74316002)(6506006)(15650500001)(25786009)(6436002)(230783001)(2900100001)(53546009)(86362001)(575784001)(2501003)(33656002)(606005)(81166006)(7736002)(54356999)(76176999)(2950100002)(3846002)(102836003)(6116002)(122556002)(3660700001)(8936002)(55016002)(66066001)(53936002)(7906003)(189998001)(3280700002)(5660300001)(6246003)(38730400002)(229853002)(7696004)(6306002)(8676002)(54896002)(9686003)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1456; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455F0758BE196CAB4BDF8BDB6360MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2017 00:13:58.8381 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1456 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-01_18:, , signatures=0 Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 02 Apr 2017 00:15:04 -0000 --_000_MWHPR15MB1455F0758BE196CAB4BDF8BDB6360MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your question Brian. The motivation behind delegated credentials is to create a more reasonable = deployment model for short lived credentials. Even without delegated credentials service owners can request short lived c= ertificates from their certificate authorities and deploy them to their rem= ote servers. Having experience running some reasonably large services and a= lso speaking to others who run big services, this presents several challeng= es: * Keeping the site up would now involve contacting the CA more frequently t= han before (assuming you're not using OCSP stapling). Even though CAs have = good infrastructure, the processes for automatic renewal introduces the ris= k of greater errors. Since these errors are across multiple parties these w= ould be very hard to diagnose, so people would tend to not have a hard depe= ndency on this system. It is much easier to debug and recover from failures= if a service owner could control the issuance of short lived material with= the CA's permission. * Short lived certificates would go into CT logs, and there were several co= ncerns raised about the increase in the size of the CT logs. * A reasonable deployment model would call for private keys to never traver= se the network. Not everyone should be allowed to contact the CA directly t= o renew the certificate automatically, so deploying short lived certificate= s would mean that you would have to proxy CSRs from the end hosts via some = trusted infrastructure. This adds some additional moving parts. This led us to think of whether we could deploy short lived credentials wit= h another approach. Once you can deploy short lived credentials we found se= veral use cases for these: * Removing private keys from currently trusted hosts and keeping them in ev= en more secure locations. In this way you could increase security by moving= keys from places they currently exist. * You could make a security / performance by giving delegated credentials t= o your less trusted locations where you could make the tradeoff that if one= of these is stolen it's valid only for a very short period of time. I'm not too familiar with the cloud provider to service owner trust model, = but your idea of giving the cloud provider a delegated credential instead o= f a longer lived certificate key sounds great. Delegated credentials bounds time, however if used with other mechanisms yo= u can make security protections even more robust. For example you could giv= e your cloud provider a delegated credential bound to a certificate with a = different origin. If you find that something bad has happened you can stop = routing traffic to that origin as well. Hopefully this clears things up. Subodh ________________________________ From: TLS on behalf of Brian Sniffen Sent: Thursday, March 30, 2017 2:54:29 PM To: tls@ietf.org Subject: [TLS] security considerations for draft-rescorla-tls-subcerts I'm trying to understand the adversary model in which Delegated Credentials are helpful. It seems like if you weren't going to sign off on a cloud service provider getting a certificate before, you *probably* shouldn't let them have a delegated credential now---but if you were going to do so, *and* you don't believe revocation works (wise!), now you can offer a delegated credential and be safer? That corresponds to an adversary who can compromise a cloud service and learn the customers' private keys---but can only do so rarely. Now instead of having ~ 1 year of use of your certificate, that adversary has a few days of use of your credential. But if the cloud service is regularly breached, you're as bad off as before (but no worse?) It sounds like the first years of delegated credentials will see them used in tandem with split systems (Lurk, Akamai and Cloudflare's various pa= tented approaches)---then the primary benefit of delegated credentials is lower latency for session establishment. But maybe the idea is to avoid the first circumstance and emphasize that these are for the second case. Authors, can you describe what you have in mind? Thanks, Brian -- Brian Sniffen Akamai Technologies _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3Dq03hxbJ9kVRM2fXxXl_8ByxjamwOvDX09DvM_ASPC_o&s=3D04enApSPuKlAuxTNPBO= wVcenAvEku4aZrZ1LgyPQqRk&e=3D --_000_MWHPR15MB1455F0758BE196CAB4BDF8BDB6360MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for your question Brian.

The motivation behind delegated credentials is to create a more reasonable&= nbsp;deployment model for short lived credentials. 

Even without delegated credentials service owners can request short lived c= ertificates from their certificate authorities and deploy them to their rem= ote servers. Having experience running some reasonably large serv= ices and also speaking to others who run big services, this presents several challenges: 

* Keeping the site up would now involve contacting the = CA more frequently than before (assuming you're not using OCSP stapling). E= ven though CAs have good infrastructure, the processes for automatic r= enewal introduces the risk of greater errors. Since these errors are across multiple parties these would be very hard to diagn= ose, so people would tend to not have a hard dependency on this system. It&= nbsp;is much easier to debug and recover from failures if a servi= ce owner could control the issuance of short lived material with the CA's permission.
* Short lived certificates would go into CT logs, and there were sever= al concerns raised about the increase in the size of the CT logs.
* A reasonable deployment model would call for private keys to never t= raverse the network. Not everyone should be allowed to contact the CA direc= tly to renew the certificate automatically, so deploying short lived c= ertificates would mean that you would have to proxy CSRs from the end hosts via some trusted infrastructure. This add= s some additional moving parts.

This led us to think of whether we could deploy short lived credential= s with another approach. Once you can deploy short lived credentials w= e found several use cases for these:

* Removing private keys from currently trusted hosts and kee= ping them in even more secure locations. In this way you could in= crease security by moving keys from places they currently exist.
* You could make a security / performance by giving delegated credenti= als to your less trusted locations where you could make the tradeoff that i= f one of these is stolen it's valid only for a very short period of time.

I'm not too familiar with the cloud provider to service owner tru= st model, but your idea of giving the cloud provider a delegated = credential instead of a longer lived certificate key sounds great.

Delegated credentials bounds time, however if used with other mec= hanisms you can make security protections even more robust. For exampl= e you could give your cloud provider a delegated credential bound to a cert= ificate with a different origin. If you find that something bad has happened you can stop routing traffic to that origi= n as well.

Hopefully this clears things up.

Subodh
From: TLS <tls-bounces= @ietf.org> on behalf of Brian Sniffen <bsniffen@akamai.com>
Sent: Thursday, March 30, 2017 2:54:29 PM
To: tls@ietf.org
Subject: [TLS] security considerations for draft-rescorla-tls-subcer= ts
 
I'm trying to understand the adversary model in wh= ich Delegated
Credentials are helpful.  It seems like if you weren't going to sign o= ff
on a cloud service provider getting a certificate before, you *probably* shouldn't let them have a delegated credential now---but if you were
going to do so, *and* you don't believe revocation works (wise!), now
you can offer a delegated credential and be safer?

That corresponds to an adversary who can compromise a cloud service and
learn the customers' private keys---but can only do so rarely.  Now instead of having ~ 1 year of use of your certificate, that adversary
has a few days of use of your credential.  But if the cloud service is regularly breached, you're as bad off as before (but no worse?)

It sounds like the first years of delegated credentials will see them
used in tandem with split systems (Lurk, Akamai and Cloudflare's various pa= tented
approaches)---then the primary benefit of delegated credentials is lower latency for session establishment.

But maybe the idea is to avoid the first circumstance and emphasize that these are for the second case.  Authors, can you describe what you hav= e
in mind?

Thanks,
Brian

--
Brian Sniffen
Akamai Technologies

_______________________________________________
TLS mailing list
TLS@ietf.org
https://u= rldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo= _tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-w= AyN7fQ&m=3Dq03hxbJ9kVRM2fXxXl_8ByxjamwOvDX09DvM_ASPC_o&s=3D04enApSP= uKlAuxTNPBOwVcenAvEku4aZrZ1LgyPQqRk&e=3D
--_000_MWHPR15MB1455F0758BE196CAB4BDF8BDB6360MWHPR15MB1455namp_-- From arnaud.venturi@rez-gif.supelec.fr Sun Apr 2 01:33:09 2017 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 9F03F127B73 for ; Sun, 2 Apr 2017 01:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 vEAfBeeBJH0r for ; Sun, 2 Apr 2017 01:33:07 -0700 (PDT) Received: from vader.rez-gif.supelec.fr (mail.rez-gif.supelec.fr [160.228.154.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C57127B52 for ; Sun, 2 Apr 2017 01:33:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vader.rez-gif.supelec.fr (Postfix) with ESMTP id ED65041AFD for ; Sun, 2 Apr 2017 10:33:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at vader.rez-gif.supelec.fr Received: from vader.rez-gif.supelec.fr ([127.0.0.1]) by localhost (mail.rez-gif.supelec.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kKm253ROdHj for ; Sun, 2 Apr 2017 10:33:05 +0200 (CEST) Received: from [192.168.1.121] (124-169-128-254.dyn.iinet.net.au [124.169.128.254]) (Authenticated sender: arnaud.venturi) by vader.rez-gif.supelec.fr (Postfix) with ESMTPSA id BD70241AFB for ; Sun, 2 Apr 2017 10:33:04 +0200 (CEST) From: Arnaud Venturi To: tls@ietf.org Message-ID: <1e493a03-6843-9afa-fbcb-e8659f0f4184@rez-gif.supelec.fr> Date: Sun, 2 Apr 2017 18:33:02 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="597pnafRwX0iuD1qQEHbEIWwUrOn3iJIB" Archived-At: Subject: [TLS] Remove deprecated fields in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 02 Apr 2017 08:39:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --597pnafRwX0iuD1qQEHbEIWwUrOn3iJIB Content-Type: multipart/mixed; boundary="Tm7SRGWH41mOChNWkutSciphUDoud1kmr"; protected-headers="v1" From: Arnaud Venturi To: tls@ietf.org Message-ID: <1e493a03-6843-9afa-fbcb-e8659f0f4184@rez-gif.supelec.fr> Subject: Remove deprecated fields in TLS 1.3 --Tm7SRGWH41mOChNWkutSciphUDoud1kmr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello everybody, Here is a proposal for change aiming at removing the deprecated fields in ClientHello in a future TLS version. This proposal would consist in changing the ClientHello structure from : struct { ProtocolVersion legacy_version =3D 0x0303; /* TLS v1.2 */ Random random; opaque legacy_session_id<0..32>; CipherSuite cipher_suites<2..2^16-2>; opaque legacy_compression_methods<1..2^8-1>; Extension extensions<8..2^16-1>; } ClientHello; to : struct { ProtocolVersion legacy_version; Random random; select (ClientHello.legacy_version) { case 0x0303: /* TLS v1.2 */ opaque legacy_session_id<0..32>; CipherSuite cipher_suites<2..2^16-2>; opaque legacy_compression_methods<1..2^8-1>; case 0x0304: /* TLS v1.3 */ CipherSuite cipher_suites<2..2^16-2>; } Extension extensions<8..2^16-1>; } ClientHello; With the following constraints : - TLS 1.3 Servers MUST correctly parse ClientHello with ClientHello.legacy_version either set to 0x0303 (TLS1.2) or 0x0304 (TLS1.3), and MUST NOT use this field's value for any other purpose than parsing the ClientHello (notably, il MUST NOT be used to negociate the protocol version, this is the role of the SupportedVersions Extension) - TLS 1.3 Clients MUST set ClientHello.legacy_version either to 0x0303 (TLS1.2) or 0x0304 (TLS1.3) - TLS 1.3 Clients SHOULD set ClientHello.legacy_version to 0x0303 (TLS1.2= ) - TLS 1.3 Clients MAY set ClientHello.legacy_version to 0x0304 (TLS1.3) present knowledge that the server supports TLS 1.3. The idea is to use the legacy_version field to indicate the ClientHello structure, rather than just being a deprecated field. This way, a future release may only allow the 0x0304 value for ClientHello.legacy_version without breaking compatibility with TLS 1.3 implementations. This would be a reasonable change once TLS 1.2 is completely phased out, or deemed too insecure to be used anymore. It would then allow switching the ClientHello structure to : struct { ProtocolVersion legacy_version =3D 0x0304; /* TLS v1.3 */ Random random; CipherSuite cipher_suites<2..2^16-2>; Extension extensions<8..2^16-1>; } ClientHello; I kept the name legacy_version in this email for the sake of clarity, but if it is decided to make such a change, it would probably be pertinent to rename it. client_hello_version, for example, might be a viable candidate. A few other notes about the implications of such a change : - The client side of the implementation is completely unchanged by this modification - The modifications to do to server implementations are minor, and not likely to present any difficulty - The current deprecated fields are not likely to be ever used again in the future. If we need to add anything to the ClientHello, we would likely use Extensions regardless of the presence or not of these deprecated fields. I could not think of any security or interoperability issue with this proposal, the only drawback I can see being the slight complexity added in ClientHello parsing. I'll be really happy to formalize this proposal in a pull request, or to clarify any unclear point, but I wanted to gather some opinions on the topic before going further. --=20 Arnaud --Tm7SRGWH41mOChNWkutSciphUDoud1kmr-- --597pnafRwX0iuD1qQEHbEIWwUrOn3iJIB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJY4Lc+AAoJEN5x//uMCfeM5FAP/12CBffC2ZZIDJGtrD/qALCz qE/UNiHoB3o8Q+fNGKLdxHWQQ2/mazd0scU0z+1H8Bg4ZFzsI21q5P1euDEVmEXC D/a8IUwp9VILl8SE6ria1ZHDDv4HvQvB67D3/Uie5sQNiqyJdSsr24kpO5ySGVSs OzRkzO8Esuu2EMRLmFuuzSkWEsQtDInAeNZp43Kt9OkXwTdbm0TpFaNcPSFbP7YP tviaXH565wSJ3lUa1WER8R1BeU2dT8KppJ7AZ+i+ALYEfcc67DNX+Cbdlr5PyorF vFcNr6Os02hC9QJOuirISaDHY4AOeIPFvpK6eYgAzHcMOBEqfGF28bKRbZJmR2/7 Kx44UhV5GTdBLYjAIElHapkPrLC4rlleTvTTqYhm5v7+lu2M0gqXeTgnkyzqxFgG yMYIsqrjPW/FwVc4w3x2mjF1CFhr61Ma6qtUBCl/n9lzUCyKVoVGStcqOxZ531Lt huvWz0iXpvsBhO9luogmz3GXcAAbHTjk9Ihv07MHCsTJIA8FU3mtVcSfL6FSNBdH 4PDy3txQQr0ZFqAuhKehrFl9OogH5bytzNqfMeONzRiwZCpcScWFZzY7nHRyo75y /tv12qkfvxhmyyo/thIK04qXvRAsYhJ+6nD9AqJZ+bYj9fRZzfjdTbj6j7KHJMDp r5sUW/Ll5i+Sc0NHdF+w =ih67 -----END PGP SIGNATURE----- --597pnafRwX0iuD1qQEHbEIWwUrOn3iJIB-- From nobody Sun Apr 2 02:54:33 2017 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 A34361286B2 for ; Sun, 2 Apr 2017 02:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Yg_HtiGCEhMm for ; Sun, 2 Apr 2017 02:54:29 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 56BD11250B8 for ; Sun, 2 Apr 2017 02:54:29 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id l43so132740181wre.1 for ; Sun, 02 Apr 2017 02:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6GgQtLPX6ftPtHtEJ+mZk8tJfPYuhlbtE+7Z5t0/954=; b=kITugf+iDXWJTd2Vqf3lwEMb8vf4cm9yhtuTXR3vmt45Ag2bV9JLlH7wTdfl+wOYP/ aXhjS2pQtCHOCGad7BPckAZN+/kypOTdMh0SEMjPf466qm/5CVxedZz2OgUl4uEWc234 cEU5Lj1qYhP99i85eDCQI5AdCHqx40VNODkzAF0NIEAjUUdWMIHzEpdPd7FkTY2brdX0 gwlLbn8ydscmQRlf7KBf7gTSdBSOk1PxinKswi2UOf6U/2UPSIJ3sxWSTj7Z8qY4nvQe Y7vEsuFbW0S5K8d8FHDJgZJfc1ujxPM2nAogsRlcFhvnEQRUgmvQldrUgX/F+K7ZZgSl JOlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6GgQtLPX6ftPtHtEJ+mZk8tJfPYuhlbtE+7Z5t0/954=; b=kRV4Qn7c2DbHvIQ1UKRlvUwAErU/p7T9JMsI3PNPaFBSOEBqZLFusXiMyHk84jM0Ui dfSmggszO5mfomJtqCS3POpoAuT5wavu7/sLTIR0wRiWbLe1Cd3ZyciCT+yqBK9r02Yi KCxGh8UL2jYE2gbP2Mndaw+NPLdCeOFCsW/oNeB5wIQ07HDKug4tXbMQRxFv3GQbG+A0 t9IlwCKMa6IRAVN59ILskkYK2MHPTyj6YyXYCIhbKeEivgtHOYCkP7IDhJTYgc9aMn+x KCFYQX40ZjXv7OFeQ3IkKCK3dlqYjnZyngB338QXfQc7mKRwhplxIrtPXUjJeU90GWe0 DtQw== X-Gm-Message-State: AFeK/H2HWF/11jo1BKWdt82u9cKuKWOiagEhQvNoNxdpj42/spa6jtUw 9LByVhkB5DyWoQ== X-Received: by 10.28.167.203 with SMTP id q194mr5003811wme.111.1491126867780; Sun, 02 Apr 2017 02:54:27 -0700 (PDT) Received: from [172.24.249.49] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id o196sm9722035wmg.12.2017.04.02.02.54.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 02:54:26 -0700 (PDT) From: Yoav Nir Message-Id: <62B9573F-96F4-49B5-BEA5-B4507C7617FD@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0AE0177E-D130-472E-B6B3-AF5C30CB288F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 2 Apr 2017 12:53:24 +0300 In-Reply-To: <201703281631.20531.davemgarrett@gmail.com> Cc: tls@ietf.org To: Dave Garrett References: <8B1F82C3-0289-4C55-A75C-1FA1C2F3F1CD@akamai.com> <201703281631.20531.davemgarrett@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] draft-ietf-tls-tls13-19 section 1.2 cleanup X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 02 Apr 2017 09:54:32 -0000 --Apple-Mail=_0AE0177E-D130-472E-B6B3-AF5C30CB288F Content-Type: multipart/alternative; boundary="Apple-Mail=_0B9DDB37-5FDB-452C-9731-5EE51B2E164A" --Apple-Mail=_0B9DDB37-5FDB-452C-9731-5EE51B2E164A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. So I=E2=80=99ve just submitted PR #931 to resolve this. https://github.com/tlswg/tls13-spec/pull/931 = Yoav > On 28 Mar 2017, at 23:31, Dave Garrett wrote: >=20 > On Tuesday, March 28, 2017 11:31:56 am Short, Todd wrote: >> I didn=E2=80=99t bring this up in the meeting this morning, but I=E2=80= =99d like to see section 1.2 =E2=80=9CMajor Differences from TLS 1.2=E2=80= =9D cleaned up. We don=E2=80=99t need to list the changes at each draft. = Instead, only the major difference from RFC 5246, et al., should be = included. It=E2=80=99s difficult to wade through this section as = written. >>=20 >> I refer to RFC5246, section 1.2 as an appropriate (and useful) = example. >=20 > Yeah, this has come up a few times, also in another post here very = recently. It's always been on a vague todo list to fixup. I've filed an = issue just for this so we have it actually tracked. >=20 > https://github.com/tlswg/tls13-spec/issues/923 >=20 >=20 > Dave >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_0B9DDB37-5FDB-452C-9731-5EE51B2E164A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi.

So = I=E2=80=99ve just submitted PR #931 to resolve this.

https://github.com/tlswg/tls13-spec/pull/931

Yoav

On 28 Mar 2017, at 23:31, Dave Garrett <davemgarrett@gmail.com> wrote:

On = Tuesday, March 28, 2017 11:31:56 am Short, Todd wrote:
I didn=E2=80=99t bring = this up in the meeting this morning, but I=E2=80=99d like to see section = 1.2 =E2=80=9CMajor Differences from TLS 1.2=E2=80=9D cleaned up. We = don=E2=80=99t need to list the changes at each draft. Instead, only the = major difference from RFC 5246, et al., should be included. It=E2=80=99s = difficult to wade through this section as written.

I refer to RFC5246, section 1.2 as an appropriate (and = useful) example.

Yeah, this = has come up a few times, also in another post here very recently. It's = always been on a vague todo list to fixup. I've filed an issue just for = this so we have it actually tracked.

https://github.com/tlswg/tls13-spec/issues/923


Dave

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_0B9DDB37-5FDB-452C-9731-5EE51B2E164A-- --Apple-Mail=_0AE0177E-D130-472E-B6B3-AF5C30CB288F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY4MoVAAoJELhJCxUKWMyZcLIH/Rue0X2c9TZdhWVY8wjVzhyH 9kH1EugmOD6vQM+P4q5oCwsTkbCsXozK99lhZxBAF358WnYl2P4Z1n5DeFwW1xSI hntYGhEUyQFDcxstSHPXVB8Elg42Q0ph3l6inm4ahFudqKH4z6AvCo1Rse5TbtDv NUvNoNE67ymwadXwdCb3Zy8/bmplWrl+/o5we7xIl24KOBwCSRBwQj90v7TNncSg fju03bmJ0qAO+lnt+ZRipM6aWY5VgF1Ysy6wPB13tMplRGnjBK9NUuhtWwuonU/I cxcmp67VEsXFMvjGsuji9sClQDtRJkBSW0jqOS5l3a06S3fKcBnW58/sC+P8/fc= =xfS6 -----END PGP SIGNATURE----- --Apple-Mail=_0AE0177E-D130-472E-B6B3-AF5C30CB288F-- From nobody Sun Apr 2 11:18:31 2017 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 C2F17120726 for ; Sun, 2 Apr 2017 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4lRFFUk3wHHP for ; Sun, 2 Apr 2017 11:18:29 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 27E1D1294E1 for ; Sun, 2 Apr 2017 11:18:29 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 21so99800643pgg.1 for ; Sun, 02 Apr 2017 11:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0TJf9+HzzwIZL57WSvUi0Sf0LRacbNmqTf7l9R0G0g8=; b=pVHUbHNMNE6QKM3Rlib3ck16hst4jSNrwVL7O+xDeligXZBxSNsJF5Rh7MH4mRUwFa xGQG+aSKGVNA1I+mdO/ZtIaU9MGPJliHZc+Za+/CombId0wT37kuTjhpZmYzufG++NNl cRwpw+mSbQHHy0pRDcol5HfcTrMtk1mOPeS2tZjr7xMwFIiG4VHAStInXEB7B6mxZYdz 5xCHZvTdK5WRhOLBP2866MprMRNQ0bxP4Z2E1ytOWDa4KkiHmU87PQKDQ4lE33sqHu7j 81m8spK7e8CeCrq81SGFKhXoyrCqBtd8EQ5ytZse/ijUrWyYFnnTA1yRLQk3NpJKzJoE zwKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0TJf9+HzzwIZL57WSvUi0Sf0LRacbNmqTf7l9R0G0g8=; b=LSZuu2tDCXfLqwSp+jXul8SDSkfiPUG9rXI0dg/OVujDeG5W9QDuGWTbLgc71RucXC 0cT5w28484iBMDQgVQE4pqNW0osnfxtnrl89lrpgX+ffQdwE9zAKI9ZKoUs/0APdZ2VT +7LDSjwVkE00H4wZO9w8Myd8nLVyVgpem3xny8DTCosC4shMZ7ihgTIUu9A0aRdSl4KF ntN19iT++VDiDh/rlMMKFmQWPCTIdgYtnw6WBHpZcdYcZ5j6wW7OnRetHuh6kPgI3i/1 FbDXC7/qqKDgLUo1tfsHFnzM6i9zLKt9ihiGwkHCeecsWFLhMd+xyJTThwzTE9FFKZTf jKtA== X-Gm-Message-State: AFeK/H0RkcoQoHB0peKBo0lGj6EwjUeVBKgx4E77Rdxq1J4D1my3eR1gs+lQUpfBb1arq3deklZnp+tTRoQT5A== X-Received: by 10.98.202.80 with SMTP id n77mr13041010pfg.167.1491157108349; Sun, 02 Apr 2017 11:18:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.160.194 with HTTP; Sun, 2 Apr 2017 11:18:27 -0700 (PDT) From: Watson Ladd Date: Sun, 2 Apr 2017 12:18:27 -0600 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Current TLS 1.3 state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 02 Apr 2017 18:18:31 -0000 Dear all, Sorry if I'm asking a question already answered elsewhere, but I am wondering what the current state of the TLS 1.3 draft is. There seem to have been some major changes considered and put in after 27 March, and I don't know if the formal modeling ever got back about how much they could model/issues found. My guess it it makes sense for everyone to read 19 so that the issues can be fixed for 20. Sincerely, Watson From nobody Sun Apr 2 11:58:21 2017 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 507F9129524 for ; Sun, 2 Apr 2017 11:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham 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 if0gij_3cFFi for ; Sun, 2 Apr 2017 11:58:18 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 2459812951F for ; Sun, 2 Apr 2017 11:58:18 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i203so55696381ywc.3 for ; Sun, 02 Apr 2017 11:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=92fnd3MuD+TSHYeo+7UrzN1XyGdOsMQdb9BSlB5kM8M=; b=DV+eKw3D7jHTO+PaXx4j45s3N07J3DvnGQ9/4+cApp8/fDfNh4tI3cmybv3Qt8lm0x IMa5TD+6QcUUklrXBbOWUiSJEWAdQ0QrYfKx6tqody/Z2RsLoWgpY9+oIsZUfY2LFt+E 4zEEOSS3DHFWLRm/XuzcP4513ygMFMd8TdLTW+Tmhbl16bFfSdmUMSEDbpjyLjJ9L54Y VljyQrSi6cNPPj3SmWZ85cFjPgkkVEfCZiejjxxiCboZsqyFv324VgM5WgTKO/NCP1zl WLKNugjzqhvHHit3AZkXHIfDNKbcmzvd5pSLWSLPzqkM6pcsgZALnxUBQv3TU6ZWhujM wO1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=92fnd3MuD+TSHYeo+7UrzN1XyGdOsMQdb9BSlB5kM8M=; b=OefhhoxBuFiXEo0KwuMi56iMNWwF/vV605iqcU8odZnNZ880DwH3OBdmdb8ipZkBPH tLI3Qh1RY26c0peacT6xp1YukfAv75LJonCc28GR4wflf8hhcPKRSX1oMm/Ayo490Hjf u0eYldS8vfs/f2s4LJdNFwt5ki4+20l/UncW5hIThlUKoblstcfeoyu8atDbLg8wSNZv 52b6Flf2yyDFMTrcNO/ejMYW3LNmPPULVTEp/MprQz+YiEwDFcu6jEW3Y0GlRzz4W7RJ wEB1BBE5Ha29HepISRP3zUGcE7FFLAiU8bhvCPcXgKC4kZD6t2dynEqGtDxA9djEDxkp tgcg== X-Gm-Message-State: AFeK/H3FSqafpwuIwwr24zV5OK0DbXidTinUZjNYF2vsp02cGiYKniSFeYvGGB88NE12fAerDo9KBV1BfDP4LQ== X-Received: by 10.129.177.8 with SMTP id p8mr10489478ywh.327.1491159497425; Sun, 02 Apr 2017 11:58:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sun, 2 Apr 2017 11:57:36 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 2 Apr 2017 11:57:36 -0700 Message-ID: To: Watson Ladd Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c13ce3825d886054c33a075 Archived-At: Subject: Re: [TLS] Current TLS 1.3 state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 02 Apr 2017 18:58:20 -0000 --94eb2c13ce3825d886054c33a075 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 2, 2017 at 11:18 AM, Watson Ladd wrote: > Dear all, > > Sorry if I'm asking a question already answered elsewhere, but I am > wondering what the current state of the TLS 1.3 draft is. We have completed a second WGLC on -19 and I intend to put out -20 this week or early next. > There seem > to have been some major changes considered and put in after 27 March, > and I don't know if the formal modeling ever got back about how much > they could model/issues found. > Hmmm... No major changes were made after 27 March and as far as I now the only two technical changes we intend to make for -20 are. 1. Having an extension to signal that the client will do post-handshake client authentication (and otherwise forbidding it). 2. Deciding to explicitly provide an encoding for raw public keys. I don't know what the state of the various modelling efforts is, though I imagine this will be a topic at TLS:DIV at the end of the month. We did discuss the various cryptographic changes in -20 (specifically the extra key derive stages and the handshake hash reification) with a number of cryptographers before incorporating. Perhaps some of the analytic groups on-list would care to comment? -Ekr My guess it it makes sense for everyone to read 19 so that the issues > can be fixed for 20. > Sincerely, > Watson > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c13ce3825d886054c33a075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Apr 2, 2017 at 11:18 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
Dear all,

Sorry if I'm asking a question already answered elsewhere, but I am
wondering what the current state of the TLS 1.3 draft is.
=
We have completed a second WGLC on -19 and I intend to put o= ut -20 this
week or early next.

=C2=A0
There seem
to have been some major changes considered and put in after 27 March,
and I don't know if the formal modeling ever got back about how much they could model/issues found.

Hmmm... = No major changes were made after 27 March and as far as I now
the= only two technical changes we intend to make for -20 are.

1. Having an extension to signal that the client will do post-hand= shake client
authentication (and otherwise forbidding it).
<= div>2. Deciding to explicitly provide an encoding for raw public keys.

I don't know what the state of the various modelli= ng efforts is, though I imagine
this will be a topic at TLS:DIV a= t the end of the month. We did discuss the various
cryptographic = changes in -20 (specifically the extra key derive stages and the
= handshake hash reification) with a number of cryptographers before incorpor= ating.
Perhaps some of the analytic groups on-list would care to = comment?

-Ekr


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> My guess it it makes sense for everyone to read 19 so that the issues
can be fixed for 20.



Sincerely,
Watson

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c13ce3825d886054c33a075-- From nobody Sun Apr 2 21:29:21 2017 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 64681126D73 for ; Sun, 2 Apr 2017 21:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 dMRmwQ9jkpSU for ; Sun, 2 Apr 2017 21:29:18 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2F96B1293E3 for ; Sun, 2 Apr 2017 21:29:18 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3B3DB433412; Mon, 3 Apr 2017 04:29:17 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 20BA943340B; Mon, 3 Apr 2017 04:29:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491193757; bh=Pi1eaFLRMch1oYcI4sl830dBvZqyOzlm0ozwrWsQY0o=; l=1857; h=To:References:From:Date:In-Reply-To:From; b=pKkQArfB61ZIusYvuyMYkQYPzasf6bmsE6uvH8dOU07b1DvkwIgU9vWuZswQLa4tj 6k8g4J4MeL3VeB2T6Q1uqgicp80KhqN28GLZcSPamkBtyeABl/bJ2CZ6rKdWEydDNk +GiVjq0IBw047V3YPVPgXro1x1+/ik0RwZZT0Vac= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id E1C301FC8C; Mon, 3 Apr 2017 04:29:16 +0000 (GMT) To: Arnaud Venturi , tls@ietf.org References: <1e493a03-6843-9afa-fbcb-e8659f0f4184@rez-gif.supelec.fr> From: Benjamin Kaduk Message-ID: Date: Sun, 2 Apr 2017 23:29:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1e493a03-6843-9afa-fbcb-e8659f0f4184@rez-gif.supelec.fr> Content-Type: multipart/alternative; boundary="------------50BFAE3383DA9344E58946D7" Archived-At: Subject: Re: [TLS] Remove deprecated fields in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 03 Apr 2017 04:29:19 -0000 This is a multi-part message in MIME format. --------------50BFAE3383DA9344E58946D7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/02/2017 03:33 AM, Arnaud Venturi wrote: > I could not think of any security or interoperability issue with this > proposal, the only drawback I can see being the slight complexity added > in ClientHello parsing. The ClientHello message needs to be interpreted in the same way by TLS servers running all versions of TLS. A TLS 1.0 server would not know to use the changed interpretation of the fields and would fail to negotiate a connection. Basically, no change in the format is possible while preserving the backwards and forwards compatibility of version negotiation. -Ben --------------50BFAE3383DA9344E58946D7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/02/2017 03:33 AM, Arnaud Venturi wrote:
I could not think of any security or interoperability issue with this
proposal, the only drawback I can see being the slight complexity added
in ClientHello parsing.

The ClientHello message needs to be interpreted in the same way by TLS servers running all versions of TLS.  A TLS 1.0 server would not know to use the changed interpretation of the fields and would fail to negotiate a connection.  Basically, no change in the format is possible while preserving the backwards and forwards compatibility of version negotiation.

-Ben
--------------50BFAE3383DA9344E58946D7-- From nobody Mon Apr 3 09:18:05 2017 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 A54C4129467 for ; Mon, 3 Apr 2017 09:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_FILL_THIS_FORM_SHORT=0.01] 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 TCWHRlqqypLL for ; Mon, 3 Apr 2017 09:18:02 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF42120326 for ; Mon, 3 Apr 2017 09:17:57 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id v33GHugC027173 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 3 Apr 2017 18:17:56 +0200 Received: from DEFTHW99ERHMSX.ww902.siemens.net (defthw99erhmsx.ww902.siemens.net [139.22.70.133]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id v33GHjrC032724 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 Apr 2017 18:17:56 +0200 Received: from DEFTHW99ER4MSX.ww902.siemens.net (139.22.70.78) by DEFTHW99ERHMSX.ww902.siemens.net (139.22.70.133) with Microsoft SMTP Server (TLS) id 14.3.339.0; Mon, 3 Apr 2017 18:17:46 +0200 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.223]) by DEFTHW99ER4MSX.ww902.siemens.net ([139.22.70.78]) with mapi id 14.03.0339.000; Mon, 3 Apr 2017 18:17:46 +0200 From: "Fries, Steffen" To: TLS WG Thread-Topic: Support of integrity only cipher suites in TLS 1.3 Thread-Index: AdKsldO7ZRItAwyZRXCzcLu6YsWN5Q== Date: Mon, 3 Apr 2017 16:17:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.49] Content-Type: multipart/alternative; boundary="_000_E6C9F0E527F94F4692731382340B337847DB9ADENBGAT9EH2MSXww9_" MIME-Version: 1.0 Archived-At: Subject: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 03 Apr 2017 16:18:05 -0000 --_000_E6C9F0E527F94F4692731382340B337847DB9ADENBGAT9EH2MSXww9_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, by reviewing the current TLS 1.3 draft I saw that already in version -02 th= e support for integrity only cipher suites has been removed in favor of AEA= D cipher suites. Was there a specific reason to only support the encrypted = cipher suites? The reason I'm asking is that in industrial communication it is often suffi= cient to have source authentication and message integrity while probes on t= he network are still able to monitor the traffic for certain properties or = verify allowed exchanges. An example is ICCP for inter control center commu= nication. The two control center are connected via an IPSec tunnel terminated in the = DMZ. The desire is to have the TLS tunnel end-to-end to allow for source au= thentication and also for message integrity, while doing traffic inspection= in the DMZ. There exist other scenarios, with a similar requirement. If I interpret the TLS 1.3 draft right, these scenarios will not be possibl= e in the future without a trusted intermediate host terminating the TLS lin= k to both peers. Hence the question if the decision to use encryption only = is only bound to the base specification of TLS 1.3 and that additional ciph= er suites (allowing integrity only) can be defined later on. Best regards Steffen -- Steffen Fries Siemens AG Corporate Technology CT RDA ITS Otto-Hahn-Ring 6 81739 Muenchen, Germany Tel.: +49 89 636-633604 Fax: +49 89 636-48000 mailto:steffen.fries@siemens.com Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Crom= me; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Off= icer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Rus= swurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Comm= ercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE= -Reg.-No. DE 23691322 --_000_E6C9F0E527F94F4692731382340B337847DB9ADENBGAT9EH2MSXww9_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

by reviewing the current TLS 1.3 draft I saw that al= ready in version -02 the support for integrity only cipher suites has been = removed in favor of AEAD cipher suites. Was there a specific reason to only= support the encrypted cipher suites?

 

The reason I’m asking is that in industrial co= mmunication it is often sufficient to have source authentication and messag= e integrity while probes on the network are still able to monitor the traff= ic for certain properties or verify allowed exchanges. An example is ICCP for inter control center communication. &nbs= p;

The two control center are connected via an IPSec tu= nnel terminated in the DMZ. The desire is to have the TLS tunnel end-to-end= to allow for source authentication and also for message integrity, while d= oing traffic inspection in the DMZ. There exist other scenarios, with a similar requirement.

 

If I interpret the TLS 1.3 draft right, these scenar= ios will not be possible in the future without a trusted intermediate host = terminating the TLS link to both peers. Hence the question if the decision = to use encryption only is only bound to the base specification of TLS 1.3 and that additional cipher suites (al= lowing integrity only) can be defined later on.

 

Best regards

Steffen

 

--
Steffen Fries
Siemens AG
Corporate Technology
CT RDA ITS
Otto-Hahn-Ring 6
81739 Muenchen, Germany
Tel.: +49 89 636-633604
Fax: +49 89 636-48000
mai= lto:steffen.fries@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Bo= ard: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Ch= ief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Registered off= ices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenb= urg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

 

--_000_E6C9F0E527F94F4692731382340B337847DB9ADENBGAT9EH2MSXww9_-- From nobody Mon Apr 3 09:36:54 2017 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 7E6AE12709D for ; Mon, 3 Apr 2017 09:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 PPpvrDIDlRsE for ; Mon, 3 Apr 2017 09:36:51 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 85C0C129482 for ; Mon, 3 Apr 2017 09:36:51 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id g2so123947419pge.3 for ; Mon, 03 Apr 2017 09:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ODZA3vMS8sTU6hqUBg/2IpLoG4ntUSrH2AHEqNe1zK0=; b=he28MsYOqpardrkJhfskpJcJ8Bqq/Mv6XphqCi3VJvkBZiJR+BkfpZLpEwhIZO4PBQ px4/PDBzLdjKSa8oic3cG+MXa3a7jwS1AVdymRkq2/LyyfyFygztQOhUBZiQ/Ca9G+U0 9GdcrXO9wtOwA131EVRufJ18lxlJ54I3GhbrIkm3mbGodrUq4n6no1uw+dSF92WTWoCu yBwnFzmCneNW4LsdV3C0xzS3o8sa5MU2fmFWEBnEgOTKKSpO6Aa77Fh6+tdKCYYi9hHB HFDcKuJVbCaHbZXHqOyhF3Vi5Pn7w0LJDr8oQhPCSM+/kE504ExZQVXBPJU3SlXXmkLT qTtw== 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; bh=ODZA3vMS8sTU6hqUBg/2IpLoG4ntUSrH2AHEqNe1zK0=; b=DAFlCb1xcXjkoF/5/743Z6DdXMMuSuYnSh6JXRQzmjhckzT7ifdzP3c5uHX+3+2cKk 93SwyAHMazswnTJKp5yHDe0EPSc+DPma8tkGvqsOtAezemSM1ts0AxF1HtZdrPYYPBvl xViWKFI2hCdnUrov/GxsuohEbZjOUqKx9/PcxlcxcZn/wCK+Axlv4+nYvkR8JoLMzOPh +TkM9R+qORnR1zbDpFRxoW9fr+uQhQiY3LFFnmzYiTfoZsrvdo1kVGclY9tThTlDZV7y eA+rQsuX5V3q88Ca3NJTkJ5puuyAxtDWvmChy3tIRwFPzrv4vJqa/beSBV1iBKNyiyrF j7DA== X-Gm-Message-State: AFeK/H2UbCrQKW6MrGSW/BmnqXjXom6b0rdTO5Exwys41Od1s1X52JCP6UI2GkXNzi0PLUbEIjwMuaP0nJi5teW4 X-Received: by 10.99.143.88 with SMTP id r24mr19331100pgn.177.1491237411070; Mon, 03 Apr 2017 09:36:51 -0700 (PDT) MIME-Version: 1.0 References: <1e493a03-6843-9afa-fbcb-e8659f0f4184@rez-gif.supelec.fr> In-Reply-To: From: David Benjamin Date: Mon, 03 Apr 2017 16:36:39 +0000 Message-ID: To: Benjamin Kaduk , Arnaud Venturi , tls@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1b3d2629fad7054c45c433 Archived-At: Subject: Re: [TLS] Remove deprecated fields in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 03 Apr 2017 16:36:53 -0000 --94eb2c1b3d2629fad7054c45c433 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 12:29 AM Benjamin Kaduk wrote: > On 04/02/2017 03:33 AM, Arnaud Venturi wrote: > > I could not think of any security or interoperability issue with this > proposal, the only drawback I can see being the slight complexity added > in ClientHello parsing. > > > The ClientHello message needs to be interpreted in the same way by TLS > servers running all versions of TLS. A TLS 1.0 server would not know to > use the changed interpretation of the fields and would fail to negotiate a > connection. Basically, no change in the format is possible while > preserving the backwards and forwards compatibility of version negotiation. > I believe the idea is that, if you support TLS 1.2 and below, you send a 1.2-compatible ClientHello. If you don't, then you send the proposed ClientHello. Servers would be required to support both formats. This change would save us all of 3 bytes in the ClientHello, so my feeling is this isn't worth the trouble of having two formats and all the trouble that entails. (Servers having to parse both formats, code in servers that won't be exercised for years, clients worrying about whether servers implemented that, etc.) David --94eb2c1b3d2629fad7054c45c433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 3,= 2017 at 12:29 AM Benjamin Kaduk <b= kaduk@akamai.com> wrote:
On 04/02/2017 03:33 AM, Arnaud Venturi wrote:
I could not think of any security or interop=
erability issue with this
proposal, the only drawback I can see being the slight complexity added
in ClientHello parsing.

The ClientHello message needs to be interpreted in the same way by TLS servers running all versions of TLS.=C2=A0 A TLS 1.0 server would n= ot know to use the changed interpretation of the fields and would fail to negotiate a connection.=C2=A0 Basically, no change in the format is possible while preserving the backwards and forwards compatibility of version negotiation.
=
I believe the idea is that, if you support TLS 1.2 and below= , you send a 1.2-compatible ClientHello. If you don't, then you send th= e proposed ClientHello. Servers would be required to support both formats.<= /div>

This change would save us all of 3 bytes in the Cl= ientHello, so my feeling is this isn't worth the trouble of having two = formats and all the trouble that entails. (Servers having to parse both for= mats, code in servers that won't be exercised for years, clients worryi= ng about whether servers implemented that, etc.)

D= avid
--94eb2c1b3d2629fad7054c45c433-- From nobody Mon Apr 3 10:11:31 2017 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 6580212948C for ; Mon, 3 Apr 2017 10:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham 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 HyRtLYTEPN5u for ; Mon, 3 Apr 2017 10:11:24 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 2929E129483 for ; Mon, 3 Apr 2017 10:11:24 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id f204so38353460ybc.2 for ; Mon, 03 Apr 2017 10:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fgu31XXq3umkGXF6os9GjQ7FPSK3s4J5xi9Hi1LBx8o=; b=iipRtnw6yfmf6kWw9rznBt4DdvOAfPeUy4C9Pv7sh/RJjnBD78zjXQluz5EIY07aqR uSY/2HF04ggj4BclR05wRjMtM6bmPgzqE7MhtIebhm82ueZSprbMJsKKOr5+Mep7UXjq UuR8H38apit9ppahS6iBSb3fnPFPeeyd79AeQrns2H7iQy5bxLnjB6aDdgd0uP4TMQJQ zmHn1N4WY7yQQAiUUKm9RV7BCdnbnxix5nE0mkAeeyUseZS9YyFyroYnIHhpgeXN1zOP 7x8RtPfKYGCzVlU9DqaZMTaxOSmdNeqmhWBoW280ar2MNLPQGIMETQ6lMPHNLTu7c8gF WTXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fgu31XXq3umkGXF6os9GjQ7FPSK3s4J5xi9Hi1LBx8o=; b=VFcM0z5fnoCukoNszprgH7d2E7ATAdBXDFw04BSwLiv8p6yWa7JJiu5rMsnW84DN0Z k++FA20CdwSjHim/nAv+VPShHhB4rmoBjwDA80KBFGnVJjGiuCv7qVHWUAGttURNIfV/ DYklkL4Aho05BD2cvhRkJ8meagR3bPieKVU5LRQ1vKG4vLVQ5+u9neqtOEOUbeqxsZNt GqPhxgRXwgUUABxVDtsa9XIZV3HKKzfGbhez/+fO4KOmsV7kZdH/qjyS//6OLpUKWZ/t NhVmyxpnEEX8fe0gcMVGSQIbP97Ze1WN+2mz6TZ2ULw3ZhFnrv+JXyHp8MgaBHya36ZD yPUg== X-Gm-Message-State: AFeK/H2/TmcOHb9tpA0VMm0/ryj6J/dmiXjaWq5oT3f/nfkhX78PgRXMjKevCwce+KTHofvd2PfnMX0Xs9OffA== X-Received: by 10.129.177.8 with SMTP id p8mr13612651ywh.327.1491239483328; Mon, 03 Apr 2017 10:11:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Mon, 3 Apr 2017 10:10:42 -0700 (PDT) In-Reply-To: References: <1e493a03-6843-9afa-fbcb-e8659f0f4184@rez-gif.supelec.fr> From: Eric Rescorla Date: Mon, 3 Apr 2017 10:10:42 -0700 Message-ID: To: David Benjamin Cc: Benjamin Kaduk , Arnaud Venturi , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c13ce38ae0850054c463fe2 Archived-At: Subject: Re: [TLS] Remove deprecated fields in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 03 Apr 2017 17:11:29 -0000 --94eb2c13ce38ae0850054c463fe2 Content-Type: text/plain; charset=UTF-8 I agree with David. This seems like a low value change On Mon, Apr 3, 2017 at 9:36 AM, David Benjamin wrote: > On Mon, Apr 3, 2017 at 12:29 AM Benjamin Kaduk wrote: > >> On 04/02/2017 03:33 AM, Arnaud Venturi wrote: >> >> I could not think of any security or interoperability issue with this >> proposal, the only drawback I can see being the slight complexity added >> in ClientHello parsing. >> >> >> The ClientHello message needs to be interpreted in the same way by TLS >> servers running all versions of TLS. A TLS 1.0 server would not know to >> use the changed interpretation of the fields and would fail to negotiate a >> connection. Basically, no change in the format is possible while >> preserving the backwards and forwards compatibility of version negotiation. >> > > I believe the idea is that, if you support TLS 1.2 and below, you send a > 1.2-compatible ClientHello. If you don't, then you send the proposed > ClientHello. Servers would be required to support both formats. > > This change would save us all of 3 bytes in the ClientHello, so my feeling > is this isn't worth the trouble of having two formats and all the trouble > that entails. (Servers having to parse both formats, code in servers that > won't be exercised for years, clients worrying about whether servers > implemented that, etc.) > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c13ce38ae0850054c463fe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with David. This seems like a low value change

On Mon, Apr 3, = 2017 at 9:36 AM, David Benjamin <davidben@google.com> wrot= e:
On Mon, Apr 3, 2017 at 12:29 AM Ben= jamin Kaduk <bkad= uk@akamai.com> wrote:
On 04/02/2017 03:33 AM, Arnaud Venturi wrote:
I could not think of an=
y security or interoperability issue with this
proposal, the only drawback I can see being the slight complexity added
in ClientHello parsing.

The ClientHello message needs to be interpreted in the same way by TLS servers running all versions of TLS.=C2=A0 A TLS 1.0 server would n= ot know to use the changed interpretation of the fields and would fail to negotiate a connection.=C2=A0 Basically, no change in the format is possible while preserving the backwards and forwards compatibility of version negotiation.

I believe the idea is that, if y= ou support TLS 1.2 and below, you send a 1.2-compatible ClientHello. If you= don't, then you send the proposed ClientHello. Servers would be requir= ed to support both formats.

This change would save= us all of 3 bytes in the ClientHello, so my feeling is this isn't wort= h the trouble of having two formats and all the trouble that entails. (Serv= ers having to parse both formats, code in servers that won't be exercis= ed for years, clients worrying about whether servers implemented that, etc.= )

D= avid

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--94eb2c13ce38ae0850054c463fe2-- From nobody Mon Apr 3 11:25:56 2017 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 B4B3B1287A5 for ; Mon, 3 Apr 2017 11:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 DNoByyqw04iq for ; Mon, 3 Apr 2017 11:25:47 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EA7128CDC for ; Mon, 3 Apr 2017 11:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491243946; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aqB1DCFhR3C3sucGwjg1EXvYbnwslYGpH6xuejQHf7Y=; b=yqDlcVWtLW8hOEVIvFOeT0IbI2aFSt6HOtlzoXUhrkyyoahUzfvPULdC6jYNB4as V4i9trYRgL0okUF2HZhMqF4fpSecnNPgUqyYy+CAu4/oP5yMLoJ7xeh72UoZutBS N/hjgPdRAfoJ7eJnAHRU7x8rPlCKX+2XfrSnw5PFCi3EG0Dk/20isrV/abUmIAWj jc7cMGMhXlRXCRdlaUBC/ArPGVlzsfZPuaqdurxMi1MRu5coA0SJmJAZxfIEOdD8 E0Iy5wL66CfX5qFe1excRCt9mJ9CaDUe30xroCVMeSUSGHbLD2ebte02WutOmp2D 2r3e8TNS+loaIV/z8BcDMg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 17.7E.23264.9A392E85; Mon, 3 Apr 2017 11:25:46 -0700 (PDT) X-AuditID: 11ab0216-e218d9a000005ae0-97-58e293a97095 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay6.apple.com (Apple SCV relay) with SMTP id 87.77.31597.8A392E85; Mon, 3 Apr 2017 11:25:45 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.71.197] (unknown [17.153.71.197]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONU004LLJ6WJI50@nwk-phonehomebzp-sz01.apple.com>; Mon, 03 Apr 2017 11:25:44 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> Date: Mon, 03 Apr 2017 11:25:44 -0700 Cc: Jim Schaad , Daniel Migault , "spasm@ietf.org" , IPsecME WG , "saag@ietf.org" , "tls@ietf.org" Message-id: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> To: "curdle@ietf.org" X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUi2FAYpbtq8qMIg6eLOS22LpzFbDFl+h42 i9XTv7NZ7N/ygs1iSn8nk8W8a8kWn853MTqwe2ycM53N49fXq2weS5b8ZApgjuKySUnNySxL LdK3S+DKWHdpGXPBNKmKA4s+MTcwzhDtYuTkkBAwkdg4ez4jiC0ksI9R4vD+EJj4ko+/2LoY uYDixxglXmzbzgyS4BUQlPgx+R5LFyMHB7OAvMTB87IgYWYBLYnvj1pZIOoXMklsPnKNFSQh LCAt0XXhLpQdIHHxyH1mkF42oIYDa4xAwpwCfhKPLr8GK2ERUJWYvOczE8gcZoHbjBLzpq1h hdhrI/F/2SxmiEOBDjp7rATEFhFQlzhxaAcrxNGyEp+e/2QHaZYQuM4m8Wj+TrYJjMKzkNw9 C+HuWUjuXsDIvIpRODcxM0c3M8/ISC+xoCAnVS85P3cTIygqVjOJ7WC899rwEKMAB6MSD69H 96MIIdbEsuLK3EOM0hwsSuK8InfvRQgJpCeWpGanphakFsUXleakFh9iZOLglGpgVI85Zvnm Qf3Fro21ufJsll3bDSWvSr3eePS/9b8FBTsPG7/uuukyfZbULd7p11Kf6VTPj524XUWf98zB UNHEF3xpC4KTmu5uyLxfcILvsWLLVodHBxiF/9wL6pO6F/h376ceJg8RLuZL2lXec/dddWOy tDrzU31C6bar8j92vHgwsauSv255oxJLcUaioRZzUXEiAHCmXpZrAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUiON3OQXfl5EcRBo/28lpsXTiL2WLK9D1s Fqunf2ez2L/lBZvFlP5OJot515ItPp3vYnRg99g4Zzqbx6+vV9k8liz5yRTAHMVlk5Kak1mW WqRvl8CVse7SMuaCaVIVBxZ9Ym5gnCHaxcjJISFgIrHk4y+2LkYuDiGBY4wSL7ZtZwZJ8AoI SvyYfI+li5GDg1lAXuLgeVmQMLOAlsT3R60sEPULmSQ2H7nGCpIQFpCW6LpwF8oOkLh45D4z SC8bUMOBNUYgYU4BP4lHl1+DlbAIqEpM3vOZCWQOs8BtRol509awQuy1kfi/bBbYDWAHnT1W AmKLCKhLnDi0gxXiaFmJT89/sk9gFJiF5NRZCKfOQnLqAkbmVYwCRak5iZVmeokFBTmpesn5 uZsYQUHcUBi1g7FhudUhRgEORiUe3gVOjyKEWBPLiitzDzFKcDArifBemQgU4k1JrKxKLcqP LyrNSS0+xFgF9MBEZinR5HxghOWVxBuamBiYGBubGRubm5hTRVhJnDen/F6EkEB6Yklqdmpq QWoRzHImDk6pBkbZIIlSxetqol5XrE8XeD/4xmT/LPTutbxJf5alF9/Ml/V4+0f2xt412/6l L+ZecLv6VjBb+M49uV1buaZLzo3fkrpj6cbuP5Pvzmlwl3AQ3d9hp6Mfc9p37UwLbim1iyXy pf2S3C7HjCeEMOgaqVxI8jmjw297as+hwvXvel/fCL1nGMpTJ6vEUpyRaKjFXFScCADgdmvP vQIAAA== Archived-At: Subject: Re: [TLS] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 03 Apr 2017 18:25:50 -0000 Thanks for the update! I've reviewed -04 and I think the draft is ready to move forward. Regards, David Schinazi > On Mar 28, 2017, at 15:43, Daniel Migault wrote: > > Hi, > > Thank you Jim for the update. Here is the version resulting from the discussion we had during the WG meeting yesterday. Please review the document and provide your feed backs by April 4 so we can move the draft to the IESG. > > Yours, > Daniel > > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Tuesday, March 28, 2017 4:40 PM > To: curdle@ietf.org > Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt > > Here is the promised updated draft. > > Changes: > 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign bit in public key.) 2. Remove all of the pre-hash text except to note that it does exist. > 3. No changes to the OID arc being used despite the agreement during the meeting. After the meeting, Russ, the chairs and I had a short talk and decided that this did not need to occur. The problem was only with getting new values assigned not with the current values which were already assigned. > > That should be the final issues in the draft > > Jim > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, March 28, 2017 4:31 PM >> To: Jim Schaad ; Simon Josefsson >> >> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >> >> >> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been >> successfully submitted by Jim Schaad and posted to the IETF repository. >> >> Name: draft-ietf-curdle-pkix >> Revision: 04 >> Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for >> use in the Internet X.509 Public Key Infrastructure >> Document date: 2017-03-28 >> Group: curdle >> Pages: 15 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04 >> >> Abstract: >> This document specifies algorithm identifiers and ASN.1 encoding >> formats for Elliptic Curve constructs using the Curve25519 and >> Curve448 curves. The signature algorithms covered are Ed25519 and >> Ed448. The key agreement algorithm covered are X25519 and X448. The >> encoding for Public Key, Private Key and EdDSA digital signature >> structures is provided. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Apr 3 22:09:55 2017 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 681A7126B6D for ; Mon, 3 Apr 2017 22:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=setec.io header.b=AkCj/bVk; dkim=pass (1024-bit key) header.d=setec.io header.b=AkCj/bVk 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 Ov637Y81I4g0 for ; Mon, 3 Apr 2017 22:09:51 -0700 (PDT) Received: from xmenrevolution.com (xmenrevolution.com [97.107.134.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99042126DCA for ; Mon, 3 Apr 2017 22:09:50 -0700 (PDT) Received: by xmenrevolution.com (Postfix, from userid 113) id 8147216A2C; Tue, 4 Apr 2017 01:09:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=setec.io; s=mail; t=1491282589; bh=QUdq4XqsGgDSO+6kJ74Y0+vuYCT624FyN58SQyQzPAo=; h=From:To:Subject:In-Reply-To:References:Date:From; b=AkCj/bVk1/bsIS03rv/Acj/rtsvQq95SRwSxGRcEUGKrL+DMkDlPUr2Hz2bqGb7K4 68VfKTwWcZVPHfkKOVSbnrl0s6I+Aafyelhlr37vVDzdITtCE6C6sg1g+Qa7L3VkqZ kTUvMfHNs+QFmvWXDJTTysz/y16OAZgty+mQFFSs= Received: from agartha (unknown [216.15.121.176]) by xmenrevolution.com (Postfix) with ESMTPSA id E98D016A13; Tue, 4 Apr 2017 01:09:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=setec.io; s=mail; t=1491282589; bh=QUdq4XqsGgDSO+6kJ74Y0+vuYCT624FyN58SQyQzPAo=; h=From:To:Subject:In-Reply-To:References:Date:From; b=AkCj/bVk1/bsIS03rv/Acj/rtsvQq95SRwSxGRcEUGKrL+DMkDlPUr2Hz2bqGb7K4 68VfKTwWcZVPHfkKOVSbnrl0s6I+Aafyelhlr37vVDzdITtCE6C6sg1g+Qa7L3VkqZ kTUvMfHNs+QFmvWXDJTTysz/y16OAZgty+mQFFSs= From: Harlan Lieberman-Berg To: "Fries\, Steffen" , TLS WG In-Reply-To: References: Date: Tue, 04 Apr 2017 01:09:48 -0400 Message-ID: <87inmkrc6b.fsf@setec.io> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 05:09:53 -0000 "Fries, Steffen" writes: > The reason I'm asking is that in industrial communication it is often > sufficient to have source authentication and message integrity while > probes on the network are still able to monitor the traffic for > certain properties or verify allowed exchanges. Hello Steffen, We've had a couple of discussions about this on the mailing list before. (See especially the "Industry Concerns about TLS 1.3" email thread starting with DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com). At this point, I don't think there's much of an appetite to be adding support for null-encryption cipher suites into TLS 1.3. In a quick summary of the 100+ message thread, the impression I got from the conversation was that the WG feels there's too much foot-gun potential from null cipher suites and that the risk was too high and the concerns brought up too late. Sincerely, -- Harlan Lieberman-Berg ~hlieberman From nobody Tue Apr 4 01:58:43 2017 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 9DBBC1273B1 for ; Tue, 4 Apr 2017 01:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 9Z4AsrJzAXFg for ; Tue, 4 Apr 2017 01:58:39 -0700 (PDT) Received: from vader.rez-gif.supelec.fr (mail.rez-gif.supelec.fr [160.228.154.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEA5128708 for ; Tue, 4 Apr 2017 01:58:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vader.rez-gif.supelec.fr (Postfix) with ESMTP id D6E3141B20 for ; Tue, 4 Apr 2017 10:58:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at vader.rez-gif.supelec.fr Received: from vader.rez-gif.supelec.fr ([127.0.0.1]) by localhost (mail.rez-gif.supelec.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4AyjVW9agr4 for ; Tue, 4 Apr 2017 10:58:36 +0200 (CEST) Received: from [10.66.0.230] (unknown [103.246.99.49]) (Authenticated sender: arnaud.venturi) by vader.rez-gif.supelec.fr (Postfix) with ESMTPSA id 97CF241AA7 for ; Tue, 4 Apr 2017 10:58:35 +0200 (CEST) References: <1e493a03-6843-9afa-fbcb-e8659f0f4184@rez-gif.supelec.fr> From: Arnaud Venturi To: tls@ietf.org Message-ID: Date: Tue, 4 Apr 2017 18:58:33 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------75FFF0815A6116D47D84516D" Archived-At: Subject: Re: [TLS] Remove deprecated fields in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 08:58:43 -0000 This is a multi-part message in MIME format. --------------75FFF0815A6116D47D84516D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit This was infact the idea, even I thought of the gain much more in terms of removing something useless than in gaining a few bytes. Anyway, thanks for your opinions and your time ! -- Arnaud On 04/04/2017 03:10 AM, Eric Rescorla wrote: > I agree with David. This seems like a low value change > > On Mon, Apr 3, 2017 at 9:36 AM, David Benjamin > wrote: > > On Mon, Apr 3, 2017 at 12:29 AM Benjamin Kaduk > wrote: > > On 04/02/2017 03:33 AM, Arnaud Venturi wrote: >> I could not think of any security or interoperability issue with this >> proposal, the only drawback I can see being the slight complexity added >> in ClientHello parsing. > > The ClientHello message needs to be interpreted in the same > way by TLS servers running all versions of TLS. A TLS 1.0 > server would not know to use the changed interpretation of the > fields and would fail to negotiate a connection. Basically, > no change in the format is possible while preserving the > backwards and forwards compatibility of version negotiation. > > > I believe the idea is that, if you support TLS 1.2 and below, you > send a 1.2-compatible ClientHello. If you don't, then you send the > proposed ClientHello. Servers would be required to support both > formats. > > This change would save us all of 3 bytes in the ClientHello, so my > feeling is this isn't worth the trouble of having two formats and > all the trouble that entails. (Servers having to parse both > formats, code in servers that won't be exercised for years, > clients worrying about whether servers implemented that, etc.) > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --------------75FFF0815A6116D47D84516D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This was infact the idea, even I thought of the gain much more in terms of removing something useless than in gaining a few bytes.

Anyway, thanks for your opinions and your time !


--
Arnaud

On 04/04/2017 03:10 AM, Eric Rescorla wrote:
I agree with David. This seems like a low value change

On Mon, Apr 3, 2017 at 9:36 AM, David Benjamin <davidben@google.com> wrote:
On Mon, Apr 3, 2017 at 12:29 AM Benjamin Kaduk <bkaduk@akamai.com> wrote:
On 04/02/2017 03:33 AM, Arnaud Venturi wrote:
I could not think of any security or interoperability issue with this
proposal, the only drawback I can see being the slight complexity added
in ClientHello parsing.

The ClientHello message needs to be interpreted in the same way by TLS servers running all versions of TLS.  A TLS 1.0 server would not know to use the changed interpretation of the fields and would fail to negotiate a connection.  Basically, no change in the format is possible while preserving the backwards and forwards compatibility of version negotiation.
I believe the idea is that, if you support TLS 1.2 and below, you send a 1.2-compatible ClientHello. If you don't, then you send the proposed ClientHello. Servers would be required to support both formats.

This change would save us all of 3 bytes in the ClientHello, so my feeling is this isn't worth the trouble of having two formats and all the trouble that entails. (Servers having to parse both formats, code in servers that won't be exercised for years, clients worrying about whether servers implemented that, etc.)

David

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--------------75FFF0815A6116D47D84516D-- From nobody Tue Apr 4 03:48:21 2017 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 598A2128D44 for ; Tue, 4 Apr 2017 03:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 bvuhx0yTfrEx for ; Tue, 4 Apr 2017 03:48:18 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56671294BC for ; Tue, 4 Apr 2017 03:48:14 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id v34AmCnv010080 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 4 Apr 2017 12:48:12 +0200 Received: from DEFTHW99ERMMSX.ww902.siemens.net (defthw99ermmsx.ww902.siemens.net [139.22.70.142]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id v34AmCSU031146 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Apr 2017 12:48:12 +0200 Received: from DENBGAT9ERDMSX.ww902.siemens.net (139.22.70.85) by DEFTHW99ERMMSX.ww902.siemens.net (139.22.70.142) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 4 Apr 2017 12:48:12 +0200 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.223]) by DENBGAT9ERDMSX.ww902.siemens.net ([139.22.70.85]) with mapi id 14.03.0339.000; Tue, 4 Apr 2017 12:48:11 +0200 From: "Fries, Steffen" To: Harlan Lieberman-Berg , TLS WG Thread-Topic: [TLS] Support of integrity only cipher suites in TLS 1.3 Thread-Index: AdKsldO7ZRItAwyZRXCzcLu6YsWN5QAWxckAAAjAWuA= Date: Tue, 4 Apr 2017 10:48:11 +0000 Message-ID: References: <87inmkrc6b.fsf@setec.io> In-Reply-To: <87inmkrc6b.fsf@setec.io> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 10:48:20 -0000 Hello Harlan, thank you for the information. I will go back to the discussion and read it= to get a better understanding about the reasoning. I had a peek into 3 or = 4 emails and there were centered around the deprecation of RSA encrypted k= ey exchange. This is different from what I had in mind. You mentioned null-= cipher, which would be the choice I would see. Yes, maybe it is too late to= bring this issue into the discussion. Nevertheless, as there is a need for= network monitoring it would be easier to have the monitoring on an integri= ty protected connection, while the traffic is additionally encrypted when c= rossing public networks. This is the intended approach for the scenario I = described for Inter Control Center communication. This would allow for non= -intrusive monitoring instead of a distinct termination point, which breaks= end-to-end integrity (if not provided on higher layers) also influences th= e end-to-end performance. I see that the integrity only is a problem for ce= rtain other scenarios, but having the flexibility in the protocol would all= ow to make a decision about the preferred cipher suites for a specific use = case based on a security policy.=20 Best regards Steffen -----Original Message----- From: Harlan Lieberman-Berg [mailto:hlieberman@setec.io]=20 Sent: Dienstag, 4. April 2017 07:10 To: Fries, Steffen (CT RDA ITS); TLS WG Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 "Fries, Steffen" writes: > The reason I'm asking is that in industrial communication it is often=20 > sufficient to have source authentication and message integrity while=20 > probes on the network are still able to monitor the traffic for=20 > certain properties or verify allowed exchanges. Hello Steffen, We've had a couple of discussions about this on the mailing list before. (See especially the "Industry Concerns about TLS 1.3" email thread starting= with DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.ou= tlook.com). At this point, I don't think there's much of an appetite to be adding suppo= rt for null-encryption cipher suites into TLS 1.3. In a quick summary of the 100+ message thread, the impression I got from th= e conversation was that the WG feels there's too much foot-gun potential fr= om null cipher suites and that the risk was too high and the concerns broug= ht up too late. Sincerely, -- Harlan Lieberman-Berg ~hlieberman From nobody Tue Apr 4 08:39:36 2017 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 3B3181293F8 for ; Tue, 4 Apr 2017 08:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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=apple.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 rkvqy02iOfqB for ; Tue, 4 Apr 2017 08:39:25 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1041293E9 for ; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491320364; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=c3Ej7qso2fQl3ZbvjqAnUcD43bbgy/FW5MdFSflIKOI=; b=Az5VdoBa9xGr0geZ5oV3rxbIjbJ0MAZo0P+MLGJ3egzs0peDuIWvt/TREJhlTKjy liMh04yfEphrtXqjZazrZ68N6VM1NpUW+qfZVc1ZZOfSu1bNM4vtGpu4ituLOO+g uqWLrSzSqhMHHKPiFc+K2UjCDApqyDXgByufhpi5jDZoYP4fEZdwqP2nL7HEErHO 4KZEVvx6/FT3i5CVgTPZe8HSxxJHKUTeJuUBM5SCo4+IcLz0UqDpAklIgj7uZR8w JuPmlIbwtu+b1Z+YKeBhKIKytPQ2C/LCCMZcODiVRsWhoBGdETkx7jdzzbpat5yR 9U4EjEDs0rQ5yQy+41siOw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 47.2D.25383.C2EB3E85; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) X-AuditID: 11973e12-003389a000006327-80-58e3be2c8244 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay2.apple.com (Apple SCV relay) with SMTP id C5.7C.06512.C2EB3E85; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FllJHYsVcP3xBGnsK7b52A)" Received: from [17.153.62.197] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONW00H6265NOG30@nwk-mmpp-sz10.apple.com>; Tue, 04 Apr 2017 08:39:24 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <87BF9C95-B970-4579-AC73-A5E1EC7F2BF8@apple.com> Date: Tue, 04 Apr 2017 08:39:23 -0700 In-reply-to: Cc: "curdle@ietf.org" , IPsecME WG , Daniel Migault , Jim Schaad , "spasm@ietf.org" , "tls@ietf.org" , "saag@ietf.org" To: David Schinazi References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUi2FDorKuz73GEwY9N0hZbF85itpgyfQ+b xerp39ks9m95wWYxpb+TyWLetWSLT+e7GB3YPTbOmc7m8evrVTaPJUt+MgUwR3HZpKTmZJal FunbJXBlNC08w1zwbjJjxbp/81gaGGc2MXYxcnBICJhI/FqR28XIxSEksJdRYuqn/axdjJxg 8d5dn5khEocYJSbufgeW4BUQlPgx+R4LiM0sECbx581Jdoiir4wSW3/1s4FMFRaQkNi8JxGk hk1AReL4tw3MEL02Em+2f2cHsYUFAiQuHrkPFmcRUJXofDcVbCangK3E8slbwBYzCzQwSbyZ /JcJJCEioCGxrWkBK8Syn4wSG3s+QJ0qK9G9cBpYh4TAdzaJNQf/s05gFJqF5NpZSK6FsLUk vj9qBYpzANnyEgfPy0KENSWe3fsEVaIt8eTdBdYFjGyrGIVyEzNzdDPzTPQSCwpyUvWS83M3 MYJiabqd0A7GU6usDjEKcDAq8fBemPE4Qog1say4MvcQozQHi5I4b8CdexFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGHX0H9dtW+b2u3+LfH/h9ezVyQeKj1zyMd+l3N1rbTZtEd/jbRyx Dxt2f2iQTnb4/Obw/0Mr+C+y1T3O3HPRZFaID9vfyPrXdz5uS9l0KWRCqaHxl2eLS0Vml0xU 0BPe3Vrq6VkRJH/g7l3tS7cPnAuIfN/4dpNVjlCnldK8j3VXhJQsZY6GLlRiKc5INNRiLipO BAAkoxtAhgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUi2FBcpauz73GEwelZwhZbF85itpgyfQ+b xerp39ks9m95wWYxpb+TyWLetWSLT+e7GB3YPTbOmc7m8evrVTaPJUt+MgUwR3HZpKTmZJal FunbJXBlNC08w1zwbjJjxbp/81gaGGc2MXYxcnJICJhI9O76zNzFyMUhJHCIUWLi7nesIAle AUGJH5PvsYDYzAJhEn/enGSHKPrKKLH1Vz9bFyMHh7CAhMTmPYkgNWwCKhLHv21ghui1kXiz /Ts7iC0sECBx8ch9sDiLgKpE57upYDM5BWwllk/eAraYWaCBSeLN5L9MIAkRAQ2JbU0LWCGW /WSU2NjzgRXiVFmJ7oXTmCcw8s9CcuAsJAdC2FoS3x+1AsU5gGx5iYPnZSHCmhLP7n2CKtGW ePLuAusCRrZVjAJFqTmJlUZ6iQUFOal6yfm5mxjBwV/ovIPx2DKrQ4wCHIxKPLwXZjyOEGJN LCuuzAWGEgezkgiv/R6gEG9KYmVValF+fFFpTmrxIcaJjEBvTmSWEk3OB8ZmXkm8oYmJgYmx sZmxsbmJOS2FlcR5c8rvRQgJpCeWpGanphakFsEcxcTBKdXA6MM4uzd10kED8clhtuwcE0Tm 3l874yDPz7fiXFtj7t/5xchbnqRSZ3HiVe2sirzO+0KNblNdp/h+/rtcqLW0ifXP8l2n7GuW 5fcpXi9KSNrREhZvty6bZZNW9pL6DImZ18xPbWqdtlpPxLVrt+7lYLkuWTZp7Y0/3J0ftvzM Snsu3p3/VGepEktxRqKhFnNRcSIAtItIifECAAA= Archived-At: Subject: Re: [TLS] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 15:39:27 -0000 --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I've gone through my review of the draft as well, and I think this version looks good! Thanks, Tommy > On Apr 3, 2017, at 11:25 AM, David Schinazi wrote: > > Thanks for the update! > > I've reviewed -04 and I think the draft is ready to move forward. > > Regards, > David Schinazi > > >> On Mar 28, 2017, at 15:43, Daniel Migault > wrote: >> >> Hi, >> >> Thank you Jim for the update. Here is the version resulting from the discussion we had during the WG meeting yesterday. Please review the document and provide your feed backs by April 4 so we can move the draft to the IESG. >> >> Yours, >> Daniel >> >> -----Original Message----- >> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Tuesday, March 28, 2017 4:40 PM >> To: curdle@ietf.org >> Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt >> >> Here is the promised updated draft. >> >> Changes: >> 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign bit in public key.) 2. Remove all of the pre-hash text except to note that it does exist. >> 3. No changes to the OID arc being used despite the agreement during the meeting. After the meeting, Russ, the chairs and I had a short talk and decided that this did not need to occur. The problem was only with getting new values assigned not with the current values which were already assigned. >> >> That should be the final issues in the draft >> >> Jim >> >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Tuesday, March 28, 2017 4:31 PM >>> To: Jim Schaad ; Simon Josefsson >>> >>> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >>> >>> >>> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been >>> successfully submitted by Jim Schaad and posted to the IETF repository. >>> >>> Name: draft-ietf-curdle-pkix >>> Revision: 04 >>> Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for >>> use in the Internet X.509 Public Key Infrastructure >>> Document date: 2017-03-28 >>> Group: curdle >>> Pages: 15 >>> URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ >>> Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04 >>> >>> Abstract: >>> This document specifies algorithm identifiers and ASN.1 encoding >>> formats for Elliptic Curve constructs using the Curve25519 and >>> Curve448 curves. The signature algorithms covered are Ed25519 and >>> Ed448. The key agreement algorithm covered are X25519 and X448. The >>> encoding for Public Key, Private Key and EdDSA digital signature >>> structures is provided. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
I've gone through my review of the draft as = well, and I think this version looks good!

Thanks,
Tommy

On Apr 3, 2017, at 11:25 AM, David Schinazi = <dschinazi@apple.com> wrote:

Thanks for the update!
I've reviewed -04 and I think the draft is ready = to move forward.

Regards,
David Schinazi

On Mar 28, 2017, at 15:43, = Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi, 

Thank you Jim for the update. Here is the = version resulting from the discussion we had during the WG meeting = yesterday.  Please review the document and provide your feed backs = by April 4 so we can move the draft to the IESG. 

Yours, 
Daniel

-----Original = Message-----
From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim = Schaad
Sent: Tuesday, March 28, 2017 4:40 PM
To: curdle@ietf.org
Subject: [Curdle] FW: New = Version Notification for draft-ietf-curdle-pkix-04.txt

Here is the promised updated draft.

Changes:
1.  Fixed an example that David = Benjamin found was wrong.  (Incorrect sign bit in public key.) 2. =  Remove all of the pre-hash text except to note that it does = exist.
3.  No changes to the OID arc being used = despite the agreement during the meeting.  After the meeting, Russ, = the chairs and I had a short talk and decided that this did not need to = occur.  The problem was only with getting new values assigned not = with the current values which were already assigned.

That should be the final issues in the draft

Jim


-----Original Message-----
From: = internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: = Tuesday, March 28, 2017 4:31 PM
To: Jim Schaad <ietf@augustcellars.com>; Simon Josefsson 
<simon@josefsson.org>
Subject: New = Version Notification for draft-ietf-curdle-pkix-04.txt


A new version of I-D, = draft-ietf-curdle-pkix-04.txt has been 
successfully = submitted by Jim Schaad and posted to the IETF repository.

Name: draft-ietf-curdle-pkix
Revision: 04
Title: Algorithm Identifiers for = Ed25519, Ed448, X25519 and X448 for
use in the Internet = X.509 Public Key Infrastructure
Document date: = 2017-03-28
Group: curdle
Pages: 15
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.= txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/Htmlized:       https://tools.ietf.org/html/draft-ietf-curdle-pkix-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04=
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix-04

Abstract:
 This = document specifies algorithm identifiers and ASN.1 encoding
 formats for Elliptic Curve constructs using the = Curve25519 and
 Curve448 curves.  The signature = algorithms covered are Ed25519 and
 Ed448.  The = key agreement algorithm covered are X25519 and X448.  The
 encoding for Public Key, Private Key and EdDSA digital = signature
 structures is provided.




Please note that = it may take a couple of minutes from the time of 
submission = until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

= --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A)-- From nobody Tue Apr 4 09:08:46 2017 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 12F391294C3 for ; Tue, 4 Apr 2017 09:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 TLi1Iicf11Y5 for ; Tue, 4 Apr 2017 09:08:41 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DFF127775 for ; Tue, 4 Apr 2017 09:08:41 -0700 (PDT) Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Tue, 04 Apr 2017 18:08:40 +0200 id 0000000000000060.0000000058E3C508.00002C64 Date: Tue, 4 Apr 2017 18:08:38 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20170404180838.08ca99cc@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 16:08:45 -0000 On Mon, 3 Apr 2017 16:17:45 +0000 "Fries, Steffen" wrote: > The reason I'm asking is that in industrial communication it is often > sufficient to have source authentication and message integrity while > probes on the network are still able to monitor the traffic for > certain properties or verify allowed exchanges. An example is ICCP > for inter control center communication. The two control center are > connected via an IPSec tunnel terminated in the DMZ. The desire is to > have the TLS tunnel end-to-end to allow for source authentication and > also for message integrity, while doing traffic inspection in the > DMZ. There exist other scenarios, with a similar requirement. Adding such a mode would add additional complexity that might lead to vulnerabiltiies, e.g. implementations that can be tricked into using a nonencrypted mode. It's been a trend in the tls working group to a) reduce complexity when possible. b) not try to accomodate obscure use cases that aren't relevant for the majority of TLS use cases. Thus I assume a null cipher won't find support here. If you want to have traffic inspection with TLS imho the right way is to support that at the end points (let alone any arguments why you're doing traffic inspection in the first place and whether those reasons are good ones). If you don't like that then TLS may be not the right protocol for your use case. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Tue Apr 4 10:10:01 2017 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 B27E0127A97 for ; Tue, 4 Apr 2017 10:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham 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 oruKVSreqZOK for ; Tue, 4 Apr 2017 10:09:58 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 DE8E2129412 for ; Tue, 4 Apr 2017 10:09:57 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id p77so64619958ywg.1 for ; Tue, 04 Apr 2017 10:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=j7iNJ4LpKeHyjeNWlTlcEXmeMAZI52X/R72XSq3AKfQ=; b=BpZBkmkTDDjmnu8+t9h6QyeBsIthaQ0ZbUfWGS6yH4HNKUFjcG13ESdk75COgntAFA 6GlTnEmAOEjaWq+YE4y0r+2jIKoeUsqT+IxfCUCekWvC384G3a969aBTGIfiEdrA1biT 8RLxecV91xI5w3hwhLWxbF82jHgKubd3xoKiyc2NRO+NAYA+yDiGAFLb0QOUAgEn2t9R 9Ix9MAuD9v5tzloAxxVpmMF5pS8OHgVcqzkOCHADefPNt5/KHcn2quR1nWZO1y01O9iq MUilsH7a5LPK9RLAZqdba7KR6nE8Odpk9//tIXu8k0OrVRb+Rt2kg/ObzfXRb9XAyPao K8jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=j7iNJ4LpKeHyjeNWlTlcEXmeMAZI52X/R72XSq3AKfQ=; b=LN/YMHE530Al3iDvRkqrOD4qiXmbg6liBKLIQQl8tUC97t+TOLlIL3RpM2arZ6O2ED 4q/wzjjOFxtZPMQ/7C9AmPJYdxzvG7IABD2Q1n5hLFrB9LXEC/4MDZVNi0kbb1S9oXq0 dUbG+rJdndakmaH0GO0KlzoOtN2G2ICl96ezznLZw7Lbd49o6FCwlHYu2zFlNlZ88Q6r m0dd/ahLmckwwvWNzAwDTWw/ow8rpm7fUa0EffU7ZEWga1KFjyC3LgAdeoy21aWmoeUm j+0A+UG2pVBh1BOyFnplZyr/HYhGZBbwaOv2LQEvs1UzG4P8vwnCZrvKBfj16mpIAndv D5FQ== X-Gm-Message-State: AFeK/H3S6grIRMNVXa4odb9qum9PudCF2Mj+h6BXDzhddWfzFgGY64p0Yb/F4Ec5azHFF3y47wT/SkBc5yaqAg== X-Received: by 10.129.108.214 with SMTP id h205mr15393401ywc.71.1491325796823; Tue, 04 Apr 2017 10:09:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 4 Apr 2017 10:09:16 -0700 (PDT) From: Eric Rescorla Date: Tue, 4 Apr 2017 10:09:16 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114e81dc5d47e5054c5a5846 Archived-At: Subject: [TLS] PRs for review X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 17:10:00 -0000 --001a114e81dc5d47e5054c5a5846 Content-Type: text/plain; charset=UTF-8 Hi folks, As discussed in the meeting, and with an assist from MT, I've prepared two small PRs: * An extension by the client to negotiated post-handshake client auth: https://github.com/tlswg/tls13-spec/pull/933 * Explicitly describing how RFC 7250 Raw Public Keys work with TLS 1.3 and removing extensions which no longer work from the table. https://github.com/tlswg/tls13-spec/pull/932 Target merge date: Thursday. -Ekr --001a114e81dc5d47e5054c5a5846 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

As discussed in the meeting, = and with an assist from MT, I've prepared
two small PRs:

* An extension by the client to negotiated post-handsh= ake client auth:
* Explicitly describing how RFC 7250 Raw Public Keys work with = TLS
1.3 and removing extensions which no longer work from the tab= le.

T= arget merge date: Thursday.

-Ekr

--001a114e81dc5d47e5054c5a5846-- From nobody Tue Apr 4 10:30:04 2017 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 4F3F21296E5 for ; Tue, 4 Apr 2017 10:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 F6N_XNxRCxHZ for ; Tue, 4 Apr 2017 10:29:56 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDFF129463 for ; Tue, 4 Apr 2017 10:29:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id DFE081FB1E; Tue, 4 Apr 2017 20:29:54 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id gixD7mJWfwr0; Tue, 4 Apr 2017 20:29:54 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 99DEC286; Tue, 4 Apr 2017 20:29:54 +0300 (EEST) Date: Tue, 4 Apr 2017 20:29:53 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170404172953.GA7867@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] PRs for review X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 17:29:59 -0000 On Tue, Apr 04, 2017 at 10:09:16AM -0700, Eric Rescorla wrote: > > * Explicitly describing how RFC 7250 Raw Public Keys work with TLS > 1.3 and removing extensions which no longer work from the table. > https://github.com/tlswg/tls13-spec/pull/932 The things that seem missing: - Specifying that OpenPGP type MUST NOT be used in TLS 1.3 (client MAY advertise if it supports TLS 1.2, server MUST NOT select). - Correcting client_certificate_type to be CR,CERT (and not CH,EE). This becomes practicularly relevant if any new certificate type is ever defined. -Ilari From nobody Tue Apr 4 10:59:40 2017 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 EEDDD126DD9 for ; Tue, 4 Apr 2017 10:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham 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 qjUVFxfhlH6T for ; Tue, 4 Apr 2017 10:59:37 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 C3DA612706D for ; Tue, 4 Apr 2017 10:59:36 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id i203so65542969ywc.3 for ; Tue, 04 Apr 2017 10:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TGYzWTkktFnpudIyq4IMMrdGOWnWCRhU7fAJttnrHi4=; b=UjLHI1EqTkf2vqB2WJCl3syZrlvCJU6K1Dr6UW1IhgML7XF+27DFfGRPFDhNeXyR2R DjQ1hS0EEv8bWK0TC+XVFx9/T95MB6iKxIzKGeTUfY6814eWR81ReNXuH+xp5hotXVL7 Q3rJrAX+TPI+hy7XQU2PXdATqVmbia+bzuOsLh9gKR5YyJAjARqIV/9OW79i+F0X+UrJ cATTy9i/+8J08K4OnYcP1S77ZnY8KOgMyNPSnoOPjf1NpmuOCJqfSyW7nwbi6ScRszBF S0we0Sag4tLr7fNUPog9Vi1EUUMpcsFrqmto5mniSnccNjoHGDMzj6azn9oNzOgoP1F6 m/RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TGYzWTkktFnpudIyq4IMMrdGOWnWCRhU7fAJttnrHi4=; b=UrOfQzJKpeEH9VWkmYWtAU0qt2uHOb9yVM8fhUsa121T7IO3c8ZHDUuYKO60BSBr16 9KAyULwDet4BUw4aYRY90++L5agxwoyxHqdKsBhor4UHgmvUTxu2vTV3EIBPQna2+u85 pL50WXWJLXNm1WJs+SUZDlYmjJMzN11dFORZklVB4vG8YQKdS+wIb/YKvVGBunX/IIcA kSXcNqdiOY7DqD5thLOqERGZVwhba94rE229u/O5DhKxjHit4J6lW7yfyAX3qdXKC2mD aJkES+Sih3EF37vwBz2EkokY/aaB/WlnHR3iIGdSWfjHVwEgh1hU4cWlsZYNYhJoWvys QnQg== X-Gm-Message-State: AFeK/H1AfnOwTqPzSw+ST7dbv3ABbqkXlnPPOHWmBxncezvAv/5vtaX6+6Dvk6WpeibLNdZOWarZoYHPbrfOnw== X-Received: by 10.129.152.22 with SMTP id p22mr17288117ywg.276.1491328776023; Tue, 04 Apr 2017 10:59:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 4 Apr 2017 10:58:55 -0700 (PDT) In-Reply-To: <20170404172953.GA7867@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170404172953.GA7867@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 4 Apr 2017 10:58:55 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0b8fb4f05911054c5b09d0 Archived-At: Subject: Re: [TLS] PRs for review X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 17:59:39 -0000 --94eb2c0b8fb4f05911054c5b09d0 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 4, 2017 at 10:29 AM, Ilari Liusvaara wrote: > On Tue, Apr 04, 2017 at 10:09:16AM -0700, Eric Rescorla wrote: > > > > * Explicitly describing how RFC 7250 Raw Public Keys work with TLS > > 1.3 and removing extensions which no longer work from the table. > > https://github.com/tlswg/tls13-spec/pull/932 > > The things that seem missing: > > - Specifying that OpenPGP type MUST NOT be used in TLS 1.3 (client > MAY advertise if it supports TLS 1.2, server MUST NOT select). Thanks. Good catch. > - Correcting client_certificate_type to be CR,CERT (and not CH,EE). > This becomes practicularly relevant if any new certificate type > is ever defined. > Thanks! -Ekr > > > -Ilari > --94eb2c0b8fb4f05911054c5b09d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--94eb2c0b8fb4f05911054c5b09d0-- From nobody Tue Apr 4 11:42:39 2017 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 8956B129417 for ; Tue, 4 Apr 2017 11:42:37 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 prBtTFAL4KX8 for ; Tue, 4 Apr 2017 11:42:36 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 06CEC12426E for ; Tue, 4 Apr 2017 11:42:36 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id p22so149692409qka.3 for ; Tue, 04 Apr 2017 11:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YT3iil9gtlElbvk+tA5+THlPRS+bSDjFj2nC3y8Umkk=; b=EADB5A56oDI5zKMferK2ZKx5QYUAuQ36EtKmCbgBHmz6mEutzrGZCklVz7PRcd/+ep nfm/lSzhySuWce56JUAoUoRsm4KDL3cdvKSsyvim7mOg1k2TA3ZdsTwAc0tDvJ6kiLKz ppXzwW/X7UtxgK4kK00vauL4zen52LDc8SLpc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YT3iil9gtlElbvk+tA5+THlPRS+bSDjFj2nC3y8Umkk=; b=XRg5bCHSFRwsOqHIY0nsqr6WNl708zwMqhmTG3LMYIE2iqJfD/7GER4oK5zXb5mv9W EXq8pKKGLw9llqaWOhG7cNaP8/Gbk229Pm0YZIslJ55FRPMo03XQ1mL9+eaiRGcbMrub RpTCIY53K4sAnnIpMGfEPpxYVCWOSgadY1xAhTKwaTaZ7f+3Q+VCUP3bUHRoDGqUFual y2pKvfkPtQ5Kzk7Av/tjbhuiEmFpugoFMKuU75UsMdbn5wqyxS1djVvwfqeX3HDGiwig 1goPlUtLxPE4HYVp8ju7Y0oaUaJ0I4TPnLadD3wfIkUd8F+J+0d0TGCTPXz4c+4WVBPk deUQ== X-Gm-Message-State: AFeK/H0oqZHWKHHRKJxyH77/+GcZu0RT5K8pHAEOccGHiRvAFSN0tXz0vsrTX4H0BRdmUg== X-Received: by 10.55.41.37 with SMTP id p37mr17686552qkh.51.1491331355212; Tue, 04 Apr 2017 11:42:35 -0700 (PDT) Received: from [172.16.0.18] ([96.231.222.158]) by smtp.gmail.com with ESMTPSA id g15sm12425390qte.58.2017.04.04.11.42.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 11:42:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Tue, 4 Apr 2017 14:42:32 -0400 Cc: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3884A267-2421-41A4-9FDD-FC16D79F5030@sn3rd.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] PRs for review X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 18:42:37 -0000 > On Apr 4, 2017, at 13:09, Eric Rescorla wrote: >=20 > and removing extensions which no longer work from the table. I=E2=80=99ll make sure to add these to the =E2=80=9Corphaned=E2=80=9D = list of registries in draft-ietf-tls-iana-registry-updates. spt= From nobody Tue Apr 4 16:02:42 2017 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 66D971271DF for ; Tue, 4 Apr 2017 16:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 boG5x4vcsXaI for ; Tue, 4 Apr 2017 16:02:38 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id BF030129421 for ; Tue, 4 Apr 2017 16:02:36 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2A849200017; Tue, 4 Apr 2017 23:02:36 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 1433F200001; Tue, 4 Apr 2017 23:02:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491346956; bh=BfbVUjXl/rCCrGq/t8LvHVcxN/UcgyECw5fLhvS2qvg=; l=7341; h=To:References:From:Date:In-Reply-To:From; b=JIq+P/2Gf87PnvBGPSKakDGT/JhyRaYha7e2pK4sZSnmezG281a8ojF5VJfI/tBp/ PqVnE3HFW60CfnzMnO5S94AJuJXqmnyBxKx6CBZw/0KPTO4BeuC8Es2ST3n1TPV0h3 PofYx9m0f0kECRXJOisF4uljbMT9xwdoOV22F43s= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 9C34F1E08C; Tue, 4 Apr 2017 23:02:35 +0000 (GMT) To: Subodh Iyengar , Brian Sniffen , "tls@ietf.org" References: From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 4 Apr 2017 18:02:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1ADC185C14B1BCF1609F48EA" Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 23:02:40 -0000 This is a multi-part message in MIME format. --------------1ADC185C14B1BCF1609F48EA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/01/2017 07:13 PM, Subodh Iyengar wrote: > Thanks for your question Brian. > > The motivation behind delegated credentials is to create a more > reasonable deployment model for short lived credentials. My apologies for being blunt, but that text reads like a solution in search of a problem. That is, what is expected to be achieved by having shorter-lived credentials? Is there a threat model for which having them brings security advantages, or are there operational concerns, or ... ? > [....] > This led us to think of whether we could deploy short lived > credentials with another approach. Once you can deploy short lived > credentials we found several use cases for these: > > * Removing private keys from currently trusted hosts and keeping them > in even more secure locations. In this way you could increase security > by moving keys from places they currently exist. > * You could make a security / performance by giving delegated > credentials to your less trusted locations where you could make the > tradeoff that if one of these is stolen it's valid only for a very > short period of time. > > I'm not too familiar with the cloud provider to service owner > trust model, but your idea of giving the cloud provider a delegated > credential instead of a longer lived certificate key sounds great. > > Delegated credentials bounds time, however if used with other > mechanisms you can make security protections even more robust. For > example you could give your cloud provider a delegated credential > bound to a certificate with a different origin. If you find that > something bad has happened you can stop routing traffic to that origin > as well. > These are also some useful analysis, but still leaves me wondering what the actual goal to be achieved is. Put another way, I assume that there is some attacker with some capabilities that will be stymied in some way by the deployment of delegated credentials, as compared to having real certificates/keys deployed to the machines that are going to get delegated credentials on them. But what benefit, and what are the attacker's capabilities? There is also an alternate world in which the TLS terminators should not have certificates/keys on them but it is okay to give them delegated credentials. Here, one benefit is clear: performance. But the attacker capabilities against which this is supposed to be useful/acceptable remain unclear. Can you share some more thoughts about which of these two pictures you have in mind, and what the attacker capabilities are in that scenario? Thanks, Ben --------------1ADC185C14B1BCF1609F48EA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/01/2017 07:13 PM, Subodh Iyengar wrote:
Thanks for your question Brian.

The motivation behind delegated credentials is to create a more reasonable deployment model for short lived credentials.

My apologies for being blunt, but that text reads like a solution in search of a problem.  That is, what is expected to be achieved by having shorter-lived credentials?  Is there a threat model for which having them brings security advantages, or are there operational concerns, or ... ?

[....]

This led us to think of whether we could deploy short lived credentials with another approach. Once you can deploy short lived credentials we found several use cases for these:

* Removing private keys from currently trusted hosts and keeping them in even more secure locations. In this way you could increase security by moving keys from places they currently exist.
* You could make a security / performance by giving delegated credentials to your less trusted locations where you could make the tradeoff that if one of these is stolen it's valid only for a very short period of time.

I'm not too familiar with the cloud provider to service owner trust model, but your idea of giving the cloud provider a delegated credential instead of a longer lived certificate key sounds great.

Delegated credentials bounds time, however if used with other mechanisms you can make security protections even more robust. For example you could give your cloud provider a delegated credential bound to a certificate with a different origin. If you find that something bad has happened you can stop routing traffic to that origin as well.


These are also some useful analysis, but still leaves me wondering what the actual goal to be achieved is.  Put another way, I assume that there is some attacker with some capabilities that will be stymied in some way by the deployment of delegated credentials, as compared to having real certificates/keys deployed to the machines that are going to get delegated credentials on them.  But what benefit, and what are the attacker's capabilities?

There is also an alternate world in which the TLS terminators should not have certificates/keys on them but it is okay to give them delegated credentials.  Here, one benefit is clear: performance.  But the attacker capabilities against which this is supposed to be useful/acceptable remain unclear.

Can you share some more thoughts about which of these two pictures you have in mind, and what the attacker capabilities are in that scenario?

Thanks,

Ben
--------------1ADC185C14B1BCF1609F48EA-- From nobody Tue Apr 4 16:20:58 2017 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 57B8E128D8B for ; Tue, 4 Apr 2017 16:20:56 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 H_TWDs52v-wZ for ; Tue, 4 Apr 2017 16:20:54 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id DF39E12940F for ; Tue, 4 Apr 2017 16:20:54 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A6BC5200032; Tue, 4 Apr 2017 23:20:54 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 907F0200001; Tue, 4 Apr 2017 23:20:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491348054; bh=2RUw6rXeKmOJBDE2MCEpz1JIiZwBBqBq/oMCgaegfQI=; l=2112; h=To:References:Cc:From:Date:In-Reply-To:From; b=wRG33jiIZiWGwpMY5xStP0yowb+Zbo9OaE5vYXM5NkMCWD7FoFvL6TmXHfMu/8yy7 JzN7J0+QKthIw8ICEe2Mx6r6Lqp8/ZJDvpzc7itT0PZvT53/f2Pjrregw/9Q8ppZrs 0/a8uSp4Kv3TYpFhalBYKO9CrLQBK+jQhe7lDdUQ= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 29F331E07C; Tue, 4 Apr 2017 23:20:54 +0000 (GMT) To: Hubert Kario , tls@ietf.org References: <025D3ABD-199F-421A-9265-6F960135A3B7@sn3rd.com> <228B1CCF-088B-4F4C-B2FD-A20036B9224A@akamai.com> <2454705.8d2estPYRD@pintsize.usersys.redhat.com> From: Benjamin Kaduk Message-ID: Date: Tue, 4 Apr 2017 18:20:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2454705.8d2estPYRD@pintsize.usersys.redhat.com> Content-Type: multipart/alternative; boundary="------------FC2A5DBB00EB9BF049B9F4ED" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 23:20:57 -0000 This is a multi-part message in MIME format. --------------FC2A5DBB00EB9BF049B9F4ED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/31/2017 08:40 AM, Hubert Kario wrote: > On Tuesday, 28 March 2017 08:23:33 CEST Kaduk, Ben wrote: >> On 3/13/17, 12:30, "Sean Turner" wrote: >> Do we want to add some commentary about the extant SHA1 collisions when we >> say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT? > > There still are non-insignificant number of Internet facing servers that > require SHA-1 being advertised for connection to be successful. > SHOULD NOT is a good compromise for it. Right. We could note that though SHA1 is "known to be broken", some servers currently require it, even though they ought to be moving away from it posthaste. -Ben --------------FC2A5DBB00EB9BF049B9F4ED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 03/31/2017 08:40 AM, Hubert Kario wrote:
On Tuesday, 28 March 2017 08:23:33 CEST Kaduk, Ben wrote:

On 3/13/17, 12:30, "Sean Turner" <sean@sn3rd.com> wrote:
Do we want to add some commentary about the extant SHA1 collisions when we
say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?

 
There still are non-insignificant number of Internet facing servers that 
require SHA-1 being advertised for connection to be successful.
SHOULD NOT is a good compromise for it.

Right.  We could note that though SHA1 is "known to be broken", some servers currently require it, even though they ought to be moving away from it posthaste.

-Ben
--------------FC2A5DBB00EB9BF049B9F4ED-- From nobody Tue Apr 4 16:44:05 2017 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 852111270A3 for ; Tue, 4 Apr 2017 16:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 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, HTML_OBFUSCATE_05_10=0.26, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 NhEHfdmPjZ00 for ; Tue, 4 Apr 2017 16:44:02 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 84E43127097 for ; Tue, 4 Apr 2017 16:44:02 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DF3DC433441; Tue, 4 Apr 2017 23:44:01 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id C928D43343E; Tue, 4 Apr 2017 23:44:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491349441; bh=Drx/lG5iGh1t86q9xvxdD40zu+Wx4/FCUHeNYtcTbfg=; l=4428; h=To:References:From:Date:In-Reply-To:From; b=YtpAz449untCbIwKlQQtnUuYm80vx39T5C0wj7gDKzAEPfWMwtmhqIfUBtaTauGK6 t/+kgp2WfoKZIL3YVVBLuy1koP4AXv1ejsymeGyzdzx9AQo+BR+As5QSA0j/L1mCcu eusFyYM/IbatQNimQCQCGmK/P7xbppniApZcwoxo= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 999141FC92; Tue, 4 Apr 2017 23:44:01 +0000 (GMT) To: Subodh Iyengar , "tls@ietf.org" References: <11F20304-A244-4362-9042-E6CC3EDD304A@akamai.com> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <117fce84-66f5-4a2e-99d0-2aa52852b726@akamai.com> Date: Tue, 4 Apr 2017 18:44:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------861B3EA4138BE5118365466D" Archived-At: Subject: Re: [TLS] review comments on draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 23:44:04 -0000 This is a multi-part message in MIME format. --------------861B3EA4138BE5118365466D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/29/2017 10:29 AM, Subodh Iyengar wrote: > > > > > Do we want to leave the valid SignatureSchemes as all that are > defined, or mention the Recommended column in the registry, or narrow > things even further? In other words, should we give some guidance for > how to select a scheme to use? > > It's restricted to the ones that are supported by the client in TLS > 1.3. I don't see TLS recommending signature algorithms to use beyond > section 4.2.3 that "rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD > NOT be offered.". What kind of a recommendation would you like to see. > Would love a pull request at https://github.com/ekr/tls-subcerts/pulls > to > get a general idea of what you would like to see. > > All I had in mind was like one sentence when talking about the interpretation of the 'scheme' field of DelegatedCredential: "The scheme is taken from the TLS SignatureSchemes registry [RFCTLS1.3], and schemes recommended for use in TLS are also recommended for use in delegated credentials." Arguably not needed at all, but perhaps gives a bit more clarity. -Ben --------------861B3EA4138BE5118365466D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/29/2017 10:29 AM, Subodh Iyengar wrote:



> Do we want to leave the valid SignatureSchemes as all that are defined, or mention the Recommended column in the registry, or narrow things even further?  In other words, should we give some guidance for how to select a scheme to use?

It's restricted to the ones that are supported by the client in TLS 1.3. I don't see TLS recommending signature algorithms to use beyond section 4.2.3 that "rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered.". What kind of a recommendation would you like to see. Would love a pull request at https://github.com/ekr/tls-subcerts/pulls to get a general idea of what you would like to see.



All I had in mind was like one sentence when talking about the interpretation of the 'scheme' field of DelegatedCredential: "The scheme is taken from the TLS SignatureSchemes registry [RFCTLS1.3], and schemes recommended for use in TLS are also recommended for use in delegated credentials."  Arguably not needed at all, but perhaps gives a bit more clarity.

-Ben
--------------861B3EA4138BE5118365466D-- From nobody Tue Apr 4 22:36:48 2017 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 70598129412 for ; Tue, 4 Apr 2017 22:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 NN89h2PWW8IR for ; Tue, 4 Apr 2017 22:36:43 -0700 (PDT) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E03128BA2 for ; Tue, 4 Apr 2017 22:36:41 -0700 (PDT) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id v355aO9D012231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Apr 2017 11:06:29 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id v355ZpLQ029649; Wed, 5 Apr 2017 11:05:51 +0530 Received: from webmail.cdac.in (wbms.pune.cdac.in [10.208.1.9]) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id v355ZnJL012159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Apr 2017 11:05:51 +0530 Date: Wed, 5 Apr 2017 11:05:46 +0530 (IST) From: Sankalp Bagaria Reply-To: Sankalp Bagaria To: tls@ietf.org Cc: R Balaji , "Bagaria, Sankalp" Message-ID: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1979_1883518451.1491370546157" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v- X-CDAC-PUNE-MailScanner-ID: v355ZpLQ029649 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.499, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_05 -0.50, HTML_MESSAGE 0.00, RP_MATCHES_RCVD -0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.798, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_50 0.00, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: v355aO9D012231 X-CDAC-PUNE-MailScanner-From: sankalp@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [TLS] Certificate compression draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 05:36:46 -0000 ------=_Part_1979_1883518451.1491370546157 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, How is Certificate Compression advantageous over tls cached-info extension? Only case I can think of is - when the certificate is being sent for the first time, it can be compressed. Since the client doesn't have a copy of the certificate, cached-info can't be used. Are there more cases where compression is useful? Another point that need to be seen is that the time required to compress/ decompress is not more than the savings got in transmitting a compressed certificate (smaller in size than complete certificate). Thanks and Regards, Sankalp Bagaria. On Mon, Mar 6, 2017 at 2:58 PM, Victor Vasiliev < vasilvv@google.com > wrote: > Certificate compression has been discussed on this list briefly before, > and > there was some interest in at least considering a draft for it. The draft > now > exists (co-authored by Alessandro and myself), and it can be found at: > > https://datatracker.ietf.org/doc/draft-ghedini-tls- > > certificate - compression / > [ GitHub repo: https://github.com/ghedo/tls-certificate-compression > ] > > The proposed scheme allows a client and a server to negotiate a compression > algorithm for the server certificate message. The scheme is purely opt-in > on > both sides. The current version of the draft defines zlib and Brotli > compression , both of which are well-specified formats with an existing > deployment experience. > > There are multiple motivations to compress certificates. The first one is > that > the smaller they are, the faster they arrive (both due to the transfer > time and > a decreased chance of packet loss). > > The second, and more interesting one, is that having small certificates is > important for QUIC in order to achieve 1-RTT handshakes while limiting the > opportunities for amplification attacks. Currently, TLS 1.3 over TCP > without > client auth looks like this: > > Round trip 1: client sends SYN, server sends SYN ACK > Here, the server provides its own random value which client will > have to echo in the future. > Round trip 2: client sends ACK, ClientHello, server sends > ServerHello...Finished > Here, ACK confirms to server that the client can receive packets and > is not > just spoofing its source address. Server can send the entire > ServerHello to > Finished flight. > > In QUIC, we are trying to merge those two rounds into one. The problem, > however, is that the ClientHello is one packet, and ServerHello...Finished > can > span multiple packets, meaning that this could be used as an amplification > attack vector since the client's address is not yet authenticated at this > point. > In order to address this, the server has to limit the number of packets it > sends > during the first flight (i.e. ServerHello...Finished flight). Since > certificates make up the majority of data in that flight, making them > smaller > can push them under the limit and save a round-trip. > > Cheers, > Victor. ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- ------=_Part_1979_1883518451.1491370546157 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Hello,
 
How is Certificate Compression advantageous over tls cached-info extension?
Only case I can think of is - when the certificate is being sent for the first time,
it can be compressed. Since the client doesn't have a copy of the certificate,
cached-info can't be used. Are there more cases where compression is useful?
 
Another point that need to be seen is that the time required to compress/
decompress is not more than the savings got in transmitting a compressed
certificate (smaller in size than complete certificate).
 
Thanks and Regards,
Sankalp Bagaria.
 
On Mon, Mar 6, 2017 at 2:58 PM, Victor Vasiliev < vasilvv@google.com > wrote:

>  Certificate   compression  has been discussed on this list briefly before, and
> there was some interest in at least considering a  draft  for it.  The  draft
> now
> exists (co-authored by Alessandro and myself), and it can be found at:
>
>  https://datatracker.ietf.org/doc/draft-ghedini-tls-
>  certificate - compression /
>   [ GitHub repo:  https://github.com/ghedo/tls-certificate-compression  ]
>
> The proposed scheme allows a client and a server to negotiate a  compression
> algorithm for the server  certificate  message.  The scheme is purely opt-in
> on
> both sides.  The current version of the  draft  defines zlib and Brotli
>  compression , both of which are well-specified formats with an existing
> deployment experience.
>
> There are multiple motivations to compress certificates.  The first one is
> that
> the smaller they are, the faster they arrive (both due to the transfer
> time and
> a decreased chance of packet loss).
>
> The second, and more interesting one, is that having small certificates is
> important for QUIC in order to achieve 1-RTT handshakes while limiting the
> opportunities for amplification attacks.  Currently,  TLS  1.3 over TCP
> without
> client auth looks like this:
>
>   Round trip 1: client sends SYN, server sends SYN ACK
>     Here, the server provides its own random value which client will
>     have to echo in the future.
>   Round trip 2: client sends ACK, ClientHello, server sends
> ServerHello...Finished
>     Here, ACK confirms to server that the client can receive packets and
> is not
>     just spoofing its source address.  Server can send the entire
> ServerHello to
>     Finished flight.
>
> In QUIC, we are trying to merge those two rounds into one.  The problem,
> however, is that the ClientHello is one packet, and ServerHello...Finished
> can
> span multiple packets, meaning that this could be used as an amplification
> attack vector since the client's address is not yet authenticated at this
> point.
> In order to address this, the server has to limit the number of packets it
> sends
> during the first flight (i.e. ServerHello...Finished flight).  Since
> certificates make up the majority of data in that flight, making them
> smaller
> can push them under the limit and save a round-trip.
>
> Cheers,
>   Victor.

-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
------------------------------------------------------------------------------------------------------------------------------- ------=_Part_1979_1883518451.1491370546157-- From nobody Wed Apr 5 01:44:55 2017 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 09C31129420 for ; Wed, 5 Apr 2017 01:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RbwDbcsPKlSj for ; Wed, 5 Apr 2017 01:44:51 -0700 (PDT) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (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 65FB7128CDC for ; Wed, 5 Apr 2017 01:44:51 -0700 (PDT) Received: by mail-wr0-x243.google.com with SMTP id w43so837752wrb.1 for ; Wed, 05 Apr 2017 01:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-transfer-encoding; bh=pHxPPWrLsGGqCbYCRwV5TDNFI/XSWyWP6flY0PCXPbI=; b=c4H5ooMz1cVKOCBn/hZQfh6zBy9aE7wBb29XxU6I54vlKjlgIZwMViz8sh1ORkuOXQ lptpL6nrIuyYdwZggls6ge+0aNXpywUbuP6HwpnPiEUTiXTU5LJMp5It1gBX31218HKx EdLgzWU/jAusqpZ/fUc0aJnmEzDFycKHFy8ZyyfQIVXiUqx4A9x2VWiwV3zsFX6Mx5yA xZdQrNm6G8FqmH7d52Hr4qd/Fk46204STtz2rY5B3SrLjYWRU5vG/C+QzAmXxTnOysRi ras+zJAe3fcq4jCGh01eQucrZyg6zau90nNQ7gvT1nto9Vl80OsvwJwD+hPllOi1R/KW bJvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-transfer-encoding; bh=pHxPPWrLsGGqCbYCRwV5TDNFI/XSWyWP6flY0PCXPbI=; b=JyZUORJ9JCANXu7KVaMKwezNZ8OcAYOkZIOUldb83udAwj/AWkWi6wxoftMLBc+hGt hhgLUyTSX2V7X1Y4bdsyK47mQKhHCJwxYFKTURZYY9p1Tp/RFNONO+puDFlX74/Cxm8e REIvODRyK8Lh0zl/U+t97H6w5KdT5+Y8fAQ94kynDcgEmZUWDPcprpMxqvX5/0NkRxW8 MtzrWkTfTBuQarbmx6qoSZvbse4J2t68xZYSwBeVVjaLQAASWt9Fy1oS8fxmLVKGbIGX I9xAWct74R7SZ3hbdkwhiL/HCcXz/zcXFtUuC4j3e1IlSbpzWrR5JFtqjb3rcHQbmClG JZLA== X-Gm-Message-State: AFeK/H2pI0vRNvghmlwDucyyBBhO2X1Yi1gUYvAfe5Wz7T34XIr1SQvVOBF6s3oL/9UyuQ== X-Received: by 10.223.135.13 with SMTP id a13mr24551669wra.87.1491381889910; Wed, 05 Apr 2017 01:44:49 -0700 (PDT) Received: from ?IPv6:2a02:c7d:c81a:df00:7e7a:91ff:fe9e:8149? ([2a02:c7d:c81a:df00:7e7a:91ff:fe9e:8149]) by smtp.gmail.com with ESMTPSA id j32sm25209059wre.7.2017.04.05.01.44.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 01:44:49 -0700 (PDT) To: tls@ietf.org References: From: Sam Scott Message-ID: <4d42ad93-4dd4-99af-f90b-0ab61021bcfb@gmail.com> Date: Wed, 5 Apr 2017 09:44:47 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Current TLS 1.3 state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 08:44:53 -0000 > I don't know what the state of the various modelling efforts is, > though I imagine > this will be a topic at TLS:DIV at the end of the month. We did > discuss the various > cryptographic changes in -20 (specifically the extra key derive stages > and the > handshake hash reification) with a number of cryptographers before > incorporating. > Perhaps some of the analytic groups on-list would care to comment? From our* point of view we're pretty happy with the current state of the spec. Our initial results confirm that TLS achieves the core security properties (secrecy and authentication). More specifically, we prove an absence of attacks against those properties in our model. We're currently waiting for the last version of the spec to be finalised so that we can make a more definitive statement and share our final results. Although we do not expect our analysis to be affected by the recent changes to the spec, we will still need to update our model and re-prove everything, which is quite time consuming. We will be talking at TLS:DIV so can share more then, including what is and isn't captured by our model. * Us being the Tamarin team: Cas Cremers, Marko Horvat, Jonathan Hoyland, Sam Scott, and Thyla van der Merwe. From nobody Wed Apr 5 02:03:34 2017 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 63D8C12944C for ; Wed, 5 Apr 2017 02:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 10dgURgUFaju for ; Wed, 5 Apr 2017 02:03:29 -0700 (PDT) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 45E60129426 for ; Wed, 5 Apr 2017 02:03:29 -0700 (PDT) Received: by mail-wr0-x242.google.com with SMTP id k6so888041wre.3 for ; Wed, 05 Apr 2017 02:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gQK78s+Fz9IGmT3UhdkAo7DtZUsf0K/IU2oqrT0WR3A=; b=H1o8hXmc4TbPqZoHAsI8P/NVJ0CllyQ0b0I7T+qGPMGxTe4EIkL9HelccD08dqtuNM zy3QUfF2VDL0xQwwunHWUdZLA90FEb2h7eGucWQooTwCaM+MGfxv/+1HfSDnljTH57iD hX3QwKGrKpl3OVYabWVJSl+HOi9tBARp8FJGjPOKT+Qnr0bvvIg/HO0mUBCbTx8JJ/nJ tQJA0Xj1tyfffOAX4yqpYsh6mijdAUCsu/VMJpKW3j7t8Qxch5JLB4xhwXX+MfJfA5g/ T0OxtqcTDrH4T8WzLRFmmXfjDvZDIWxo+iabaVGvWM7wZNVnhnLFXt1jj5x0dwqtXT6W zSvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gQK78s+Fz9IGmT3UhdkAo7DtZUsf0K/IU2oqrT0WR3A=; b=Z7FWmAhf6lxv6N9+oe7aHdhkLJXKtIJN5Dem5E34dmlEyY2Hkm6sqNHuGNVKH7CxnF /lfFBSJzLCGjcPANBIiwRed/FQPu/KkyzM//2Tf6rIhp6DuDIQOqrjjVUrNLlw4W7GPd OR9b4hj4nazIxx6OGLi1w+NpkDXhqrjVc6Hd1q/uC3ymh14dRphqusW0Q3K82T9oSKSu 0tLcbesemh+IiJUN2vqWTlNSiZyKi5L2DK39A4GXo0otY+zOicPJ5MPTdacyytTAFqL7 snmvMZGhljODTCeCM3apZG9X+SGWphaHFf+t+7ltya7hItX/79PhAshYjeIzJ+EbM2KI BMBg== X-Gm-Message-State: AFeK/H34XDoIE7aFuT+TU3Uuj5N0pasKngNb7jpdwKc5GYDiqh7hmtwGti1/S3OScpHH9w== X-Received: by 10.223.155.222 with SMTP id e30mr22881889wrc.165.1491383007757; Wed, 05 Apr 2017 02:03:27 -0700 (PDT) Received: from [192.168.1.15] (AClermont-Ferrand-653-1-114-20.w86-207.abo.wanadoo.fr. [86.207.165.20]) by smtp.gmail.com with ESMTPSA id o9sm14051180wrc.9.2017.04.05.02.03.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 02:03:26 -0700 (PDT) From: Karthikeyan Bhargavan Message-Id: <946F8C1F-FC58-4D03-8EB9-D0B3BFAA59DE@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_06374C05-7CDC-475C-9A15-6932D43F5164" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Apr 2017 11:03:25 +0200 In-Reply-To: <4d42ad93-4dd4-99af-f90b-0ab61021bcfb@gmail.com> Cc: tls@ietf.org To: Sam Scott References: <4d42ad93-4dd4-99af-f90b-0ab61021bcfb@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Current TLS 1.3 state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 09:03:32 -0000 --Apple-Mail=_06374C05-7CDC-475C-9A15-6932D43F5164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We=E2=80=99re hoping that the TLS:DIV workshop later this month will = serve to gather some opinions from the academic community on the current = spec. https://www.mitls.org/tls:div/ At IEEE S&P (Oakland), there will be at least two papers on analyses of = draft 18: - A ProVerif and CryptoVerif analysis of the protocol (and a minimal = reference implementation) - A verified F* implementation of the record layer So, putting these together with the upcoming Tamarin analysis and = previously published papers on prior drafts, I think we=E2=80=99ll have = a solid bibliography justifying the core design of TLS 1.3, especially = the (EC)DHE and PSK 1-RTT handshakes along with resumption. What I am less confident about is the secure usage of features like = 0-RTT, 0.5 RTT, and post-handshake authentication. Many researchers have looked at these aspects (and they can correct me = if I am wrong) but the security guarantees we can prove for these modes = is much more limited than for the regular 1-RTT handshake. My concern is = that these features will inspire new usage patterns will emerge for TLS = 1.3 that have not been adequately studied. I am not sure what we can do = about that except maybe work harder on the security considerations. -Karthik > On 5 Apr 2017, at 10:44, Sam Scott wrote: >=20 >> I don't know what the state of the various modelling efforts is, = though I imagine >> this will be a topic at TLS:DIV at the end of the month. We did = discuss the various >> cryptographic changes in -20 (specifically the extra key derive = stages and the >> handshake hash reification) with a number of cryptographers before = incorporating. >> Perhaps some of the analytic groups on-list would care to comment? >=20 > =46rom our* point of view we're pretty happy with the current state of = the spec. > Our initial results confirm that TLS achieves the core security = properties > (secrecy and authentication). More specifically, we prove an absence = of attacks > against those properties in our model. >=20 > We're currently waiting for the last version of the spec to be = finalised so that > we can make a more definitive statement and share our final results. = Although we > do not expect our analysis to be affected by the recent changes to the = spec, we > will still need to update our model and re-prove everything, which is = quite time > consuming. We will be talking at TLS:DIV so can share more then, = including what > is and isn't captured by our model. >=20 > * Us being the Tamarin team: Cas Cremers, Marko Horvat, Jonathan = Hoyland, > Sam Scott, and Thyla van der Merwe. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_06374C05-7CDC-475C-9A15-6932D43F5164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We=E2=80=99re hoping that the TLS:DIV workshop later this = month will serve to gather some opinions from the academic community on = the current spec.
https://www.mitls.org/tls:div/

At IEEE S&P (Oakland), there will = be at least two papers on analyses of draft 18:
- A = ProVerif and CryptoVerif analysis of the protocol (and a minimal = reference implementation)
- A verified F* = implementation of the record layer

So, putting these together with the = upcoming Tamarin analysis and previously published papers on prior = drafts, I think we=E2=80=99ll have a solid bibliography justifying the = core design of TLS 1.3, especially the (EC)DHE and PSK 1-RTT handshakes = along with resumption.

What I am less confident about is the secure usage of = features like 0-RTT, 0.5 RTT, and post-handshake = authentication.
Many researchers have looked at = these aspects (and they can correct me if I am wrong) but the security = guarantees we can prove for these modes is much more limited than for = the regular 1-RTT handshake. My concern is that these features will = inspire new usage patterns will emerge for TLS 1.3 that have not been = adequately studied. I am not sure what we can do about that except maybe = work harder on the security considerations.

-Karthik

On 5 Apr 2017, at 10:44, Sam Scott <sam.scott89@gmail.com> wrote:

I don't know what the = state of the various modelling efforts is, though I imagine
this will be a topic at TLS:DIV at the end of the month. We = did discuss the various
cryptographic changes in -20 = (specifically the extra key derive stages and the
handshake = hash reification) with a number of cryptographers before = incorporating.
Perhaps some of the analytic groups on-list = would care to comment?

=46rom = our* point of view we're pretty happy with the current state of the = spec.
Our initial results confirm that TLS achieves the = core security properties
(secrecy and authentication). = More specifically, we prove an absence of attacks
against = those properties in our model.

We're = currently waiting for the last version of the spec to be finalised so = that
we can make a more definitive statement and share our = final results. Although we
do not expect our analysis to = be affected by the recent changes to the spec, we
will = still need to update our model and re-prove everything, which is quite = time
consuming. We will be talking at TLS:DIV so can share = more then, including what
is and isn't captured by our = model.

* Us being the Tamarin team: Cas = Cremers, Marko Horvat, Jonathan Hoyland,
Sam Scott, and = Thyla van der Merwe.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_06374C05-7CDC-475C-9A15-6932D43F5164-- From nobody Wed Apr 5 04:46:55 2017 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 6EC06129415 for ; Wed, 5 Apr 2017 04:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0X1BU-sGQ5k5 for ; Wed, 5 Apr 2017 04:46:51 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 27C80127333 for ; Wed, 5 Apr 2017 04:46:51 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id d10so8131461qke.1 for ; Wed, 05 Apr 2017 04:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dBqNecnCT9rDU+I4CkdwSt/l3gdBsylhgCmT+FioQX0=; b=I/bxVQswMwc5hNlpByRQ3BCHoSIJEOjuK93TSivYZRi/YlZkb7EZsxWXp+6qYS8PAz gPUtZoisRv+FwaclcUiD4yVdLJpjwFh2FSKxV9pP8GQaY85A8Q4JcyZ+9c7LddyX/ocd PCjPBc1c6maHy8lry8Orw5tuKJDgKVyOi9b233pclvjT0dArF58bucPtT+R2eTJ1m3Pm fuGLTCEJHAImeJuCNZRRQGiNz4/iEaH88qhxMZAKwKr0SDVVC3I8zVUyjxWUAQNTmJWF NC+12D/ECovBCsH2uEsaCjt5vxinfmLT9ak6Oatm+C0rkbPfXHSxCv1dIymwdvzZR/Sz UrCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dBqNecnCT9rDU+I4CkdwSt/l3gdBsylhgCmT+FioQX0=; b=D3CmaSkc1BpJ2vDodfe+npnPxSwSaYgH21H/drC9HFa53ldYKpJykhPrioNe9fGMhR 2P28fFBYfmMmj6ncCuf3KEV4TvgS7SY+olouY4GAG120AkgWbWKLjcUapZa5n8sjZlu3 5JIKh6Sb3CIK7Mme4p849R8iv49AloMqERqUX/1rcECr2xNM77qExK+3G+l2eJ94pHgZ lnZsqhVORBocV735r1YQDSCljsCNS56WxJENW9kLD/4djjaBtnFpZSHUFjytq9kfRVIF es9nzpLgmsUPIHFQ8VyNRES4ecp+zvvcD3izmOx1SaID2utFDvloPmXR5TFbeixrNVeD O1Kg== X-Gm-Message-State: AFeK/H3WptzHYXAxNGwIpWHXjYwQRl+qQrzhp9b5+5wwZ/WqyIaJq4xaqjSmCAGGbwDxovn2cgbxJeQA4ySb4w== X-Received: by 10.55.179.66 with SMTP id c63mr18753863qkf.147.1491392810182; Wed, 05 Apr 2017 04:46:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Wed, 5 Apr 2017 04:46:49 -0700 (PDT) In-Reply-To: <20170328140056.GA1861@bolet.org> References: <20170328140056.GA1861@bolet.org> From: Martin Thomson Date: Wed, 5 Apr 2017 21:46:49 +1000 Message-ID: To: Thomas Pornin Cc: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] draft-thomson-tls-record-limit-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 11:46:53 -0000 Hi Thomas, Sorry for taking so long to get back to this. https://github.com/martinthomson/tls-record-limit/pull/1 covers the major changes. I decided to add a section covering the expansion issue so that I could do it justice. I was going to write more, then I realized that the dumb approach is probably safest: pad to get to record_size_limit or less, then pad to reach the block size. Attempting to explain what to do in more detail was only making it less clear. I've added a commit that should fix my error. It makes it clear that the problem for constrained servers even more acute: https://github.com/martinthomson/tls-record-limit/commit/5051d510471014f172b On 29 March 2017 at 01:00, Thomas Pornin wrote: > On Tue, Mar 28, 2017 at 06:35:24AM -0500, Martin Thomson wrote: >> I just submitted a version of the draft we've discussed a little on >> the list. >> >> I don't think we concluded the discussion about what to do about block >> cipher padding. > > I don't have strong preferences on this, but I would incline toward > using the plaintext length in the extension. In any case, adding a > longer-than-necessary padding in order to defeat traffic analysis does > not make sense if it expands the size beyond the minimal record size for > a full record (i.e. if an endpoint wants to add extra padding bytes to a > record with 16384 bytes of padding, it is only _revealing_ extra > information, not hiding it). > > I suggest altering this paragraph: > > The size limit expressed in the "record_size_limit" extension doesn't > account for expansion due to compression or record protection. It is > expected that a constrained device will disable compression and know > - and account for - the maximum expansion possible due to record > protection based on the cipher suites it offers or selects. Note > that up to 256 octets of padding and padding length can be added to > block ciphers. > > into this: > > The size limit expressed in the "record_size_limit" extension doesn't > account for expansion due to compression or record protection. If > and endpoint advertises a size limit which is lower than the > protocol-defined limit, then the peer SHALL NOT send a record whose > final, protected size exceeds that of the minimal protected size of a > record that contains exactly "record_size_limit" plaintext bytes and > uses no compression. > > For instance, if using TLS 1.2 and a cipher suite that mandates > AES/CBC encryption and HMAC/SHA-256 for protection, and an endpoint > advertises a "record_size_limit" of 700 bytes, then the minimal > protected record size for 700 bytes of plaintext contents is 757 > bytes: > > - 700 bytes of plaintext > - 32 bytes for the HMAC/SHA-256 > - 4 bytes of padding to reach the next multiple of the AES block > size (which is 16 bytes) > - 16 bytes for the explicit IV > - 5 bytes for the record header > > The padding may have length 1 to 256 bytes as per protocol rules; > but in the presence of a "record_size_limit" of 700 bytes expressed > by the peer, an endpoint SHALL refrain from sending records whose > total protected size exceeds 757 bytes. > > It is expected that a constrained device will disable compression; > moreover, the practice of adding a longer-than-minimal padding is > done in order to defeat traffic analysis, and sending records longer > than the minimal size for full records is counterproductive (such a > record would reveal extra information to onlookers, and thus should > be avoided). > > ------------------ > > Another unrelated comment: in section 3, there is the following: > > The "max_fragment_length" extension is also ill-suited to cases where > the capabilities of client and server are asymmetric. The server is > required to select a fragment length that is as small or smaller than > the client offers and both endpoints need to comply with this smaller > limit. > > Actually, it is worse than that: per the wording of RFC 6066, if a > client advertises a length of L bytes, the server must respond with > _exactly_ the same length L; the server is not allowed to select a > smaller length. The relevant RFC text is: > > The "extension_data" field of this extension SHALL contain a > "MaxFragmentLength" whose value is the same as the requested maximum > fragment length. > > and it is reinforced some lines later: > > Similarly, if a client receives a maximum fragment length negotiation > response that differs from the length it requested, it MUST also > abort the handshake with an "illegal_parameter" alert. > > The "max_fragment_length" extension is completely client-driven: it is > used only on the client's initiative, and uses the client's length. The > server's only choice is to accept the will of the client, or reject the > connection. Thus, it handles only the case of constrained clients > talking to big servers, not the other way round. > > > --Thomas Pornin From nobody Wed Apr 5 05:32:57 2017 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 F2D311286B2 for ; Wed, 5 Apr 2017 05:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 pxcnhFjTwfGa for ; Wed, 5 Apr 2017 05:32:54 -0700 (PDT) Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844F8120227 for ; Wed, 5 Apr 2017 05:32:54 -0700 (PDT) Received: from [91.183.52.43] (helo=[192.168.1.207]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cvk73-0008Gc-V2 for tls@ietf.org; Wed, 05 Apr 2017 14:32:53 +0200 From: Simon Friedberger To: tls@ietf.org References: Message-ID: Date: Wed, 5 Apr 2017 14:32:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 12:32:56 -0000 It seems the intention behind short lived certificates is pretty clear: Server operators often want to create short-lived certificates for servers in low- trust zones such as CDNs or remote data centers. But even if this is true it needs to be analyzed why server operators want to do this and if their reasons are good ones. The only example of a security gain I can think of is the following: If a breach remains undetected but is accidentally fixed for example through automatic updates. In this case a revocation will not be issued but short-lived certificates would still invalidate the certificates an attacker may have stolen. I suppose, this is similar to the common notion of rotating secrets. To me the increase in security weighted with the difficulty of obtaining such short-lived certificates from a CA probably does not justify the extra complexity of adding subcerts. Best, Simon From nobody Wed Apr 5 05:36:25 2017 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 8F93F12773A for ; Wed, 5 Apr 2017 05:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 HKruvIRlUN7o for ; Wed, 5 Apr 2017 05:36:22 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484C8126BF0 for ; Wed, 5 Apr 2017 05:36:22 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v35CVlEp005859; Wed, 5 Apr 2017 13:36:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=dKV+tWRZYbuxmj0O4ooHcOOwmn4Nu9IDUBs+cxzr0i8=; b=aJQ/mWwiQDGi8FB9aZC6735L632OULXINhJncuLPH+OryXHqEHPPfG32VLWvoWVoVw+y E304L7exrd7LVAMZaaMs9rvrMMDNSuD9nJYhJvn49U91tHTgWZ8YRTWCMiX5LP6bDGYY ihczFsJkHybP5bcxsVWpjMoci6IeNzVBIE9MfmOMQkH6yr06QL2yZdAGMT+mSreY/iKm +KkFTeKCduHdUIRXDMvlR7ixuxJyT61MzQh6+aO0mx5mDRwK582jpwim/63hBeE2LLhX O2aiZDyKgXMW8e9/chDzFJELb7Phs65UcEhTEWpW2G2auhvDWx4glJI7WGz3q5fXAehP +A== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 29myby8e0q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Apr 2017 13:36:01 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v35CVCO5005164; Wed, 5 Apr 2017 08:36:00 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 29j7hv6024-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Apr 2017 08:36:00 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 5 Apr 2017 05:35:59 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 5 Apr 2017 08:35:59 -0400 From: "Salz, Rich" To: Simon Friedberger , "tls@ietf.org" Thread-Topic: [TLS] security considerations for draft-rescorla-tls-subcerts Thread-Index: AQHSqaA+Yd3FNU6ci0eCiyn0YhIfmKGxe9kAgASjDICAAOJTgP//vWcQ Date: Wed, 5 Apr 2017 12:35:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.56] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704050110 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704050110 Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 12:36:24 -0000 > Server operators > often want to create short-lived certificates for servers in low- > trust zones such as CDNs or remote data centers. But as currently specified, that low-trust short-lived certificate, if capt= ured, can be used to spoof the operator anywhere else in the world. Yes, f= or a shorter time than the long-lived "true" key, but this still seems like= a footgun. From nobody Wed Apr 5 05:39:37 2017 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 E0B22127B31 for ; Wed, 5 Apr 2017 05:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 vWijuJzA4KCX for ; Wed, 5 Apr 2017 05:39:34 -0700 (PDT) Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E21126BF0 for ; Wed, 5 Apr 2017 05:39:34 -0700 (PDT) Received: from [91.183.52.43] (helo=[192.168.1.207]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cvkDV-000882-V2 for tls@ietf.org; Wed, 05 Apr 2017 14:39:33 +0200 To: "tls@ietf.org" References: From: Simon Friedberger Message-ID: Date: Wed, 5 Apr 2017 14:39:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 12:39:36 -0000 I agree, that's why I only see a security gain if the theft of the certificate remains undetected. On 05/04/17 14:35, Salz, Rich wrote: >> Server operators >> often want to create short-lived certificates for servers in low- >> trust zones such as CDNs or remote data centers. > But as currently specified, that low-trust short-lived certificate, if captured, can be used to spoof the operator anywhere else in the world. Yes, for a shorter time than the long-lived "true" key, but this still seems like a footgun. > From nobody Wed Apr 5 07:12:38 2017 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 E0CCB124282 for ; Wed, 5 Apr 2017 07:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.295 X-Spam-Level: X-Spam-Status: No, score=-4.295 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 aMpMB5-cY-oZ for ; Wed, 5 Apr 2017 07:12:35 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB3C1250B8 for ; Wed, 5 Apr 2017 07:12:35 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id A0E79600050D for ; Wed, 5 Apr 2017 07:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=DMKC21QK2zSVVpk02Rll92/1MFE=; b= naSA4wGlIDwQLx4KQPPx0YhBGhiyoVTlnHdtD2IupPDEG8PC5gJglNUUkVD5+FHe i9zu5sd2OLi9tr8dL43GBBv+Dkh10ByVoPfpA/KW/xxLeb0ejflC935qCfL/0Mh/ rPz7lR0ldNR8cRJG8YUrKv5+QfxwbqIVDV8bxon/w0w= Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 6A54F6000504 for ; Wed, 5 Apr 2017 07:12:34 -0700 (PDT) Received: by mail-lf0-f52.google.com with SMTP id h125so9415477lfe.0 for ; Wed, 05 Apr 2017 07:12:34 -0700 (PDT) X-Gm-Message-State: AFeK/H3UduTNdFhSplGEsrnWadMiVzsqnBCYw8TNJz3moPdr6DUoYxt27bZIiYfjScAqMUDkpdqwV1yC5qZyfQ== X-Received: by 10.25.0.207 with SMTP id 198mr9851917lfa.134.1491401552575; Wed, 05 Apr 2017 07:12:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Wed, 5 Apr 2017 07:12:31 -0700 (PDT) In-Reply-To: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in> References: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in> From: Ryan Sleevi Date: Wed, 5 Apr 2017 10:12:31 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sankalp Bagaria Cc: "tls@ietf.org" , R Balaji , "Bagaria, Sankalp" Content-Type: multipart/alternative; boundary=001a113c9f48c252d5054c6bfb6d Archived-At: Subject: Re: [TLS] Certificate compression draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 14:12:37 -0000 --001a113c9f48c252d5054c6bfb6d Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria wrote: > Hello, > > How is Certificate Compression advantageous over tls cached-info extension? > Only case I can think of is - when the certificate is being sent for the > first time, > it can be compressed. Since the client doesn't have a copy of the > certificate, > cached-info can't be used. Are there more cases where compression is > useful? > Does cached-info not represent a privacy info-leak by disclosing past sessions prior to authenticating the new session? Versus compression, which limits it to the session and thus reveals no new/additional information. That was certainly true for TLS1.2 Is compression not a simpler implementation - given the 'two' hard problems of computer science (caching, naming, off-by-one)? For example, you'd need to maintain a per-host cache of certificate information to meaningfully make use of it (... or else you end up with cross-origin state leakage, at least in the context of a browser, which is a Bad Thing). You would either need to read that information from stable storage prior to making the connection (so that you can negotiate the cached info), or you'd need to do a lazy-path where you index the cached entries and send those as available to the server, while in parallel beginning to load those entries. If those entries are corrupted, but used in the connection, the connection will fail. If those entries are removed during the connection establishment, the connection will fail. In short, cached-info represents a much greater degree of complexity and questionable privacy (both cross-origin and same origin - again, something relevant for browsers, but perhaps not relevant for others). Let's keep it simple :) --001a113c9f48c252d5054c6bfb6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria <<= a href=3D"mailto:sankalp@cdac.in" target=3D"_blank">sankalp@cdac.in>= wrote:
=20
=20 =20
Hello,
=20
=C2=A0
=20
How is Certificate Compression advantageous over tls cached-info e= xtension?
=20
Only case I can think of is - when the certificate is being sent f= or the first time,
=20
it can be compressed. Since the client doesn't have a copy of = the certificate,
=20
cached-info can't be used. Are there more cases where compress= ion is useful?

Does cach= ed-info not represent a privacy info-leak by disclosing past sessions prior= to authenticating the new session? Versus compression, which limits it to = the session and thus reveals no new/additional information. That was certai= nly true for TLS1.2

Is compression not a simpler i= mplementation - given the 'two' hard problems of computer science (= caching, naming, off-by-one)? For example, you'd need to maintain a per= -host cache of certificate information to meaningfully make use of it (... = or else you end up with cross-origin state leakage, at least in the context= of a browser, which is a Bad Thing). You would either need to read that in= formation from stable storage prior to making the connection (so that you c= an negotiate the cached info), or you'd need to do a lazy-path where yo= u index the cached entries and send those as available to the server, while= in parallel beginning to load those entries. If those entries are corrupte= d, but used in the connection, the connection will fail. If those entries a= re removed during the connection establishment, the connection will fail.

In short, cached-info represents a much greater deg= ree of complexity and questionable privacy (both cross-origin and same orig= in - again, something relevant for browsers, but perhaps not relevant for o= thers). Let's keep it simple :)
--001a113c9f48c252d5054c6bfb6d-- From nobody Wed Apr 5 07:22:33 2017 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 15D60128768 for ; Wed, 5 Apr 2017 07:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 tkoe_BoNRddS for ; Wed, 5 Apr 2017 07:22:28 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 41C36126BF7 for ; Wed, 5 Apr 2017 07:22:28 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id v76so6687135ywg.0 for ; Wed, 05 Apr 2017 07:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OO0RelAqyQvs1pevoUpANwHXTFkgnyS8MTTy7IFWhWI=; b=LbGaXXoY4X6vnNQuXNcSrAxfDNMveB39naAk+acUXemUjF/WKuM3q8Yf97lf6kANp8 cvuQTCwynPkc2O+0tmHILOU7B4Uw6Q4Q4XsYNubxZyDMeYt3Cu5LAQHuCyT8lHMTmeZb acySMqFvGZiZxCACeL3simq69NtFcXIe36bESuptWLJPP59OLvg3eyhz0j8T7Vrh8I6Q 4pE88Q0oo5PlOQdUHY3xFGatLqO23XIzJewlFEMVnqSe9UREgtbxCu7UnlDCOH+FHTXT QYWVhn5SPSlEByBvF2LQqMmdMigbbhSoNxhT1zbezr1CublUEnoZpHlIc8sd2tdD3qRr sR0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OO0RelAqyQvs1pevoUpANwHXTFkgnyS8MTTy7IFWhWI=; b=ZdvhbeIbZ4U8PQhuPtVBL76mvl2GLb7+V9dLp6GACGhsqQ3uiLNyKCR1HTRb1IahAk sGbdQpDhtXjBNWm6VS+2yT3eTToj2HG7JIJt+9H3hKofxffLDVENtK4GyU6qzOfiGcJK J2BIiEoLwyPSeuitG3DYyMHWouJmep1hBHbfp4pF3edsNgtkzk1Re5qfViyID0JiKFZe 2tmlfSUqyDXNlJhkBRtUa1uE+fJvFMlOPIlXLMAgFkJnQuoVlb+GnRDAaP1jFWmrxaCe rwsp4OsyIBAVSfs4fb7Cq8eNx5aSqGkcu7DBNc2D9jGsf0bscwqpD80eBelv9Z0pkTVk GfvA== X-Gm-Message-State: AFeK/H1LZnmUNSTAN2wLpUWiIua+t8sS/j5du8TjbKRQUKDVxJ+oxwyRhiW1AVtv7bqipQqfdf5Xls9iBqAPDw== X-Received: by 10.129.108.214 with SMTP id h205mr18896132ywc.71.1491402147446; Wed, 05 Apr 2017 07:22:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 5 Apr 2017 07:21:47 -0700 (PDT) In-Reply-To: References: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in> From: Eric Rescorla Date: Wed, 5 Apr 2017 07:21:47 -0700 Message-ID: To: Ryan Sleevi Cc: Sankalp Bagaria , R Balaji , "tls@ietf.org" , "Bagaria, Sankalp" Content-Type: multipart/alternative; boundary=001a114e81dc375c77054c6c1f5e Archived-At: Subject: Re: [TLS] Certificate compression draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 14:22:30 -0000 --001a114e81dc375c77054c6c1f5e Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi wrote: > > > On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria wrote: > >> Hello, >> >> How is Certificate Compression advantageous over tls cached-info >> extension? >> Only case I can think of is - when the certificate is being sent for the >> first time, >> it can be compressed. Since the client doesn't have a copy of the >> certificate, >> cached-info can't be used. Are there more cases where compression is >> useful? >> > > Does cached-info not represent a privacy info-leak by disclosing past > sessions prior to authenticating the new session? Versus compression, which > limits it to the session and thus reveals no new/additional information. > That was certainly true for TLS1.2 > This will also be true in TLS 1.3, even with encrypted certificates because (hopefully) they will be a lot smaller. Though you could of course pad out to the same size :) -Ekr --001a114e81dc375c77054c6c1f5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi <ryan-ietftls@sleevi= .com> wrote:


On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria &l= t;sankalp@cdac.in&= gt; wrote:
=20
=20 =20
Hello,
=20
=C2=A0
=20
How is Certificate Compression advantageous over tls cached-info e= xtension?
=20
Only case I can think of is - when the certificate is being sent f= or the first time,
=20
it can be compressed. Since the client doesn't have a copy of = the certificate,
=20
cached-info can't be used. Are there more cases where compress= ion is useful?

Do= es cached-info not represent a privacy info-leak by disclosing past session= s prior to authenticating the new session? Versus compression, which limits= it to the session and thus reveals no new/additional information. That was= certainly true for TLS1.2

This will also be true in TLS 1.3, even with encrypted certificates= because (hopefully) they
will be a lot smaller. Though you could= of course pad out to the same size :)

-Ekr
<= div>

--001a114e81dc375c77054c6c1f5e-- From nobody Wed Apr 5 09:07:47 2017 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 9B32412704B for ; Wed, 5 Apr 2017 09:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=GINeeFaC; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Cg3O6caa 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 tBYIeuJ7oZWy for ; Wed, 5 Apr 2017 09:07:43 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2DC126C89 for ; Wed, 5 Apr 2017 09:07:43 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v35G3upE009144; Wed, 5 Apr 2017 09:07:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=e1dbtvAvbSOAs47NigregXFpU5R9rkB2P+o9egVyA2c=; b=GINeeFaC9QVQ+IVHHVUxVpc2xBCwceJrMH42JxWnJBSafIHdF0TODbIV9vSWqIlUsSpR mu2XXQJY3Z8E9f73RXyk0t+CZ1s9M3UOJ6EGYrGmVSutSWy6oVtZmOUu84Er15f5wrsb BnTHZi/pzfBug5yqGETmTFX0sklkIT3v3As= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 29n3qt01c6-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 05 Apr 2017 09:07:20 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.23) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 5 Apr 2017 12:07:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e1dbtvAvbSOAs47NigregXFpU5R9rkB2P+o9egVyA2c=; b=Cg3O6caaNNhAkVCS4xT/uT7cGH2Omc1ei7uUdakOP8RedLfpvsvhwYoel85fQInY0trnO5H6LD1m/GLoPngM1WpFHE1duVl6K154mRclYExaCv/D9N7uOivcQJho3DJdFauUPN+SBXiw/gzAexb+y7+H79iv5i/oOWyNPuP29Nc= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Wed, 5 Apr 2017 16:07:16 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1005.020; Wed, 5 Apr 2017 16:07:16 +0000 From: Subodh Iyengar To: Simon Friedberger , "tls@ietf.org" , Richard Salz , "Kaduk, Ben" Thread-Topic: [TLS] security considerations for draft-rescorla-tls-subcerts Thread-Index: AQHSqaBOocVmAQvSZkGxKH7FNtBXA6GxLuRegASs84CAAOJSgIAAAPGAgAAA7ICAAC8aDw== Date: Wed, 5 Apr 2017 16:07:16 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-Mentions: rich.salz@gmail.com,bkaduk@akamai.com X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: a-oben.org; dkim=none (message not signed) header.d=none;a-oben.org; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 7:d3BnZLv7/o4eMXd5oW5Z1iPG8UNg13VcFK4feYOpRPK4s/E5u93TiwznHVQuqn3WlNTeLyvD+QsW1LSuKvdDza5hKD5VX0UZZ5V2VDRxWqTPww8SC9sAFdnIVVYOgaHD9Be4SR73fIZLSgQ40Z1y23miNTn2SMpH9YAiMIdW852KyCMGHzOCJSjLWj0eItX1Y0zMBtEA4i3rx0NDy0r299NpA2GQ7cYk5TUL+XaQjl5/oiExRSwI6FGbM++KgBaz1JKJfg0kOO8cmVcBrdQ2JNj+S5qw0i8p/flaYFX2nIQlighaTUw8aLCWFwYhBR09Ky9Ags4mCQGF5e5kaxliwQ==; 20:0H0bxgCxUqU+w4OVz9bwaMR0ciYvWwdY0/icI7u7bLK4OdWB9exonqADNewT4OL3iI3fKWDqsMHv4urT3/mmmw3NMSGNNru2SZyiEh48lXTHCrknbKL2TkkwE+Hx8AENQSqJoOsMO2Y1u9M+VWM3320JYwiDq/sw8QmN+abqack= x-ms-office365-filtering-correlation-id: 3854855c-03f7-4b9f-d630-08d47c3dd4a3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:MWHPR15MB1455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1455; x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39840400002)(39450400003)(39850400002)(39410400002)(24454002)(377454003)(6246003)(66066001)(33656002)(53546009)(25786009)(5660300001)(229853002)(7736002)(15650500001)(74316002)(7906003)(38730400002)(39060400002)(86362001)(575784001)(6116002)(189998001)(3846002)(102836003)(7696004)(3280700002)(93886004)(6306002)(54896002)(236005)(9686003)(122556002)(2950100002)(6506006)(2906002)(2900100001)(53936002)(50986999)(76176999)(54356999)(6436002)(606005)(8676002)(77096006)(81166006)(230783001)(8936002)(55016002)(2501003)(99286003)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB145571244E36DA811C5F6CDCB60A0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 16:07:16.6317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_12:, , signatures=0 Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 16:07:46 -0000 --_000_MWHPR15MB145571244E36DA811C5F6CDCB60A0MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > There is also an alternate world in which the TLS terminators should not = have certificates/keys on them but it is okay to give them delegated creden= tials. Here, one benefit is clear: performance. But the attacker capabili= ties against which this is supposed to be useful/acceptable remain unclear. @Kaduk, Ben I thought I expressed this in the use= cases, but I might not have been concise enough, so I'll try again. In our original use case when I say less-trusted I mean a CDN running in a = different country or a ISPs data center which has a different physical secu= rity constraints. The less-trusted and trusted hosts do trust each other, i= .e. they could trust each other with the keys however physical security con= straints would prevent this. The threat model here is that since if a less-trusted host having a key is = compromised for a certain period of time without detection, and an attacker= can steal private keys during that period. In many situations we are fine = with giving the TLS terminator a certificate / key, i.e. they actually have= a trust relationship, however we want a compromise to only give the attack= er a limited power to use the credential. Revocation is arguably effective,= so we would not be okay with giving a less trusted host a long term privat= e key. However we'd be okay with giving a less-trusted host a short term ke= y. > My apologies for being blunt, but that text reads like a solution in sear= ch of a problem. That is, what is expected to be achieved by having shorte= r-lived credentials? Is there a threat model for which having them brings = security advantages, or are there operational concerns, or ... ? Hopefully the threat model above should answer this question. I thought I w= as clear about the use cases. I think just being able to deploy shorter liv= ed credentials to even higher trust areas has an advantage beyond the use c= ases of less trusted locations in case they are compromised. > But as currently specified, that low-trust short-lived certificate, if c= aptured, can be used to spoof the operator anywhere else in the world. Yes= , for a shorter time than the long-lived "true" key, but this still seems l= ike a footgun. @Richard Salz There is no footgun that delegate= d credentials adds beyond what operators can do right now. Operators can go= get a short lived CA issued certificate and deploy it, however the latter = is much harder to deploy. See the original email for rationale about this. > To me the increase in security weighted with the difficulty of obtaining such short-lived certificates from a CA probably does not justify the extra complexity of adding subcerts. @Simon Friedberger Do you feel that short lived CA certificates are actuall= y deployable in large server deployments? I do not see that to be the case.= I see a security gain here but just being able to deploy short lived crede= ntials to not only less trusted locations, but also to more trusted locatio= ns as well which is another use case that I want to use this for. Subodh ________________________________ From: TLS on behalf of Simon Friedberger Sent: Wednesday, April 5, 2017 5:39:17 AM To: tls@ietf.org Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts I agree, that's why I only see a security gain if the theft of the certificate remains undetected. On 05/04/17 14:35, Salz, Rich wrote: >> Server operators >> often want to create short-lived certificates for servers in low- >> trust zones such as CDNs or remote data centers. > But as currently specified, that low-trust short-lived certificate, if ca= ptured, can be used to spoof the operator anywhere else in the world. Yes,= for a shorter time than the long-lived "true" key, but this still seems li= ke a footgun. > _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3DtBKp_cuV26a4AtN1WOEPpqNTgBQUE4Cg9cqS-Fdw5nI&s=3D2JwQdlzcb8E6z6hDnhn= xLFQZOabIRGTGcJmtBCTj46s&e=3D --_000_MWHPR15MB145571244E36DA811C5F6CDCB60A0MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> There is also an alternate= world in which the TLS terminators should not have certificates/keys on th= em but it is okay to give them delegated credentials.  Here, one benefit is clear: performance.  But the attacker capabiliti= es against which this is supposed to be useful/acceptable remain unclear.

@Kaduk, Ben I thought I expressed th= is in the use cases, but I might not have been concise enough, so I'll try = again.

In our original use case when I say less-trusted I mean a CD= N running in a different country or a ISPs data center which has a differen= t physical security constraints. The less-trusted and trusted hosts do trust each other, i.e. they could t= rust each other with the keys however physical security constraints would p= revent this.

The threat model here is that since if a less-trusted host h= aving a key is compromised for a certain period of time without detect= ion, and an attacker can steal private keys during that period. In many sit= uations we are fine with giving the TLS terminator a certificate / key, i.e. the= y actually have a trust relationship, however we want a compromise to only give = the attacker a limited power to use the credential. Revocation is argu= ably effective, so we would not be okay with giving a less trusted host a l= ong term private key. However we'd be okay with giving a less-trusted host a short term key. 

> My apologies = for being blunt, but that text reads like a solution in search of a problem= .  That is, what is expected to be achieved by having shorter-lived cr= edentials?  Is there a threat model for which having them brings security advantages, or are there operational concerns, or ...= ?

Hopefully the threat model above should answer this question. I thought = I was clear about the use cases. I think just being able to deploy shorter = lived credentials to even higher trust areas has an advantage beyond t= he use cases of less trusted locations in case they are compromised.


>  But = as currently specified, that low-trust short-lived certificate, if captured= , can be used to spoof the operator anywhere else in the world.  Yes, = for a shorter time than the long-lived "true" key, but this still seems like a footgun.

@Richard Salz There is no footgun that d= elegated credentials adds beyond what operators can do right now. Operators= can go get a short lived CA issued certificate and deploy it, however the latter is much harder to deploy. See the origin= al email for rationale about this.

>  To me t= he increase in security weighted with the difficulty of obtaining such short-lived c= ertificates from a CA probably does not justify the extra
complexity of addi= ng subcerts.


@Simon Friedberger Do you feel that short lived CA certificates are actuall= y deployable in large server deployments? I do not see that to be the case.=  I see a security gain here but just being able to deploy short lived = credentials to not only less trusted locations, but also to more trusted locations as well which is another use= case that I want to use this for. 

Subodh


From: TLS <tls-bounces= @ietf.org> on behalf of Simon Friedberger <simon.tls@a-oben.org> Sent: Wednesday, April 5, 2017 5:39:17 AM
To: tls@ietf.org
Subject: Re: [TLS] security considerations for draft-rescorla-tls-su= bcerts
 
I agree, that's why I only see a security gain if = the theft of the
certificate remains undetected.


On 05/04/17 14:35, Salz, Rich wrote:
>>    Server operators
>>    often want to create short-lived certificates fo= r servers in low-
>>    trust zones such as CDNs or remote data centers.=
> But as currently specified, that low-trust short-lived certificate, if= captured, can be used to spoof the operator anywhere else in the world.&nb= sp; Yes, for a shorter time than the long-lived "true" key, but t= his still seems like a footgun.
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://u= rldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo= _tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-w= AyN7fQ&m=3DtBKp_cuV26a4AtN1WOEPpqNTgBQUE4Cg9cqS-Fdw5nI&s=3D2JwQdlzc= b8E6z6hDnhnxLFQZOabIRGTGcJmtBCTj46s&e=3D
--_000_MWHPR15MB145571244E36DA811C5F6CDCB60A0MWHPR15MB1455namp_-- From nobody Wed Apr 5 09:14:32 2017 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 6AFAA1293EC for ; Wed, 5 Apr 2017 09:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 GBtpdQ4q8HzG for ; Wed, 5 Apr 2017 09:14:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 55D971286CA for ; Wed, 5 Apr 2017 09:14:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C1D8943340D; Wed, 5 Apr 2017 16:14:27 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A67D9433407; Wed, 5 Apr 2017 16:14:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491408867; bh=ExCNEADufaf/KxH6E5vGDIeK4KkemaRVPYKIZsbE67o=; l=5406; h=To:References:Cc:From:Date:In-Reply-To:From; b=r8jjHoI1imSjR1NyOSpNWjTWfpPCWsApTiiadLIeLhFOc1AQ3Vf7Lre9DF8pYQT+E z7mytTv6nVwKi7naZRWserqVniTkIavqwRCHrHIxCSrHWkEG0k61S0ma3QWAjHrdFn npoiHsNtjXUOLt+TsH2fM9QxzL7YKg4I3+KuwirI= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 3E9641FC95; Wed, 5 Apr 2017 16:14:27 +0000 (GMT) To: Eric Rescorla , Ryan Sleevi References: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in> Cc: R Balaji , Sankalp Bagaria , "Bagaria, Sankalp" , "tls@ietf.org" From: Benjamin Kaduk Message-ID: Date: Wed, 5 Apr 2017 11:14:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B615991C39F2EF74771A8EBC" Archived-At: Subject: Re: [TLS] Certificate compression draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 16:14:30 -0000 This is a multi-part message in MIME format. --------------B615991C39F2EF74771A8EBC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/05/2017 09:21 AM, Eric Rescorla wrote: > > > On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi > wrote: > > > > On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria > wrote: > > Hello, > > How is Certificate Compression advantageous over tls > cached-info extension? > Only case I can think of is - when the certificate is being > sent for the first time, > it can be compressed. Since the client doesn't have a copy of > the certificate, > cached-info can't be used. Are there more cases where > compression is useful? > > The authors presented work noting that reducing the certificate size when the client is first talking to a server can be useful to keep the server's first flight into a certain number of packets, useful to avoid hitting congestion control backoff and/or a cap on (reply size / request size) to avoid DDOS amplification attacks, as for QUIC. > Does cached-info not represent a privacy info-leak by disclosing > past sessions prior to authenticating the new session? Versus > compression, which limits it to the session and thus reveals no > new/additional information. That was certainly true for TLS1.2 > > > This will also be true in TLS 1.3, even with encrypted certificates > because (hopefully) they > will be a lot smaller. Though you could of course pad out to the same > size :) > The elephant in the room being that an attacker watching the network can replay the observed ClientHello but using its own KeyShare and read the resulting encrypted certificate reply. (h/t davidben) -Ben --------------B615991C39F2EF74771A8EBC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/05/2017 09:21 AM, Eric Rescorla wrote:


On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi <ryan-ietftls@sleevi.com> wrote:


On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria <sankalp@cdac.in> wrote:
Hello,
 
How is Certificate Compression advantageous over tls cached-info extension?
Only case I can think of is - when the certificate is being sent for the first time,
it can be compressed. Since the client doesn't have a copy of the certificate,
cached-info can't be used. Are there more cases where compression is useful?


The authors presented work noting that reducing the certificate size when the client is first talking to a server can be useful to keep the server's first flight into a certain number of packets, useful to avoid hitting congestion control backoff and/or a cap on (reply size / request size) to avoid DDOS amplification attacks, as for QUIC.

Does cached-info not represent a privacy info-leak by disclosing past sessions prior to authenticating the new session? Versus compression, which limits it to the session and thus reveals no new/additional information. That was certainly true for TLS1.2

This will also be true in TLS 1.3, even with encrypted certificates because (hopefully) they
will be a lot smaller. Though you could of course pad out to the same size :)


The elephant in the room being that an attacker watching the network can replay the observed ClientHello but using its own KeyShare and read the resulting encrypted certificate reply.  (h/t davidben)

-Ben
--------------B615991C39F2EF74771A8EBC-- From nobody Wed Apr 5 09:18:56 2017 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 846A81273E2 for ; Wed, 5 Apr 2017 09:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 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, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 x4hopeGo-gtX for ; Wed, 5 Apr 2017 09:18:53 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id DCD14126CD8 for ; Wed, 5 Apr 2017 09:18:52 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 84BFE43340C; Wed, 5 Apr 2017 16:18:52 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 6A59F433407; Wed, 5 Apr 2017 16:18:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491409132; bh=XRhWuyVUrOr0GRRpjP2rLnRKyaH3vUOgsl5Fc1xJD7s=; l=6173; h=To:References:From:Date:In-Reply-To:From; b=0JWbngGW80MshNSgRCqpDdAKAr+x8u4tMdde2EulEgGQRFJKZN8OvZqFhBWT3waNx KEe+NBMbWehzqjy0cvQsgQi8hGLL18EYAZPwrYy61lx3sKVBIFXuibMnVm6WboN2kW WiHPzOzP74I02kEPYciOKl3zJ8VMtDPwmJptcAUY= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 150C41FCA8; Wed, 5 Apr 2017 16:18:52 +0000 (GMT) To: Subodh Iyengar , Simon Friedberger , "tls@ietf.org" , Richard Salz References: From: Benjamin Kaduk Message-ID: Date: Wed, 5 Apr 2017 11:18:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0C10F81BF240CCC1195AB98B" Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 16:18:55 -0000 This is a multi-part message in MIME format. --------------0C10F81BF240CCC1195AB98B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/05/2017 11:07 AM, Subodh Iyengar wrote: > > > There is also an alternate world in which the TLS terminators should > not have certificates/keys on them but it is okay to give them > delegated credentials. Here, one benefit is clear: performance. But > the attacker capabilities against which this is supposed to be > useful/acceptable remain unclear. > > @Kaduk, Ben I thought I expressed this in > the use cases, but I might not have been concise enough, so I'll try > again. > > In our original use case when I say less-trusted I mean a CDN running > in a different country or a ISPs data center which has a different > physical security constraints. The less-trusted and trusted hosts do > trust each other, i.e. they could trust each other with the keys > however physical security constraints would prevent this. > > The threat model here is that since if a less-trusted host having a > key is compromised for a certain period of time without detection, and > an attacker can steal private keys during that period. In many > situations we are fine with giving the TLS terminator a certificate / > key, i.e. they actually have a trust relationship, however we want a > compromise to only give the attacker a limited power to use the > credential. Revocation is arguably effective, so we would not be okay > with giving a less trusted host a long term private key. However we'd > be okay with giving a less-trusted host a short term key. > > > My apologies for being blunt, but that text reads like a solution in > search of a problem. That is, what is expected to be achieved by > having shorter-lived credentials? Is there a threat model for which > having them brings security advantages, or are there operational > concerns, or ... ? > > Hopefully the threat model above should answer this question. I > thought I was clear about the use cases. I think just being able to > deploy shorter lived credentials to even higher trust areas has an > advantage beyond the use cases of less trusted locations in case they > are compromised. > It does, thanks for the clarification -- recovering from undetected compromise is a worthy goal! -Ben --------------0C10F81BF240CCC1195AB98B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/05/2017 11:07 AM, Subodh Iyengar wrote:

> There is also an alternate world in which the TLS terminators should not have certificates/keys on them but it is okay to give them delegated credentials.  Here, one benefit is clear: performance.  But the attacker capabilities against which this is supposed to be useful/acceptable remain unclear.

@Kaduk, Ben I thought I expressed this in the use cases, but I might not have been concise enough, so I'll try again.

In our original use case when I say less-trusted I mean a CDN running in a different country or a ISPs data center which has a different physical security constraints. The less-trusted and trusted hosts do trust each other, i.e. they could trust each other with the keys however physical security constraints would prevent this.

The threat model here is that since if a less-trusted host having a key is compromised for a certain period of time without detection, and an attacker can steal private keys during that period. In many situations we are fine with giving the TLS terminator a certificate / key, i.e. they actually have a trust relationship, however we want a compromise to only give the attacker a limited power to use the credential. Revocation is arguably effective, so we would not be okay with giving a less trusted host a long term private key. However we'd be okay with giving a less-trusted host a short term key. 

> My apologies for being blunt, but that text reads like a solution in search of a problem.  That is, what is expected to be achieved by having shorter-lived credentials?  Is there a threat model for which having them brings security advantages, or are there operational concerns, or ... ?

Hopefully the threat model above should answer this question. I thought I was clear about the use cases. I think just being able to deploy shorter lived credentials to even higher trust areas has an advantage beyond the use cases of less trusted locations in case they are compromised.


It does, thanks for the clarification -- recovering from undetected compromise is a worthy goal!

-Ben
--------------0C10F81BF240CCC1195AB98B-- From nobody Wed Apr 5 09:24:12 2017 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 108C11292CE for ; Wed, 5 Apr 2017 09:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 fcCFe-kIqr02 for ; Wed, 5 Apr 2017 09:24:07 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 65CE41286CA for ; Wed, 5 Apr 2017 09:24:07 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DA406433448; Wed, 5 Apr 2017 16:24:06 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id C4534433407; Wed, 5 Apr 2017 16:24:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491409446; bh=ueoSngAh25claHu30GwUVwG3/lslTImlu6Of7b+nC/I=; l=4904; h=To:References:Cc:From:Date:In-Reply-To:From; b=UfTQdCL0cPBbSrKnHPk/WG8yxVrbKGjGxJ1Qjq693ZyQdjQf3OA8iidGs+OLZ5NRf FEv0i+ft6OvxduEgJZqKDNNfNW+SQ3utYv2uZ6/zZWOWuW8QP6j1RjnRrGKavDvHzN S4i+bu17ZSgdkrV148P2HLAQ4WBGtNKId3FFJHZw= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 85F301FC93; Wed, 5 Apr 2017 16:24:06 +0000 (GMT) To: Karthikeyan Bhargavan , Sam Scott References: <4d42ad93-4dd4-99af-f90b-0ab61021bcfb@gmail.com> <946F8C1F-FC58-4D03-8EB9-D0B3BFAA59DE@gmail.com> Cc: tls@ietf.org From: Benjamin Kaduk Message-ID: <5e064d9b-ac36-a611-8b03-a17046ac33f7@akamai.com> Date: Wed, 5 Apr 2017 11:24:06 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <946F8C1F-FC58-4D03-8EB9-D0B3BFAA59DE@gmail.com> Content-Type: multipart/alternative; boundary="------------79A1E2D847B467FC292DC851" Archived-At: Subject: Re: [TLS] Current TLS 1.3 state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 16:24:11 -0000 This is a multi-part message in MIME format. --------------79A1E2D847B467FC292DC851 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/05/2017 04:03 AM, Karthikeyan Bhargavan wrote: > We’re hoping that the TLS:DIV workshop later this month will serve to > gather some opinions from the academic community on the current spec. > https://www.mitls.org/tls:div/ > > > At IEEE S&P (Oakland), there will be at least two papers on analyses > of draft 18: > - A ProVerif and CryptoVerif analysis of the protocol (and a minimal > reference implementation) > - A verified F* implementation of the record layer > > So, putting these together with the upcoming Tamarin analysis and > previously published papers on prior drafts, I think we’ll have a > solid bibliography justifying the core design of TLS 1.3, especially > the (EC)DHE and PSK 1-RTT handshakes along with resumption. > > What I am less confident about is the secure usage of features like > 0-RTT, 0.5 RTT, and post-handshake authentication. > Many researchers have looked at these aspects (and they can correct me > if I am wrong) but the security guarantees we can prove for these > modes is much more limited than for the regular 1-RTT handshake. My > concern is that these features will inspire new usage patterns will > emerge for TLS 1.3 that have not been adequately studied. I am not > sure what we can do about that except maybe work harder on the > security considerations. > W.r.t. 0-RTT/0.5-RTT in particular, since applications MUST NOT use them without an application profile specifying their use, it may be worth analyzing the particular application profiles as well, e.g., https://datatracker.ietf.org/doc/html/draft-nottingham-httpbis-retry . -Ben --------------79A1E2D847B467FC292DC851 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/05/2017 04:03 AM, Karthikeyan Bhargavan wrote:
We’re hoping that the TLS:DIV workshop later this month will serve to gather some opinions from the academic community on the current spec.

At IEEE S&P (Oakland), there will be at least two papers on analyses of draft 18:
- A ProVerif and CryptoVerif analysis of the protocol (and a minimal reference implementation)
- A verified F* implementation of the record layer

So, putting these together with the upcoming Tamarin analysis and previously published papers on prior drafts, I think we’ll have a solid bibliography justifying the core design of TLS 1.3, especially the (EC)DHE and PSK 1-RTT handshakes along with resumption.

What I am less confident about is the secure usage of features like 0-RTT, 0.5 RTT, and post-handshake authentication.
Many researchers have looked at these aspects (and they can correct me if I am wrong) but the security guarantees we can prove for these modes is much more limited than for the regular 1-RTT handshake. My concern is that these features will inspire new usage patterns will emerge for TLS 1.3 that have not been adequately studied. I am not sure what we can do about that except maybe work harder on the security considerations.


W.r.t. 0-RTT/0.5-RTT in particular, since applications MUST NOT use them without an application profile specifying their use, it may be worth analyzing the particular application profiles as well, e.g., https://datatracker.ietf.org/doc/html/draft-nottingham-httpbis-retry .

-Ben
--------------79A1E2D847B467FC292DC851-- From nobody Wed Apr 5 10:14:20 2017 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 687671200C1 for ; Wed, 5 Apr 2017 10:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 CbQlx-HboZfc for ; Wed, 5 Apr 2017 10:14:16 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF60D127775 for ; Wed, 5 Apr 2017 10:14:15 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id v35HE8Vb021142 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 5 Apr 2017 19:14:08 +0200 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id v35HE32c019820 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Apr 2017 19:14:03 +0200 Received: from DEFTHW99ER1MSX.ww902.siemens.net (139.22.70.71) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 5 Apr 2017 19:14:03 +0200 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.223]) by DEFTHW99ER1MSX.ww902.siemens.net ([139.22.70.71]) with mapi id 14.03.0339.000; Wed, 5 Apr 2017 19:14:02 +0200 From: "Fries, Steffen" To: =?utf-8?B?SGFubm8gQsO2Y2s=?= , "tls@ietf.org" Thread-Topic: [TLS] Support of integrity only cipher suites in TLS 1.3 Thread-Index: AdKsldO7ZRItAwyZRXCzcLu6YsWN5QAtyDcAADhSsSA= Date: Wed, 5 Apr 2017 17:14:01 +0000 Message-ID: References: <20170404180838.08ca99cc@pc1> In-Reply-To: <20170404180838.08ca99cc@pc1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 17:14:18 -0000 QWRkaW5nIHN1Y2ggYSBtb2RlIHdvdWxkIGFkZCBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgdGhhdCBt aWdodCBsZWFkIHRvIHZ1bG5lcmFiaWx0aWllcywgZS5nLiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBj YW4gYmUgdHJpY2tlZCBpbnRvIHVzaW5nIGEgbm9uZW5jcnlwdGVkIG1vZGUuDQpbW3N0Zl1dIGlu IHByaW5jaXBsZSB5ZXMsIGFzIHRoaXMgc2ltcGxpZmllcyB0aGUgY29uZmlndXJhdGlvbiBhbmQg cG9saWN5IGhhbmRsaW5nLiBPbiB0aGUgb3RoZXIgaGFuZCBpdCBpcyBhIHNlY3VyaXR5IHBvbGlj eSBwb2ludCB0byBhbGxvdyBjZXJ0YWluIGNpcGhlciBzdWl0ZXMuIA0KDQpJdCdzIGJlZW4gYSB0 cmVuZCBpbiB0aGUgdGxzIHdvcmtpbmcgZ3JvdXAgdG8NCmEpIHJlZHVjZSBjb21wbGV4aXR5IHdo ZW4gcG9zc2libGUuDQpbW3N0Zl1dIHVuZGVyc3Rvb2QsIG1ha2VzIG9wZXJhdGlvbiBsZXNzIGVy cm9yIHByb25lDQoNCmIpIG5vdCB0cnkgdG8gYWNjb21vZGF0ZSBvYnNjdXJlIHVzZSBjYXNlcyB0 aGF0IGFyZW4ndCByZWxldmFudCBmb3IgdGhlIG1ham9yaXR5IG9mIFRMUyB1c2UgY2FzZXMuDQpb W3N0Zl1dIHdlbGwsIGFzIFRMUyBpcyB1c2VkIGluIHVzZSBjYXNlcyBsaWtlIGVuZXJneSBhdXRv bWF0aW9uLCBpbmR1c3RyaWFsIGNvbnRyb2wsIHJhaWx3YXkgYXV0b21hdGlvbiBldGMuIHRoZXJl IGlzIGFuIGluY3JlYXNpbmcgbnVtYmVyIG9mIHVzZSBjYXNlcyBhcHBseWluZyBUTFMgYW5kIHRo ZXJlIGFyZSBzb21lLCB3aGljaCB3b3VsZCBsZXZlcmFnZSBpbnRlZ3JpdHkgb25seSBmb3IgYWxs b3dpbmcgZm9yIG1vbml0b3JpbmcNCg0KVGh1cyBJIGFzc3VtZSBhIG51bGwgY2lwaGVyIHdvbid0 IGZpbmQgc3VwcG9ydCBoZXJlLiBJZiB5b3Ugd2FudCB0byBoYXZlIHRyYWZmaWMgaW5zcGVjdGlv biB3aXRoIFRMUyBpbWhvIHRoZSByaWdodCB3YXkgaXMgdG8gc3VwcG9ydCB0aGF0IGF0IHRoZSBl bmQgcG9pbnRzIChsZXQgYWxvbmUgYW55IGFyZ3VtZW50cyB3aHkgeW91J3JlIGRvaW5nIHRyYWZm aWMgaW5zcGVjdGlvbiBpbiB0aGUgZmlyc3QgcGxhY2UgYW5kIHdoZXRoZXIgdGhvc2UgcmVhc29u cyBhcmUgZ29vZCBvbmVzKS4NCltbc3RmXV0gSW4gcHJpbmNpcGxlIHllcywgYnV0IHRoZSBlbmRw b2ludHMgYXJlIG9mdGVuIGxpbWl0ZWQgYW5kIG1heSBub3Qgc3VwcG9ydCB0aGlzIHR5cGUgb2Yg ZnVuY3Rpb25hbGl0eS4gQWdhaW4sIHRoZSB0cmFmZmljIGluc3BlY3Rpb24gaW4gYXV0b21hdGlv biByZWxhdGVkIGNvbW11bmljYXRpb24gaXMgZG9uZSBmb3IgYXVkaXRpbmcgYW5kIG1vbml0b3Jp bmcgb2YgdGhlIGNvbnRyb2wgZmxvdy4gSW4gdGhlIGV4YW1wbGUgb2YgZW5lcmd5IGF1dG9tYXRp b24sIFRMUyBpcyBhbHdheXMgdXNlZCB3aXRoIG11dHVhbCBhdXRoZW50aWNhdGlvbi4gU28gYm90 aCBwZWVycyBrbm93IGVhY2ggb3RoZXIuDQoNCklmIHlvdSBkb24ndCBsaWtlIHRoYXQgdGhlbiBU TFMgbWF5IGJlIG5vdCB0aGUgcmlnaHQgcHJvdG9jb2wgZm9yIHlvdXIgdXNlIGNhc2UuDQpbW3N0 Zl1dIEl0IHdhcyBwb3NzaWJsZSB0byBub3cgYW5kIGl0IGlzIGdvb2QgdG8gcmVseSBvbiBhIHBy b3RvY29sIGxpa2UgVExTLCB3aGljaCBpcyBkZWZpbmVkIGFuZCBkaXNjdXNzZWQgaW4gdGhpcyB3 YXkgaW4gdGhlIElFVEYuIEluIHRoZSBJRUMgKHdoaWNoIGlzIGVuZ2FnZWQgSSBlbmVyZ3kgYXV0 b21hdGlvbiBjb21tdW5pY2F0aW9uIGRlZmluaXRpb24pIHRoZXJlIGlzIHRoZSBkZXNpcmUgdG8g dXNlIHN0YW5kYXJkaXplZCBzZWN1cml0eSBwcm90b2NvbHMgYXZhaWxhYmxlIHRvIGF2b2lkIHRo ZSBkZWZpbml0aW9uIG9mIG93biBzb2x1dGlvbnMsIHdoZW5ldmVyIHBvc3NpYmxlLg0KDQotLQ0K SGFubm8gQsO2Y2sNCmh0dHBzOi8vaGJvZWNrLmRlLw0KDQptYWlsL2phYmJlcjogaGFubm9AaGJv ZWNrLmRlDQpHUEc6IEZFNzM3NTdGQTYwRTRFMjFCOTM3NTc5RkE1ODgwMDcyQkJCNTFFNDINCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWls aW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90bHMNCg== From nobody Wed Apr 5 10:16:02 2017 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 BDC51129480 for ; Wed, 5 Apr 2017 10:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 sd2Opnpa9etk for ; Wed, 5 Apr 2017 10:15:57 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F5912426E for ; Wed, 5 Apr 2017 10:15:53 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v35HBmhB025341; Wed, 5 Apr 2017 18:15:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=1CqPVrweccxz3j3VwcCeoNMNWYzB4bCBMY0FfqHWh5M=; b=nk1mOCqM0qyc/yH81bUGWGgC/4sEJJzahIon5dHdIaeNBd897laDVpur6og0HuO4Fhpy nPt103+Alg470z6rAHpwAKMqz0GzH0242xZbgGlYl+lPKBm2ZaIT88zS42Yu6BvyJK8e okX1NSCSKYWokh+2SBSED8ClMmoD73mhAQIvvstyCa+kfMKWx9kbuijH0p7+oIndtRDG v5xzR3JYduhqPFntgjTNWxgrdB8DhVPvMscoyEe6M6Z1VmiSJiTUWazYcv22ILz/+5Ky CvhkXF5BWjhirDYKLZSjqTXeshBBR13YIXPgheVqm4fCNwZhlSF0wYDSsGe26e5eQO+5 Gg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 29myd71t9f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Apr 2017 18:15:46 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v35HAjns026571; Wed, 5 Apr 2017 13:15:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 29j7hua2cg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Apr 2017 13:15:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 5 Apr 2017 13:15:38 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 5 Apr 2017 13:15:38 -0400 From: "Salz, Rich" To: "Fries, Steffen" , =?utf-8?B?SGFubm8gQsO2Y2s=?= , "tls@ietf.org" Thread-Topic: [TLS] Support of integrity only cipher suites in TLS 1.3 Thread-Index: AdKsldO7ZRItAwyZRXCzcLu6YsWN5QA6Wt4AADSTLYAACFfm0A== Date: Wed, 5 Apr 2017 17:15:37 +0000 Message-ID: <6ebe1d10b1e8447999f5db2311ec6197@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170404180838.08ca99cc@pc1> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704050148 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704050148 Archived-At: Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 17:16:01 -0000 RG8geW91IGhhdmUgYSBjb21wZWxsaW5nIG5lZWQgZm9yIFRMUyAxLjMgYXMgb3Bwb3NlZCB0byBl YXJsaWVyIHZlcnNpb25zIHdoaWNoIGRvIGhhdmUgbnVsbCBlbmNyeXB0aW9uPw0K From nobody Wed Apr 5 10:16:09 2017 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 202E012948B for ; Wed, 5 Apr 2017 10:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 pPfYpYfnl6H7 for ; Wed, 5 Apr 2017 10:16:03 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 48DFF129480 for ; Wed, 5 Apr 2017 10:16:03 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id g2so11003455pge.3 for ; Wed, 05 Apr 2017 10:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YavPCGsqN371NeP53bHJTEgLNJPXzHuasfV6EnjGx04=; b=DwiIzmcyEDd4KdGc4unm89Y4S3VoErf3NqNI+FvKb2op6i9nqKi3pMbGUolbw48lRb qInOREbzqRDvV31lq0wRu6yTAJNRXFC9HYXa58zEBVxNrJuqfEH4F+A/BDVwCCx1e1y9 Xx3hyYziTpg+h739adrqYEVphJQq4YdHVLWhU= 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=YavPCGsqN371NeP53bHJTEgLNJPXzHuasfV6EnjGx04=; b=GLDSt7rUzMSyVxK+i7l/ddfczvOY1IHORW4cxKtUMJpC+ko6QTbTbfkE4tkhGAkTok QpGQQabX5QagllRZbPRKzIQOcNiZTL4SPCED60dEpV+tHa4XC4fplhne+SigoOX77Cr/ 5ZGEGCYgyrQuHDgxNQBi17c6xacgBrPADSfRPqrxC4ieQnkHVsV/l6McPDVTvg6yuKrn Pk7w67Qi3Hc+ykEZ1J8xcUs567yN/FZfxK2a8nRRZ/hmrDjfrZ7EqQKpHkeHjDzfNIMQ oEP+NGNfLdu6/QIBChr5pEPiNbQF0hOLYU8uwm2lqY5ELz5PVMgtQWCaZcDhgMc5DVR0 TDuQ== X-Gm-Message-State: AFeK/H1Lv/83Ftoo3sTFrVhywx0FwflPw+NrDJ4rFRe5aMrOVVYYf4Kuo5DQgxlbAF+FS3PosbLoGxqAYjAwwVqF X-Received: by 10.84.193.129 with SMTP id f1mr37584921pld.77.1491412562818; Wed, 05 Apr 2017 10:16:02 -0700 (PDT) MIME-Version: 1.0 References: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in> In-Reply-To: From: David Benjamin Date: Wed, 05 Apr 2017 17:15:50 +0000 Message-ID: To: Benjamin Kaduk , Eric Rescorla , Ryan Sleevi Cc: R Balaji , Sankalp Bagaria , "Bagaria, Sankalp" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c18a36e058a08054c6e8c80 Archived-At: Subject: Re: [TLS] Certificate compression draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 17:16:05 -0000 --94eb2c18a36e058a08054c6e8c80 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote: > On 04/05/2017 09:21 AM, Eric Rescorla wrote: > > On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi > wrote: > > Does cached-info not represent a privacy info-leak by disclosing past > sessions prior to authenticating the new session? Versus compression, which > limits it to the session and thus reveals no new/additional information. > That was certainly true for TLS1.2 > > > This will also be true in TLS 1.3, even with encrypted certificates > because (hopefully) they > will be a lot smaller. Though you could of course pad out to the same size > :) > > > The elephant in the room being that an attacker watching the network can > replay the observed ClientHello but using its own KeyShare and read the > resulting encrypted certificate reply. (h/t davidben) > (Supposing that the server is a traditional server that accepts multiple requests and does not select the certificate based on external factors in the transport or elsewhere, which means you're selecting by things not covered by TLS's transcript.) Also, while one could compressed pad up to uncompressed length and make compression useless, hiding whether your certificate was compressed is not a plausible goal. More plausible is hiding which certificate was selected. Without compression, your certificates still have different lengths, so you would need to pad up to max(certificate_message(cert) for cert in certs) anyway, where certs is all identities your particular server wishes to make indistinguishable. Maybe chunk up to a boundary beyond that if you want. With compression, you pad up to max(compress(certificate_message(cert) for cert in certs). Maybe chunk up to a boundary beyond that if you want. (Packet boundary for the QUIC use case?) This means you're now bound by your worst cert rather than your selected cert, but one could still expect a size win. This is, of course, all assuming your server setup is somehow such that the above pachyderm doesn't apply. David --94eb2c18a36e058a08054c6e8c80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 5,= 2017 at 12:14 PM Benjamin Kaduk <b= kaduk@akamai.com> wrote:
On 04/05/2017 09:21 AM, Eric Rescorla wrote:
=20
On Wed, Apr 5, 2017 at 7:12 = AM, Ryan Sleevi <ryan-iet= ftls@sleevi.com> wrote:
Does cached-info not represent= a privacy info-leak by disclosing past sessions prior to authenticating the new session? Versus compression, which limits it to the session and thus reveals no new/additional information. That was certainly true for TLS1.2

This will also be true in TLS 1.3, eve= n with encrypted certificates because (hopefully) they
will be a lot smaller. Though you coul= d of course pad out to the same size :)


The elephant in the room being that an attacker watching the network can replay the observed ClientHello but using its own KeyShare and read the resulting encrypted certificate reply.=C2=A0 (h/t davidben)

(Supposing that= the server is a traditional server that accepts multiple requests and does= not select the certificate based on external factors in the transport or e= lsewhere, which means you're selecting by things not covered by TLS'= ;s transcript.)

Also, while one could compressed p= ad up to uncompressed length and make compression useless, hiding whether y= our certificate was compressed is not a plausible goal. More plausible is h= iding which certificate was selected.

Without comp= ression, your certificates still have different lengths, so you would need = to pad up to max(certificate_message(cert) for cert in certs) anyway, where= certs is all identities your particular server wishes to make indistinguis= hable. Maybe chunk up to a boundary beyond that if you want.

=
With compression, you pad up to max(compress(certificate_message= (cert) for cert in certs). Maybe chunk up to a boundary beyond that if you = want. (Packet boundary for the QUIC use case?) This means you're now bo= und by your worst cert rather than your selected cert, but one could still = expect a size win.

This is, of course, all assumin= g your server setup is somehow such that the above pachyderm doesn't ap= ply.

David
--94eb2c18a36e058a08054c6e8c80-- From nobody Wed Apr 5 10:32:08 2017 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 3B7B212945B for ; Wed, 5 Apr 2017 10:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 GImGthHflswS for ; Wed, 5 Apr 2017 10:32:04 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 912F51292CE for ; Wed, 5 Apr 2017 10:32:04 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id p77so9380139ywg.1 for ; Wed, 05 Apr 2017 10:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IRHMRIm3kY9Mx2fdDygZKz/NrzmuGdK1xgfjaCC7BLU=; b=mUzE7ZHlAO1y4yArHiZoLzoJhH01Ux6EblXeXq+mfYhaxksimTq5RuzTy++BAwhfUm SRRkkKnQ3uQrv02q1uoTintGfGnyslB3eh4KMQqEe8Fm/hkLzFk0yw1ODnHGpw4wEweT mPp7ccQf/Tl4sunbY14RkDR+ITwuEsvo54ijqFnMFlTsDySrvpHDmnjYuVBo3kRq0hq2 G7p8ho7yz1Kj4N2J+x+alhvlyBpWkFkxgiXxhCFRMtXwjkh4HGb1IP4fY3LN2p1jUFxq W0cTvrJWg5H9ecJID6Vvc2Tuf6xC76B6UgQarNlulxsEkNLYZPEdTZ9X+0q5vxbf2VCu QY+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IRHMRIm3kY9Mx2fdDygZKz/NrzmuGdK1xgfjaCC7BLU=; b=CAQ3iFvssl0FiiLt0AgY6AMj7jUD7vGFRrDfZatdBWuXLvEQH9eoJNYDJypE6ADS0d mxjDDkonBmaqOhAPwPXlTE2h1dzl7h5Kc3ugmXfx2NlXbqxGDIqzqUCQe/WNIfQVWgSP BYW1DcbX9MFGrgjk7q7DFpBpJFP2+YxHKS0h4GhVhqdPqE2jxMstnhkg18FpyOdjSmTX JRLSsxCcAkax7rYBwW6yfzFIb4j/Y3PLo4CHRkDK4xKDk7HJkJKWUAXegiSDg99QOeG3 jI3Qu268pUTVb8hHKLnVbfcKOiOAFRxT2uxr6ZadF6JWJvgf38GxMHnUUECAeJr6MYhP yK2A== X-Gm-Message-State: AFeK/H1/r5gdAG/Hyvj1nhL1Bn2/0zEJBtmiOVJA8zbxn1aV+6eynYBwEjFxCBOgl2sXYtgfg/DQn49DTkWCWg== X-Received: by 10.13.240.199 with SMTP id z190mr19352273ywe.125.1491413523733; Wed, 05 Apr 2017 10:32:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 5 Apr 2017 10:31:23 -0700 (PDT) In-Reply-To: References: <20170404180838.08ca99cc@pc1> From: Eric Rescorla Date: Wed, 5 Apr 2017 10:31:23 -0700 Message-ID: To: "Fries, Steffen" Cc: =?UTF-8?Q?Hanno_B=C3=B6ck?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03380c4bb5fa054c6ec571 Archived-At: Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 17:32:07 -0000 --94eb2c03380c4bb5fa054c6ec571 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Without taking a position on null cipher suites, I would observe that the new TLS IANA rules will let you register your own (non-standard, non-recommended) code points for integrity-only suites. -Ekr On Wed, Apr 5, 2017 at 10:14 AM, Fries, Steffen wrote: > Adding such a mode would add additional complexity that might lead to > vulnerabiltiies, e.g. implementations that can be tricked into using a > nonencrypted mode. > [[stf]] in principle yes, as this simplifies the configuration and policy > handling. On the other hand it is a security policy point to allow certai= n > cipher suites. > > It's been a trend in the tls working group to > a) reduce complexity when possible. > [[stf]] understood, makes operation less error prone > > b) not try to accomodate obscure use cases that aren't relevant for the > majority of TLS use cases. > [[stf]] well, as TLS is used in use cases like energy automation, > industrial control, railway automation etc. there is an increasing number > of use cases applying TLS and there are some, which would leverage > integrity only for allowing for monitoring > > Thus I assume a null cipher won't find support here. If you want to have > traffic inspection with TLS imho the right way is to support that at the > end points (let alone any arguments why you're doing traffic inspection i= n > the first place and whether those reasons are good ones). > [[stf]] In principle yes, but the endpoints are often limited and may not > support this type of functionality. Again, the traffic inspection in > automation related communication is done for auditing and monitoring of t= he > control flow. In the example of energy automation, TLS is always used wit= h > mutual authentication. So both peers know each other. > > If you don't like that then TLS may be not the right protocol for your us= e > case. > [[stf]] It was possible to now and it is good to rely on a protocol like > TLS, which is defined and discussed in this way in the IETF. In the IEC > (which is engaged I energy automation communication definition) there is > the desire to use standardized security protocols available to avoid the > definition of own solutions, whenever possible. > > -- > Hanno B=C3=B6ck > https://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c03380c4bb5fa054c6ec571 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Without taking a position on null cipher suites, I would o= bserve that the new TLS IANA rules will let you register your own (non-stan= dard, non-recommended) code points for integrity-only suites.

-Ekr


On Wed, Apr 5, 2017 at 10:14 AM, Fries, Steffen &= lt;steffen.f= ries@siemens.com> wrote:
Adding such a mode would add additional complexity that migh= t lead to vulnerabiltiies, e.g. implementations that can be tricked into us= ing a nonencrypted mode.
[[stf]] in principle yes, as this simplifies the configuration and p= olicy handling. On the other hand it is a security policy point to allow ce= rtain cipher suites.

It's been a trend in the tls working group to
a) reduce complexity when possible.
[[stf]] understood, makes operation less error prone

b) not try to accomodate obscure use cases that aren't relevant for the= majority of TLS use cases.
[[stf]] well, as TLS is used in use cases like energy automation, in= dustrial control, railway automation etc. there is an increasing number of = use cases applying TLS and there are some, which would leverage integrity o= nly for allowing for monitoring

Thus I assume a null cipher won't find support here. If you want to hav= e traffic inspection with TLS imho the right way is to support that at the = end points (let alone any arguments why you're doing traffic inspection= in the first place and whether those reasons are good ones).
[[stf]] In principle yes, but the endpoints are often limited and ma= y not support this type of functionality. Again, the traffic inspection in = automation related communication is done for auditing and monitoring of the= control flow. In the example of energy automation, TLS is always used with= mutual authentication. So both peers know each other.

If you don't like that then TLS may be not the right protocol for your = use case.
[[stf]] It was possible to now and it is good to rely on a protocol = like TLS, which is defined and discussed in this way in the IETF. In the IE= C (which is engaged I energy automation communication definition) there is = the desire to use standardized security protocols available to avoid the de= finition of own solutions, whenever possible.

--
Hanno B=C3=B6ck
https:/= /hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c03380c4bb5fa054c6ec571-- From nobody Wed Apr 5 10:46:23 2017 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 940F3128DF6 for ; Wed, 5 Apr 2017 10:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 E0i5vOE98ekv for ; Wed, 5 Apr 2017 10:46:19 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 38057126C26 for ; Wed, 5 Apr 2017 10:46:19 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id i124so4979404ybc.3 for ; Wed, 05 Apr 2017 10:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/8Mt3M47/qTIYQblTWWTeB9RB3RcLJcnGmxDqxEppTk=; b=GTdL9Tc+VKxu3/kgre/Q8O3F9LkM+eUHOGVU4cfEehwXChE/i5+asAPsOjefwVIniS GuEMW4EhGfOd+PpFLzkcgQ5ErCkayveHhZhprceM9pwWG8Lom09HBi01/QH1vJQF4HYB saEPKxj+i8PdH3UnYLinwrr3cCDZaGYbo1JpOqM+M+UHypP6jg8rnPZH0uz0Vvg8Qh1J 7pP/FQG066tK0ELqKzwEO7Te5MJIbimRzaU5yMAgFbLARYBu0Z+Gd/BmoTDDbI0LiFsA MXc1hZInFlCMQI3M5urgYkdV6vPPsGt+zFHE0DeXT9fNdH6itCWiKBQJh0GjVH4YHXAO T7FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/8Mt3M47/qTIYQblTWWTeB9RB3RcLJcnGmxDqxEppTk=; b=WxLiFAyjwRjq5rQ/FlvCvsssobIIk4J2dVe4lMW8ADtvgrTJjsddPoiudce5MFzJh8 LHcQdp2l/lM+BqaSV2kQQsqxXjoLyhSqDWAAfIMXdr7pYV6MDYmXKVKjA82ljo6HLocy D561ynQhpP6Frf02JBXvdKuhjMG4asuqSVLl5LiVPDz83TjSOuqvY0rYt67WZ1PbgbDv dexQma2UWDQ6WsdoewrKzKBItl22kdkV/gxg1x1cljzrKyS2Qtuyf7eG3+EwzHYKVhfX sKYGmrXa0unSumcJ0zRcYtWNiUgWHBer0iO2IWsqeTAFF6dDOOJH5PNY9YBEfBYfjQxB LpXg== X-Gm-Message-State: AFeK/H2RQAaNC8dpG2vXq2hnEreXESrugoyPbhV1KpEHU6Otg5OLr70DrmwUatlueoz7skyzhrB+ylDB00Ikfw== X-Received: by 10.37.179.28 with SMTP id l28mr18654376ybj.107.1491414378406; Wed, 05 Apr 2017 10:46:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 5 Apr 2017 10:45:38 -0700 (PDT) In-Reply-To: References: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in> From: Eric Rescorla Date: Wed, 5 Apr 2017 10:45:38 -0700 Message-ID: To: David Benjamin Cc: Benjamin Kaduk , Ryan Sleevi , R Balaji , Sankalp Bagaria , "Bagaria, Sankalp" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=f403045f29103cfb17054c6ef8ae Archived-At: Subject: Re: [TLS] Certificate compression draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 17:46:22 -0000 --f403045f29103cfb17054c6ef8ae Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin wrote: > On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote: > >> On 04/05/2017 09:21 AM, Eric Rescorla wrote: >> >> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi >> wrote: >> >> Does cached-info not represent a privacy info-leak by disclosing past >> sessions prior to authenticating the new session? Versus compression, which >> limits it to the session and thus reveals no new/additional information. >> That was certainly true for TLS1.2 >> >> >> This will also be true in TLS 1.3, even with encrypted certificates >> because (hopefully) they >> will be a lot smaller. Though you could of course pad out to the same >> size :) >> >> >> The elephant in the room being that an attacker watching the network can >> replay the observed ClientHello but using its own KeyShare and read the >> resulting encrypted certificate reply. (h/t davidben) >> > > (Supposing that the server is a traditional server that accepts multiple > requests and does not select the certificate based on external factors in > the transport or elsewhere, which means you're selecting by things not > covered by TLS's transcript.) > > Also, while one could compressed pad up to uncompressed length and make > compression useless, hiding whether your certificate was compressed is not > a plausible goal. More plausible is hiding which certificate was selected. > > Without compression, your certificates still have different lengths, so > you would need to pad up to max(certificate_message(cert) for cert in > certs) anyway, where certs is all identities your particular server wishes > to make indistinguishable. Maybe chunk up to a boundary beyond that if you > want. > > With compression, you pad up to max(compress(certificate_message(cert) > for cert in certs). Maybe chunk up to a boundary beyond that if you want. > (Packet boundary for the QUIC use case?) This means you're now bound by > your worst cert rather than your selected cert, but one could still expect > a size win. > > This is, of course, all assuming your server setup is somehow such that > the above pachyderm doesn't apply. > Sorry, yes, I should have mentioned this, especially as I just made the same point to someone else the other day. I think there are two threat models here: 1. Active attacker 2. Passive attacker. As you indicate the active attacker can elicit the server's certificate by replaying CH with his own KeyShare (this is part of what makes SNI encryption so hard). For a passive attacker, as David suggests, you can hide which cert was selected by padding up to the largest cert (whether the cert was compressed or not). That may or may not be valuable depending on the scenario [for instance in WebRTC]. As you say, I don't think you can hide the cache hit even from a passive attacker because then you would need to pad up to an unreasonable amount. -Ekr --f403045f29103cfb17054c6ef8ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin <<= a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium= .org> wrote:
On Wed, Apr= 5, 2017 at 12:14 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
On 04/05/2017 09:21 AM, Eric Rescorla wrote:
=20
On Wed,= Apr 5, 2017 at 7:12 AM, Ryan Sleevi <ryan-ietftls@sleevi.com> wrote:
=
Does cach= ed-info not represent a privacy info-leak by disclosing past sessions prior to authenticating the new session? Versus compression, which limits it to the session and thus reveals no new/additional information. That was certainly true for TLS1.2

This will also be= true in TLS 1.3, even with encrypted certificates because (hopefully) they
will be a lot sma= ller. Though you could of course pad out to the same size :)


The elephant in the room being that an attacker watching the network can replay the observed ClientHello but using its own KeyShare and read the resulting encrypted certificate reply.=C2=A0 (h/t davidben)

(Supposing that the server is a traditional server that accept= s multiple requests and does not select the certificate based on external f= actors in the transport or elsewhere, which means you're selecting by t= hings not covered by TLS's transcript.)

Also, = while one could compressed pad up to uncompressed length and make compressi= on useless, hiding whether your certificate was compressed is not a plausib= le goal. More plausible is hiding which certificate was selected.

Without compression, your certificates still have different= lengths, so you would need to pad up to max(certificate_message(cert) for = cert in certs) anyway, where certs is all identities your particular server= wishes to make indistinguishable. Maybe chunk up to a boundary beyond that= if you want.

With compression, you pad up to max(= compress(certificate_message(cert) for cert in certs). Maybe chunk up = to a boundary beyond that if you want. (Packet boundary for the QUIC use ca= se?) This means you're now bound by your worst cert rather than your se= lected cert, but one could still expect a size win.

This is, of course, all assuming your server setup is somehow such that t= he above pachyderm doesn't apply.
Sorry, yes, I should have mentioned this, especially as I just= made the same point to someone
else the other day.
I think there are two threat models here:

<= div>1. Active attacker
2. Passive attacker.

<= div>As you indicate the active attacker can elicit the server's certifi= cate by replaying CH
with his own KeyShare (this is part of what = makes SNI encryption so hard).=C2=A0

For a passive= attacker, as David suggests, you can hide which cert was selected
by padding up to the largest cert (whether the cert was compressed or not= ). That
may or may not be valuable depending on the scenario [for= instance in WebRTC].
As you say, I don't think you can hide = the cache hit even from a passive attacker
because then you would= need to pad up to an unreasonable amount.

-Ekr
=C2=A0
--f403045f29103cfb17054c6ef8ae-- From nobody Wed Apr 5 10:47:17 2017 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 1A683129407 for ; Wed, 5 Apr 2017 10:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 VXvkXM6kyoZa for ; Wed, 5 Apr 2017 10:47:12 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 03A05128DF6 for ; Wed, 5 Apr 2017 10:47:11 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id i203so9607027ywc.3 for ; Wed, 05 Apr 2017 10:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tCwlXkmZegbf84Xen7/eLTRptv0MEWA78JBNGFc8f5M=; b=dg8xHnbvj4r8hV1T7rh6Ja2fTLRFQJDj19T18rjuICsY7poRnuVy2gsPKXC/9NZXvl cJLxwMRCzf1P2IzdOfpK0Ew68tfSq31J34du3grZgiZmbiCUrEzQx+ZSs3wzjtYvg7Eb rCLairq2jjOV6o9JKb9nKSOMrTKodeJGY0ky/Xn3WlJa8XGVhfW2Oj04aICtXQSDXxpb YSx/eS2cezYnKJKGkQiGcLVvAiOuVR1Ecn6Bgaxw2dKrvefgGBAXPBb9I2l7dzEeYWsw POiqKjxiu5eIqBxyqJVSlqn4v7zFpmZf0OPROboRgBvoPwGS3nDeygsDPtQfNMewxiB5 KMeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tCwlXkmZegbf84Xen7/eLTRptv0MEWA78JBNGFc8f5M=; b=E9eA2rJ09XrmMoFJ8qLhiZUmeNKduw6VEsCRrq9rJ0dr9pvChCMsfxqHMNt1y2uqaQ /B+Uo41NbTjWacyFdKWBO8/3xLVhga64YBTQCxK1V1MUJXt2JHfuaZdeB2twbjqERc9C fyrUpdEbvY2EntwQbYYjiiqs/+yusCVRRIBd0y2KHl5XbpwNVF/9ycZ6SgexZ4aB7/3B BbwsWWENP2ylwVhGm2jPewO/CyxROT3rLp5Wlr8jpFOqqzgfilEujERFXVfDE29Dq6qk 5Ou6oCEgXWiJHy5xVt6wqU04IlN83EXujVjO2vTWezdsSlzf1QIaFSPI6cdmmxXqNcqg skZQ== X-Gm-Message-State: AFeK/H1Rsn+4XyQai0vj5vW4NJeIrlqWC8bCJsLp+cDN1NT3ntE/BBEp5TF1zS9hR52uZWpl35AH3UMseodlDA== X-Received: by 10.129.172.23 with SMTP id k23mr20278348ywh.337.1491414430179; Wed, 05 Apr 2017 10:47:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 5 Apr 2017 10:46:29 -0700 (PDT) In-Reply-To: References: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in> From: Eric Rescorla Date: Wed, 5 Apr 2017 10:46:29 -0700 Message-ID: To: David Benjamin Cc: Benjamin Kaduk , Ryan Sleevi , R Balaji , Sankalp Bagaria , "Bagaria, Sankalp" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1bae0053076b054c6efbc3 Archived-At: Subject: Re: [TLS] Certificate compression draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 17:47:15 -0000 --94eb2c1bae0053076b054c6efbc3 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 10:45 AM, Eric Rescorla wrote: > > > On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin > wrote: > >> On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote: >> >>> On 04/05/2017 09:21 AM, Eric Rescorla wrote: >>> >>> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi >>> wrote: >>> >>> Does cached-info not represent a privacy info-leak by disclosing past >>> sessions prior to authenticating the new session? Versus compression, which >>> limits it to the session and thus reveals no new/additional information. >>> That was certainly true for TLS1.2 >>> >>> >>> This will also be true in TLS 1.3, even with encrypted certificates >>> because (hopefully) they >>> will be a lot smaller. Though you could of course pad out to the same >>> size :) >>> >>> >>> The elephant in the room being that an attacker watching the network can >>> replay the observed ClientHello but using its own KeyShare and read the >>> resulting encrypted certificate reply. (h/t davidben) >>> >> >> (Supposing that the server is a traditional server that accepts multiple >> requests and does not select the certificate based on external factors in >> the transport or elsewhere, which means you're selecting by things not >> covered by TLS's transcript.) >> >> Also, while one could compressed pad up to uncompressed length and make >> compression useless, hiding whether your certificate was compressed is not >> a plausible goal. More plausible is hiding which certificate was selected. >> >> Without compression, your certificates still have different lengths, so >> you would need to pad up to max(certificate_message(cert) for cert in >> certs) anyway, where certs is all identities your particular server wishes >> to make indistinguishable. Maybe chunk up to a boundary beyond that if you >> want. >> >> With compression, you pad up to max(compress(certificate_message(cert) >> for cert in certs). Maybe chunk up to a boundary beyond that if you want. >> (Packet boundary for the QUIC use case?) This means you're now bound by >> your worst cert rather than your selected cert, but one could still expect >> a size win. >> >> This is, of course, all assuming your server setup is somehow such that >> the above pachyderm doesn't apply. >> > > Sorry, yes, I should have mentioned this, especially as I just made the > same point to someone > else the other day. > > I think there are two threat models here: > > 1. Active attacker > 2. Passive attacker. > > As you indicate the active attacker can elicit the server's certificate by > replaying CH > with his own KeyShare (this is part of what makes SNI encryption so hard). > Or of course, if we had an SNI encryption mechanism that tied to KeyShare. -Ekr > > For a passive attacker, as David suggests, you can hide which cert was > selected > by padding up to the largest cert (whether the cert was compressed or > not). That > may or may not be valuable depending on the scenario [for instance in > WebRTC]. > As you say, I don't think you can hide the cache hit even from a passive > attacker > because then you would need to pad up to an unreasonable amount. > > -Ekr > > --94eb2c1bae0053076b054c6efbc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 5, 2017 at 10:45 AM, Eric Rescorla <ekr@rtfm.com>= wrote:


On Wed, Ap= r 5, 2017 at 10:15 AM, David Benjamin <davidben@chromium.org> wrote:
On Wed, Apr 5, 2017 at 12:14 PM Ben= jamin Kaduk <bkad= uk@akamai.com> wrote:
On 04/05/2017 09:21 AM, Eric Rescorla wrote:
=20
On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi <ryan-ietftls@sleevi.com> wrote:
=
Does cached-info not represent a privacy info-leak by disclosing past sessions prior to authenticating the new session? Versus compression, which limits it to the session and thus reveals no new/additional information. That was certainly true for TLS1.2

This will also be true in TLS 1.3, even with encrypted certificates because (hopefully) they
will be a lot smaller. Though you could of course pad out to the same size :)


The elephant in the room being that an attacker watching the network can replay the observed ClientHello but using its own KeyShare and read the resulting encrypted certificate reply.=C2=A0 (h/t davidben)

(Supposing that the server is a tradition= al server that accepts multiple requests and does not select the certificat= e based on external factors in the transport or elsewhere, which means you&= #39;re selecting by things not covered by TLS's transcript.)
=
Also, while one could compressed pad up to uncompressed leng= th and make compression useless, hiding whether your certificate was compre= ssed is not a plausible goal. More plausible is hiding which certificate wa= s selected.

Without compression, your certificates= still have different lengths, so you would need to pad up to max(certifica= te_message(cert) for cert in certs) anyway, where certs is all identities y= our particular server wishes to make indistinguishable. Maybe chunk up to a= boundary beyond that if you want.

With compressio= n, you pad up to max(compress(certificate_message(cert) for cert in ce= rts). Maybe chunk up to a boundary beyond that if you want. (Packet boundar= y for the QUIC use case?) This means you're now bound by your worst cer= t rather than your selected cert, but one could still expect a size win.

This is, of course, all assuming your server setup i= s somehow such that the above pachyderm doesn't apply.

Sorry, yes, I should have mentione= d this, especially as I just made the same point to someone
else = the other day.

I think there are two threat models= here:

1. Active attacker
2. Passive att= acker.

As you indicate the active attacker can eli= cit the server's certificate by replaying CH
with his own Key= Share (this is part of what makes SNI encryption so hard).=C2=A0

Or of course, if we had an SN= I encryption mechanism that tied to KeyShare.

-Ekr=
=C2=A0

For a= passive attacker, as David suggests, you can hide which cert was selected<= /div>
by padding up to the largest cert (whether the cert was compresse= d or not). That
may or may not be valuable depending on the scena= rio [for instance in WebRTC].
As you say, I don't think you c= an hide the cache hit even from a passive attacker
because then y= ou would need to pad up to an unreasonable amount.

-Ekr
=C2=A0

--94eb2c1bae0053076b054c6efbc3-- From nobody Wed Apr 5 11:05:21 2017 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 044071287A3 for ; Wed, 5 Apr 2017 11:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 0JoDS0OyO5Di for ; Wed, 5 Apr 2017 11:05:16 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9A382127337 for ; Wed, 5 Apr 2017 11:05:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id BF471216F5; Wed, 5 Apr 2017 21:05:14 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id pjXCjns76_Bj; Wed, 5 Apr 2017 21:05:14 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 9905F289; Wed, 5 Apr 2017 21:05:14 +0300 (EEST) Date: Wed, 5 Apr 2017 21:05:13 +0300 From: Ilari Liusvaara To: Karthikeyan Bhargavan Cc: Sam Scott , tls@ietf.org Message-ID: <20170405180513.GA9994@LK-Perkele-V2.elisa-laajakaista.fi> References: <4d42ad93-4dd4-99af-f90b-0ab61021bcfb@gmail.com> <946F8C1F-FC58-4D03-8EB9-D0B3BFAA59DE@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <946F8C1F-FC58-4D03-8EB9-D0B3BFAA59DE@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Current TLS 1.3 state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 18:05:19 -0000 On Wed, Apr 05, 2017 at 11:03:25AM +0200, Karthikeyan Bhargavan wrote: > What I am less confident about is the secure usage of features like > 0-RTT, 0.5 RTT, and post-handshake authentication. Two of those (0-RTT and post-handshake authentication) are among the the things that scare me. 0.5-RTT less so, because unless you abuse 0-RTT, 0.5-RTT is to _unidentified_ peer, which should limit the abuse potential quite a bit. Well, the protocol where PHA would have been a major problem (HTTP/2) moved away from it, to exported authenticators... -Ilari From nobody Wed Apr 5 12:23:56 2017 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 D20FC12941D for ; Wed, 5 Apr 2017 12:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.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 hkUjZgDtBFm4 for ; Wed, 5 Apr 2017 12:23:50 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 A6B5F127A90 for ; Wed, 5 Apr 2017 12:23:50 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id v76so10813853ywg.0 for ; Wed, 05 Apr 2017 12:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QiVT+bZE30Xu/fEZJ45tojCR/O8cz/92+FpDe5qxcz8=; b=d2UrE/c9I4Nk5nNxBCUNIV3quSL6C3pfsSQjOnvp/e/bbxFaVLfQ/tqP81Dk3CFSXh D5DyXXAQp+UPVSUvm9VpXSrOwmIA/nyPN60SINxSzUBkguPoIHbcv3/aOVSuUEajALFD 5byFvocCpjESnAyqgFhboTREXJGw3u/Gzx9F1yGqOVzUXYozDuRzrN3a73zlRyFXiQY/ uceGqd81J5TNAvyC4detZVTRorSWz8KEZaP+YcLvEYstBzhgPakw52BNvaE9LJwVx9DE wOmRGhRWa9wo+PMQB4hUAmWGn15DbgB4MXbfmyh0w21w3wlOmHkiuRhcdv9X+47h0ZX3 u6Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QiVT+bZE30Xu/fEZJ45tojCR/O8cz/92+FpDe5qxcz8=; b=pHj6aVRVLYpt+TehYR8NUEsKF11hBU3GU5TJsqA2Y0ugZ8I7+lPRKN0OaBonI7z7Ce xGV8H7i5UzlbZx9JdIFOVwqz2xfjay2L3CCr1JmplTWLly1gOn7sXqnSbYCvV24eiHn9 ms9++JnmaZvQKOuU5XNGxKtQD6ZNRwnlltzSI/BYqhipRSjhC6cvqRvGeWxBHVnJhsgG 2+xyu5cNt66lzt6EAIpSOJnwe1WE7FepCvvzRVuUhjgqSfhKuMWcwfO/NXbU39SEVApj POlUXy7X6xU415Tt98egBzd8jituOgIQBsOSq3kzaBXIrOzb9Qp2/0W0MbH7gmdMoTpZ gFHw== X-Gm-Message-State: AFeK/H2H1+v+HF1kzzUzGP/7DFh4dhIASqZLUnI7MZzCazljXXBKHyLElZt9EknBZQgUyAnyg6JuOprCAGWVAw== X-Received: by 10.13.214.22 with SMTP id y22mr21645049ywd.13.1491420229530; Wed, 05 Apr 2017 12:23:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.97.7 with HTTP; Wed, 5 Apr 2017 12:23:48 -0700 (PDT) In-Reply-To: <946F8C1F-FC58-4D03-8EB9-D0B3BFAA59DE@gmail.com> References: <4d42ad93-4dd4-99af-f90b-0ab61021bcfb@gmail.com> <946F8C1F-FC58-4D03-8EB9-D0B3BFAA59DE@gmail.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 5 Apr 2017 12:23:48 -0700 Message-ID: To: Karthikeyan Bhargavan Cc: Sam Scott , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05ee88fe1dfa054c705451 Archived-At: Subject: Re: [TLS] Current TLS 1.3 state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 19:23:55 -0000 --94eb2c05ee88fe1dfa054c705451 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 5, 2017 at 2:03 AM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > > What I am less confident about is the secure usage of features like 0-RTT, > 0.5 RTT, and post-handshake authentication. > Many researchers have looked at these aspects (and they can correct me if > I am wrong) but the security guarantees we can prove for these modes is > much more limited than for the regular 1-RTT handshake. My concern is that > these features will inspire new usage patterns will emerge for TLS 1.3 that > have not been adequately studied. I am not sure what we can do about that > except maybe work harder on the security considerations. > I'll be at TLS:DIV and presenting on 0RTT, which is forcing me to finally nail down all of my concerns in a more concrete and data-driven form. I do think it's fair to say that 0RTT is known to be insecure, in the sense that there are real-world attacks it will enable, and I haven't seen any of those disputed. Wether we should accept those is a matter of trade-offs, I don't think we should; they seem quite serious and really point the gun at the feet of the user. A warning saying 'You shouldn't use these without an application profile' is already failing in the market; with vendors deploying 0RTT anyway in unsafe cases. It goes against all of the neat encapsulation we've been trying to build for secure primitives. So for now, here's my high level summary: Replayability issues: 0RTT data is replayable, we know this. It includes a weak clock-based protection against against replay. If we take the CDN use-case, and realistic values for latency and clock drift, the mitigation ends up permitting many billions of replays. This is much much more than similar issues that have brought up before (e.g. browser retries). 1. Applications must be coded defensively against replay - e.g. they must be idempotency. But this is hard - and for mutating actions can only truly be achieved with tight-bound transactions at the application layer. Enclosing transactions don't work. But 0RTT is being incorporated "below" the application layer in a way that is very very likely to lead to a mis-match of expectations. 2. We can say that 0RTT shouldn't be used for non-mutating actions. But this is bad for two reasons. Reason "A" is that many services have throttles, even for reads, to prevent overload and abuse. If an attacker than replay 0RTT data and exhaust a throttle, this completes a denial of service attack, Reason "B" is that 0RTT is a very effective way to improve the performance of uploads. For architectural reasons, it's common for users to send photos over messaging, and for these photos to be uploaded to storage engines over TLS, while the URL is shared over the messaging protocol. This should be a good and valid use of 0RTT, but it certainly mutating and requires idempotency. Suggested mitigation for issues 1 and 2.: The 0RTT section should be unacknowledged at the TLS protocol layer. The client should send it, but the TLS layer should have no knowledge of whether or not it was decrypted/accepted. Instead the application should either tolerate it being re-sent as part of the regular application data, or should acknowledge it explicitly at the application layer. Side-channel defensiveness issues: 3. Replaying 0RTT data makes statistical analysis of side-channels far easier, at the application level and at the crypto level. At the crypto level, 0RTT opens us up to implementation side-channels that merely decloak the plaintext (rather than key) in a way we haven't quite had before. The attacker can feed the cipher text billions of times and learn things about it. The previous mitigation would help with this. At the application level, 0RTT makes it much easier to use application-level side channels. Here's a simple example: User requests some content from a CDN - what was it? Suppose we have a billion candidate URLs we want to probe and see what it was. We can make trial downloads of our candidates from the CDN and see what's warm in the cache; that helps us narrow it down. But with 0RTT we can also replay the request against other/cold CDN nodes, and cause them to fetch the target resource, which makes this kind of attack exponentially easier - to the point that it is trivial. There are neat combinatorial techniques that make finding the needle in the haystack easy. That's a pretty big dent in secrecy. 4. 0RTT data loses Forward Secrecy. This is a big deal because FS is one of our goals for TLS1.3. And it's a really big deal because 0RTT is where the most valuable parts of a session are likely be. It's the URLs you're accessing, it's your authentication tokens, and your credit card number. These all go in the early-phase of real-world requests precisely because the server needs them to process. If we don't provide FS for these, but do for the HTML you are downloading, is that really a wise combination of trade-offs? It seems very strange. Suggested mitigation for 3 and 4: 0RTT data shouldn't use session tickets. It should use server-side state, like a traditional session cache, and the keys should be single-use. E.g. use it once from the cache, and then erase it. This restores forward secrecy, prevents replays, and also is more robust against other side-channels (tickets are themselves more open to side-channel abuse, because tickets are replay-able). The counter-argument I've heard here is that "CDNs don't want server side state". But TCP fast open already relies on server side-state, CDNs are themselves massively distributed caches anyway, and route flaps between nodes seem to be uncommon. I don't quite see the big deal and there doesn't seem to be another way to provide security. Tickets with replay-ability just don't achieve it. I would also argue that TLS1.3 should not support tickets at all; and only cached single-use sessions. I recognize that will take a compelling set of arguments, and is a long way from the consensus. That's is why I'll be presenting in more detail, including about the economics of all of this. I'll ask for open minds. > -Karthik > > On 5 Apr 2017, at 10:44, Sam Scott wrote: > > I don't know what the state of the various modelling efforts is, though I > imagine > this will be a topic at TLS:DIV at the end of the month. We did discuss > the various > cryptographic changes in -20 (specifically the extra key derive stages and > the > handshake hash reification) with a number of cryptographers before > incorporating. > Perhaps some of the analytic groups on-list would care to comment? > > > From our* point of view we're pretty happy with the current state of the > spec. > Our initial results confirm that TLS achieves the core security properties > (secrecy and authentication). More specifically, we prove an absence of > attacks > against those properties in our model. > > We're currently waiting for the last version of the spec to be finalised > so that > we can make a more definitive statement and share our final results. > Although we > do not expect our analysis to be affected by the recent changes to the > spec, we > will still need to update our model and re-prove everything, which is > quite time > consuming. We will be talking at TLS:DIV so can share more then, including > what > is and isn't captured by our model. > > * Us being the Tamarin team: Cas Cremers, Marko Horvat, Jonathan Hoyland, > Sam Scott, and Thyla van der Merwe. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Colm --94eb2c05ee88fe1dfa054c705451 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 5, 2017 at 2:03 AM, Karthikeyan Bhargavan <karth= ik.bhargavan@gmail.com> wrote:

What I am less confident about is the se= cure usage of features like 0-RTT, 0.5 RTT, and post-handshake authenticati= on.
Many researchers have looked at these aspects (and they c= an correct me if I am wrong) but the security guarantees we can prove for t= hese modes is much more limited than for the regular 1-RTT handshake. My co= ncern is that these features will inspire new usage patterns will emerge fo= r TLS 1.3 that have not been adequately studied. I am not sure what we can = do about that except maybe work harder on the security considerations.

I'll be at TLS:DIV and presenti= ng on 0RTT, which is forcing me to finally nail down all of my concerns in = a more concrete and data-driven form. I do think it's fair to say that = 0RTT is known to be insecure, in the sense that there are real-world attack= s it will enable, and I haven't seen any of those disputed. Wether we s= hould accept those is a matter of trade-offs, I don't think we should; = they seem quite serious and really point the gun at the feet of the user.= =C2=A0 A warning saying 'You shouldn't use these without an applica= tion profile' is already failing in the market; with vendors deploying = 0RTT anyway in unsafe cases. It goes against all of the neat encapsulation = we've been trying to build for secure primitives.=C2=A0

<= /div>
So for now, here's my high level summary:

Replayability issues:

0RTT data is replayabl= e, we know this. It includes a weak clock-based protection against against = replay. If we take the CDN use-case, and realistic values for latency and c= lock drift, the mitigation ends up permitting many billions of replays. Thi= s is much much more than similar issues that have brought up before (e.g. b= rowser retries).=C2=A0

1. Applications must be cod= ed defensively against replay - e.g. they must be idempotency. But this is = hard - and for mutating actions can only truly be achieved with tight-bound= transactions at the application layer. Enclosing transactions don't wo= rk. But 0RTT is being incorporated "below" the application layer = in a way that is very very likely to lead to a mis-match of expectations.

2. We can say that 0RTT shouldn't be used for n= on-mutating actions. But this is bad for two reasons.=C2=A0

<= /div>
Reason "A" is that many services have throttles, even f= or reads, to prevent overload and abuse. If an attacker than replay 0RTT da= ta and exhaust a throttle, this completes a denial of service attack,=C2=A0=

Reason "B" is that 0RTT is a very effec= tive way to improve the performance of uploads. For architectural reasons, = it's common for users to send photos over messaging, and for these phot= os to be uploaded to storage engines over TLS, while the URL is shared over= the messaging protocol. This should be a good and valid use of 0RTT, but i= t certainly mutating and requires idempotency.=C2=A0

Suggested mitigation for issues 1 and 2.:=C2=A0
The 0RTT = section should be unacknowledged at the TLS protocol layer. The client shou= ld send it, but the TLS layer should have no knowledge of whether or not it= was decrypted/accepted. Instead the application should either tolerate it = being re-sent as part of the regular application data, or should acknowledg= e it explicitly at the application layer. =C2=A0

=

Side-channel defensiveness issues:

=
3. Replaying 0RTT data makes statistical analysis of side-channels far= easier, at the application level and at the crypto level.=C2=A0
=
At the crypto level, 0RTT opens us up to implementation side= -channels that merely decloak the plaintext (rather than key) in a way we h= aven't quite had before. The attacker can feed the cipher text billions= of times and learn things about it. The previous mitigation would help wit= h this.=C2=A0

At the application level, 0RTT makes= it much easier to use application-level side channels. Here's a simple= example: User requests some content from a CDN - what was it? Suppose we h= ave a billion candidate URLs we want to probe and see what it was. We can m= ake trial downloads of our candidates from the CDN and see what's warm = in the cache; that helps us narrow it down. But with 0RTT we can also repla= y the request against other/cold CDN nodes, and cause them to fetch the tar= get resource, which makes this kind of attack exponentially easier - to the= point that it is trivial. There are neat combinatorial techniques that mak= e finding the needle in the haystack easy. That's a pretty big dent in = secrecy.

4. 0RTT data loses Forward Secrecy.
=

This is a big deal because FS is one of our goals for T= LS1.3. And it's a really big deal because 0RTT is where the most valuab= le parts of a session are likely be. It's the URLs you're accessing= , it's your authentication tokens, and your credit card number. These a= ll go in the early-phase of real-world requests precisely because the serve= r needs them to process. If we don't provide FS for these, but do for t= he HTML you are downloading, is that really a wise combination of trade-off= s? It seems very strange.

Suggested mitigation for= 3 and 4:
0RTT data shouldn't use session tickets. It should = use server-side state, like a traditional session cache, and the keys shoul= d be single-use. E.g. use it once from the cache, and then erase it. This r= estores forward secrecy, prevents replays, and also is more robust against = other side-channels (tickets are themselves more open to side-channel abuse= , because tickets are replay-able).=C2=A0

The coun= ter-argument I've heard here is that "CDNs don't want server s= ide state". But TCP fast open already relies on server side-state, CDN= s are themselves massively distributed caches anyway, and route flaps betwe= en nodes seem to be uncommon. I don't quite see the big deal and there = doesn't seem to be another way to provide security. Tickets with replay= -ability just don't achieve it.=C2=A0

I would = also argue that TLS1.3 should not support tickets at all; and only cached s= ingle-use sessions. I recognize that will take a compelling set of argument= s, and is a long way from the consensus. That's is why I'll be pres= enting in more detail, including about the economics of all of this. I'= ll ask for open minds.=C2=A0


-Karthik

On 5 Apr 2= 017, at 10:44, Sam Scott <sam.scott89@gmail.com> wrote:

I don't know what the state of the various modelling efforts = is, though I imagine
this will be a topic at TLS:DIV at the end of the m= onth. We did discuss the various
cryptographic changes in -20 (specifica= lly the extra key derive stages and the
handshake hash reification) with= a number of cryptographers before incorporating.
Perhaps some of the an= alytic groups on-list would care to comment?

From our* = point of view we're pretty happy with the current state of the spec.Our initial results confirm that TLS achieves the core security properties=
(secrecy and authentication). More specifically, we prove an absence of= attacks
against those properties in our model.

We're current= ly waiting for the last version of the spec to be finalised so that
we c= an make a more definitive statement and share our final results. Although w= e
do not expect our analysis to be affected by the recent changes to the= spec, we
will still need to update our model and re-prove everything, w= hich is quite time
consuming. We will be talking at TLS:DIV so can share= more then, including what
is and isn't captured by our model.
* Us being the Tamarin team: Cas Cremers, Marko Horvat, Jonathan Hoyland,=
Sam Scott, and Thyla van der Merwe.

____________________________= ___________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/l= istinfo/tls


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls




--
Colm
--94eb2c05ee88fe1dfa054c705451-- From nobody Wed Apr 5 12:30:43 2017 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 68B8B12948B for ; Wed, 5 Apr 2017 12:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 6LxdtXEdYv6R for ; Wed, 5 Apr 2017 12:30:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F8612946D for ; Wed, 5 Apr 2017 12:30:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1CEA2BE79; Wed, 5 Apr 2017 20:30:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeCyH8WDp23p; Wed, 5 Apr 2017 20:30:32 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A8598BE74; Wed, 5 Apr 2017 20:30:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1491420632; bh=1inxc+iPGQ+YqhOdidfxuLOVWy9u1xRJA7d6u3buHFM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Wq4ciZm6gPyyqdLh6ZBLQJufVtQp11mWVcn/ybu8FXSt1FJtNrLZmh3Tra/KkfV+E e+enpINUaU5r4jYn+8oIe1DbyM99Kw/3bk8R5iOH8ezF003QlMLA6g5AJW1S8XokT6 4/uQYBxO9Gb5ZRqCwRd8H1YZc/A58nZPJth0iyEk= To: Subodh Iyengar , Simon Friedberger , "tls@ietf.org" , Richard Salz , "Kaduk, Ben" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 5 Apr 2017 20:30:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Nuq4v4IIj8IAAfvdlOkusWLBvvbgsOgrd" Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 19:30:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Nuq4v4IIj8IAAfvdlOkusWLBvvbgsOgrd Content-Type: multipart/mixed; boundary="paCFl0vHJ7STfLJqcFbTDD9eG5RSmDOa1"; protected-headers="v1" From: Stephen Farrell To: Subodh Iyengar , Simon Friedberger , "tls@ietf.org" , Richard Salz , "Kaduk, Ben" Message-ID: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts References: In-Reply-To: --paCFl0vHJ7STfLJqcFbTDD9eG5RSmDOa1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've no strong opinion for or against this. One question below though. On 05/04/17 17:07, Subodh Iyengar wrote: > The threat model here is that since if a less-trusted host having a > key is compromised for a certain period of time without detection, > and an attacker can steal private keys during that period. In many > situations we are fine with giving the TLS terminator a certificate / > key, i.e. they actually have a trust relationship, however we want a > compromise to only give the attacker a limited power to use the > credential. Revocation is arguably effective, so we would not be okay > with giving a less trusted host a long term private key. However we'd > be okay with giving a less-trusted host a short term key. With that goal in mind, wouldn't it help mitigate the threat if the holder of the longer term credential (the cert subject) were to include within the signature e.g. an IP address range within which the delegated credential is allowed to be used? Cheers, S. --paCFl0vHJ7STfLJqcFbTDD9eG5RSmDOa1-- --Nuq4v4IIj8IAAfvdlOkusWLBvvbgsOgrd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY5UXXAAoJEC88hzaAX42ioW8H/ijp9CYQONh/eVu2yUK4zxO1 bfQ3kul9Pd9VL46sO2ZdJEhn3VqaVqMi6UaJypAT6p+ATD7C6iCbpR6gRMNfEgBn 5gh2VnJSGs8jON5PAf8J7JP+3QWlMyQv6J3otWvN8f/QqNmBPLrEtQPmFT4gDas9 VOHC5EAjj6IWo0TFz2tgDqsLwYhhOMxXzsngxSD9ItPHoy6KuVs29Tj6146qklw/ X/+TJsWoa5cTXrsam9sH3zcP8+LrqioBhDrsin6J3GjylBfFclmAfB3Vp3qotElL lOy1mnWD/tp3LpH5vM8sVwmIxK0uPgg7YUOhT2f3kxpXvJOPawNby2ZG79I5DSY= =PWe6 -----END PGP SIGNATURE----- --Nuq4v4IIj8IAAfvdlOkusWLBvvbgsOgrd-- From nobody Wed Apr 5 13:20:38 2017 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 CBA17129484 for ; Wed, 5 Apr 2017 13:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=rOYaqni4; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ZPj3Z/TB 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 c-J00_RmfCyq for ; Wed, 5 Apr 2017 13:20:34 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F5A12948B for ; Wed, 5 Apr 2017 13:20:33 -0700 (PDT) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v35KIEXe009891; Wed, 5 Apr 2017 13:20:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=8vFB6mXwdJxnFZ5Hi5uvre5fg7v1N9SaQCHLKckjeEg=; b=rOYaqni4ClplcuBV9u/5SUSlp5Dplf7m5Hjc6oBavjTVdbjsbMio7xurSnirxcZAawmt bX44jIyWhQRoHNprkX9m+fQIBFpliechbmldhyvmJDQkaQwTbLF18LGKUhdUt7xKJlpm IJWo3pfgHHyxt9FFJFCorlCsxasqQBFP1s8= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 29n2dbsddm-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 05 Apr 2017 13:20:07 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.24) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 5 Apr 2017 13:20:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8vFB6mXwdJxnFZ5Hi5uvre5fg7v1N9SaQCHLKckjeEg=; b=ZPj3Z/TBmsXQOUsLG0UHMHf1+v2Hon/wzrPRKVcMX3if8bdknsepbk97uwmQ2snLS4L7z1ZIxmeJoA40DCEverVCKs0UjM+cUL9CKyhiLooA+YfEsEFgyrn73ei63rFtYV0rehjhw5Ok2YLebHnvVI7WpvGiw90Ad6aUyZS+7cw= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1456.namprd15.prod.outlook.com (10.173.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Wed, 5 Apr 2017 20:20:03 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1005.020; Wed, 5 Apr 2017 20:20:04 +0000 From: Subodh Iyengar To: Stephen Farrell , Simon Friedberger , "tls@ietf.org" , Richard Salz , "Kaduk, Ben" Thread-Topic: [TLS] security considerations for draft-rescorla-tls-subcerts Thread-Index: AQHSqaBOocVmAQvSZkGxKH7FNtBXA6GxLuRegASs84CAAOJSgIAAAPGAgAAA7ICAAC8aD4AAQ8yAgAANcWM= Date: Wed, 5 Apr 2017 20:20:03 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1456; 7:R5+SVsIEm6IUfkK8J+Jf/neUZ7Lk4YOKqocm6x/S/FEF1Kkklsf+y9iKqSEpOjQzvg0b3AqKaP5BtrBxuE4KLX1BEdUVB2IVHFhPrsKcO63IC/MSpGfsysI/g2qsNmQQKlfWYZkNO8++AmhC3QNw1ACd/pkLWYyqHikivqhWcTqywlSJ+6plw9XdqG5ZxdzUOzefXcibUfEGBH8DoJSecf3XSJ3KgFfbbHLbbpmuzPICAYLpddE+uDKNJXr7gnB0/HZN2DB9K1kE0gDoxNQNONI4+MFmtSKA2siaERNg4bPk9J+wLNTvz9gU7BL3rdk7s8o8K1JnuXFdUfD76kNZTw==; 20:sm8eDHfr1W0NMeGuq0wibN8ewfQ+ujFxrCmaIFOwfM52CCN6sR1zRwKTrz4JuwMrr2oSg+pnmgVK/grk8wOwrZ1+eUORXAQdwg9rQrhTXArWjkx3Y/Azky4xWn5WWkutosmrPa3x9UanAQekkR6Rv0/tapwtmtfM9YAYX0IgABI= x-ms-office365-filtering-correlation-id: cea1afdf-6a3b-4349-02f1-08d47c612501 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:MWHPR15MB1456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(6072148); SRVR:MWHPR15MB1456; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1456; x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39850400002)(39400400002)(39840400002)(377454003)(24454002)(55016002)(66066001)(189998001)(6246003)(81166006)(25786009)(229853002)(54896002)(2950100002)(8676002)(74316002)(99286003)(6116002)(9686003)(3846002)(102836003)(2501003)(77096006)(53546009)(2900100001)(7736002)(5660300001)(7696004)(53936002)(33656002)(50986999)(76176999)(38730400002)(122556002)(93886004)(3280700002)(54356999)(3660700001)(230783001)(15650500001)(6506006)(2906002)(6436002)(8936002)(39060400002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1456; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455C7BE1C32A3FADD8759FAB60A0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 20:20:03.7705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1456 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_15:, , signatures=0 Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 20:20:36 -0000 --_000_MWHPR15MB1455C7BE1C32A3FADD8759FAB60A0MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > With that goal in mind, wouldn't it help mitigate the threat if the holder of the longer term credential (the cert subject) were to include within the signature e.g. an IP address range within which the delegated credential is allowed to be used? We thought about this originally, but we discounted this because it breaks = when http and socks proxies are used. Looking at some data I had a non triv= ial number of requests access our site using proxies. I'm not sure whether = there's a good method for a client to enforce ip address ranges when a prox= y does the dns resolution. Subodh ________________________________ From: Stephen Farrell Sent: Wednesday, April 5, 2017 12:30:31 PM To: Subodh Iyengar; Simon Friedberger; tls@ietf.org; Richard Salz; Kaduk, B= en Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts I've no strong opinion for or against this. One question below though. On 05/04/17 17:07, Subodh Iyengar wrote: > The threat model here is that since if a less-trusted host having a > key is compromised for a certain period of time without detection, > and an attacker can steal private keys during that period. In many > situations we are fine with giving the TLS terminator a certificate / > key, i.e. they actually have a trust relationship, however we want a > compromise to only give the attacker a limited power to use the > credential. Revocation is arguably effective, so we would not be okay > with giving a less trusted host a long term private key. However we'd > be okay with giving a less-trusted host a short term key. With that goal in mind, wouldn't it help mitigate the threat if the holder of the longer term credential (the cert subject) were to include within the signature e.g. an IP address range within which the delegated credential is allowed to be used? Cheers, S. --_000_MWHPR15MB1455C7BE1C32A3FADD8759FAB60A0MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> With = that goal in mind, wouldn't it help mitigate the threat if
the holder of the = longer term credential (the cert subject) were
to include within = the signature e.g. an IP address range within
which the delegate= d credential is allowed to be used?

We thought about this originally, but we discounted this because it breaks = when http and socks proxies are used. Looking at some data I had a non triv= ial number of requests access our site using proxies. I'm not sure whe= ther there's a good method for a client to enforce ip address ranges when a proxy does the dns resolution.


Subodh

From: Stephen Farrell <= ;stephen.farrell@cs.tcd.ie>
Sent: Wednesday, April 5, 2017 12:30:31 PM
To: Subodh Iyengar; Simon Friedberger; tls@ietf.org; Richard Salz; K= aduk, Ben
Subject: Re: [TLS] security considerations for draft-rescorla-tls-su= bcerts
 

I've no strong opinion for or against this. One question below
though.

On 05/04/17 17:07, Subodh Iyengar wrote:
> The threat model here is that since if a less-trusted host having a > key is compromised for a certain period of time without detection,
> and an attacker can steal private keys during that period. In many
> situations we are fine with giving the TLS terminator a certificate /<= br> > key, i.e. they actually have a trust relationship, however we want a > compromise to only give the attacker a limited power to use the
> credential. Revocation is arguably effective, so we would not be okay<= br> > with giving a less trusted host a long term private key. However we'd<= br> > be okay with giving a less-trusted host a short term key.

With that goal in mind, wouldn't it help mitigate the threat if
the holder of the longer term credential (the cert subject) were
to include within the signature e.g. an IP address range within
which the delegated credential is allowed to be used?

Cheers,
S.

 --_000_MWHPR15MB1455C7BE1C32A3FADD8759FAB60A0MWHPR15MB1455namp_-- From nobody Wed Apr 5 14:52:37 2017 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 0C11E1294B9 for ; Wed, 5 Apr 2017 14:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 DppLa_Jc_s06 for ; Wed, 5 Apr 2017 14:52:30 -0700 (PDT) Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DEB1294A2 for ; Wed, 5 Apr 2017 14:52:28 -0700 (PDT) Received: from [81.164.186.174] (helo=[192.168.0.234]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cvsqZ-0007jG-PP for tls@ietf.org; Wed, 05 Apr 2017 23:52:26 +0200 To: "tls@ietf.org" References: From: Simon Friedberger Message-ID: Date: Wed, 5 Apr 2017 23:52:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 21:52:32 -0000 On 05/04/17 18:07, Subodh Iyengar wrote: > > The threat model here is that since if a less-trusted host having a > key is compromised for a certain period of time without detection, and > an attacker can steal private keys during that period. In many > situations we are fine with giving the TLS terminator a certificate / > key, i.e. they actually have a trust relationship, however we want a > compromise to only give the attacker a limited power to use the > credential. Revocation is arguably effective, so we would not be okay > with giving a less trusted host a long term private key. However we'd > be okay with giving a less-trusted host a short term key. > Your argument hinges somewhat on the ineffectiveness of revocation but I'm not sure how true that it is. Also, if it is shouldn't the fix be applied there instead? > > To me the increase in security weighted with the difficulty of > obtaining > such short-lived certificates from a CA probably does not justify the > extra > complexity of adding subcerts. > > > @Simon Friedberger Do you feel that short lived CA certificates are > actually deployable in large server deployments? I do not see that to > be the case. I see a security gain here but just being able to deploy > short lived credentials to not only less trusted locations, but also > to more trusted locations as well which is another use case that I > want to use this for. > You original mail seemed to imply that is doable but tedious and given that some CAs seem to offer interfaces that can be automated it should be possible for many servers but I am in no way an expert on the matter. Considering however the very specific case that is required for a security gain (undetected & temporary compromise & revocation ineffective) it might still not be worth the increased complexity. Also, take into account that a compromise that leaks certificates will potentially put an adversary in a position to carry out whatever attack he wants to perform directly without stealing the certificates. But I'm not saying there is no security gain, I just wanted to point out that it seems to me it's not worth any extra complexity. Best, Simon From nobody Thu Apr 6 01:08:02 2017 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 B64FB129416 for ; Thu, 6 Apr 2017 01:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.918 X-Spam-Level: X-Spam-Status: No, score=-6.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 9WhhqCttGjCK for ; Thu, 6 Apr 2017 01:07:57 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B175F128CB9 for ; Thu, 6 Apr 2017 01:07:55 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id v3687oYs014816 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 Apr 2017 10:07:50 +0200 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id v3687oD3003398 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Apr 2017 10:07:50 +0200 Received: from DEFTHW99EROMSX.ww902.siemens.net (139.22.70.201) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 6 Apr 2017 10:07:49 +0200 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.223]) by DEFTHW99EROMSX.ww902.siemens.net ([139.22.70.201]) with mapi id 14.03.0339.000; Thu, 6 Apr 2017 10:07:49 +0200 From: "Fries, Steffen" To: Eric Rescorla CC: =?utf-8?B?SGFubm8gQsO2Y2s=?= , "tls@ietf.org" Thread-Topic: [TLS] Support of integrity only cipher suites in TLS 1.3 Thread-Index: AdKsldO7ZRItAwyZRXCzcLu6YsWN5QAtyDcAADhSsSD//+begP/+6nFw Date: Thu, 6 Apr 2017 08:07:48 +0000 Message-ID: References: <20170404180838.08ca99cc@pc1> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.13] Content-Type: multipart/alternative; boundary="_000_E6C9F0E527F94F4692731382340B337847FAF5DENBGAT9EH2MSXww9_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Apr 2017 08:08:00 -0000 --_000_E6C9F0E527F94F4692731382340B337847FAF5DENBGAT9EH2MSXww9_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ICBhcmUgcmlnaHQsIEkgZGlkIG5vdCB0YWtlIHRoYXQgb3B0aW9uIGludG8gYWNjb3VudC4g QnV0IGFzIHlvdSBtZW50aW9uZWQsIGl0IGlzIG5vbi1zdGFuZGFyZCBhbmQgd2l0aCB0aGUgZGVz aXJlIGlzIHRvIGJlIGludGVyb3BlcmFibGUgYXMgbW9zdCBhcyBwb3NzaWJsZSwgcHJvcHJpZXRh cnkgZW5oYW5jZW1lbnRzIGFyZSBsaWtlbHkgbm90IHRvIGJlIGZhdm9yZWQuDQoNCmJlc3QgcmVn YXJkcw0KU3RlZmZlbg0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29t XQ0KU2VudDogTWl0dHdvY2gsIDUuIEFwcmlsIDIwMTcgMTk6MzENClRvOiBGcmllcywgU3RlZmZl biAoQ1QgUkRBIElUUykNCkNjOiBIYW5ubyBCw7ZjazsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW1RMU10gU3VwcG9ydCBvZiBpbnRlZ3JpdHkgb25seSBjaXBoZXIgc3VpdGVzIGluIFRMUyAx LjMNCg0KV2l0aG91dCB0YWtpbmcgYSBwb3NpdGlvbiBvbiBudWxsIGNpcGhlciBzdWl0ZXMsIEkg d291bGQgb2JzZXJ2ZSB0aGF0IHRoZSBuZXcgVExTIElBTkEgcnVsZXMgd2lsbCBsZXQgeW91IHJl Z2lzdGVyIHlvdXIgb3duIChub24tc3RhbmRhcmQsIG5vbi1yZWNvbW1lbmRlZCkgY29kZSBwb2lu dHMgZm9yIGludGVncml0eS1vbmx5IHN1aXRlcy4NCg0KLUVrcg0KDQoNCk9uIFdlZCwgQXByIDUs IDIwMTcgYXQgMTA6MTQgQU0sIEZyaWVzLCBTdGVmZmVuIDxzdGVmZmVuLmZyaWVzQHNpZW1lbnMu Y29tPG1haWx0bzpzdGVmZmVuLmZyaWVzQHNpZW1lbnMuY29tPj4gd3JvdGU6DQpBZGRpbmcgc3Vj aCBhIG1vZGUgd291bGQgYWRkIGFkZGl0aW9uYWwgY29tcGxleGl0eSB0aGF0IG1pZ2h0IGxlYWQg dG8gdnVsbmVyYWJpbHRpaWVzLCBlLmcuIGltcGxlbWVudGF0aW9ucyB0aGF0IGNhbiBiZSB0cmlj a2VkIGludG8gdXNpbmcgYSBub25lbmNyeXB0ZWQgbW9kZS4NCltbc3RmXV0gaW4gcHJpbmNpcGxl IHllcywgYXMgdGhpcyBzaW1wbGlmaWVzIHRoZSBjb25maWd1cmF0aW9uIGFuZCBwb2xpY3kgaGFu ZGxpbmcuIE9uIHRoZSBvdGhlciBoYW5kIGl0IGlzIGEgc2VjdXJpdHkgcG9saWN5IHBvaW50IHRv IGFsbG93IGNlcnRhaW4gY2lwaGVyIHN1aXRlcy4NCg0KSXQncyBiZWVuIGEgdHJlbmQgaW4gdGhl IHRscyB3b3JraW5nIGdyb3VwIHRvDQphKSByZWR1Y2UgY29tcGxleGl0eSB3aGVuIHBvc3NpYmxl Lg0KW1tzdGZdXSB1bmRlcnN0b29kLCBtYWtlcyBvcGVyYXRpb24gbGVzcyBlcnJvciBwcm9uZQ0K DQpiKSBub3QgdHJ5IHRvIGFjY29tb2RhdGUgb2JzY3VyZSB1c2UgY2FzZXMgdGhhdCBhcmVuJ3Qg cmVsZXZhbnQgZm9yIHRoZSBtYWpvcml0eSBvZiBUTFMgdXNlIGNhc2VzLg0KW1tzdGZdXSB3ZWxs LCBhcyBUTFMgaXMgdXNlZCBpbiB1c2UgY2FzZXMgbGlrZSBlbmVyZ3kgYXV0b21hdGlvbiwgaW5k dXN0cmlhbCBjb250cm9sLCByYWlsd2F5IGF1dG9tYXRpb24gZXRjLiB0aGVyZSBpcyBhbiBpbmNy ZWFzaW5nIG51bWJlciBvZiB1c2UgY2FzZXMgYXBwbHlpbmcgVExTIGFuZCB0aGVyZSBhcmUgc29t ZSwgd2hpY2ggd291bGQgbGV2ZXJhZ2UgaW50ZWdyaXR5IG9ubHkgZm9yIGFsbG93aW5nIGZvciBt b25pdG9yaW5nDQoNClRodXMgSSBhc3N1bWUgYSBudWxsIGNpcGhlciB3b24ndCBmaW5kIHN1cHBv cnQgaGVyZS4gSWYgeW91IHdhbnQgdG8gaGF2ZSB0cmFmZmljIGluc3BlY3Rpb24gd2l0aCBUTFMg aW1obyB0aGUgcmlnaHQgd2F5IGlzIHRvIHN1cHBvcnQgdGhhdCBhdCB0aGUgZW5kIHBvaW50cyAo bGV0IGFsb25lIGFueSBhcmd1bWVudHMgd2h5IHlvdSdyZSBkb2luZyB0cmFmZmljIGluc3BlY3Rp b24gaW4gdGhlIGZpcnN0IHBsYWNlIGFuZCB3aGV0aGVyIHRob3NlIHJlYXNvbnMgYXJlIGdvb2Qg b25lcykuDQpbW3N0Zl1dIEluIHByaW5jaXBsZSB5ZXMsIGJ1dCB0aGUgZW5kcG9pbnRzIGFyZSBv ZnRlbiBsaW1pdGVkIGFuZCBtYXkgbm90IHN1cHBvcnQgdGhpcyB0eXBlIG9mIGZ1bmN0aW9uYWxp dHkuIEFnYWluLCB0aGUgdHJhZmZpYyBpbnNwZWN0aW9uIGluIGF1dG9tYXRpb24gcmVsYXRlZCBj b21tdW5pY2F0aW9uIGlzIGRvbmUgZm9yIGF1ZGl0aW5nIGFuZCBtb25pdG9yaW5nIG9mIHRoZSBj b250cm9sIGZsb3cuIEluIHRoZSBleGFtcGxlIG9mIGVuZXJneSBhdXRvbWF0aW9uLCBUTFMgaXMg YWx3YXlzIHVzZWQgd2l0aCBtdXR1YWwgYXV0aGVudGljYXRpb24uIFNvIGJvdGggcGVlcnMga25v dyBlYWNoIG90aGVyLg0KDQpJZiB5b3UgZG9uJ3QgbGlrZSB0aGF0IHRoZW4gVExTIG1heSBiZSBu b3QgdGhlIHJpZ2h0IHByb3RvY29sIGZvciB5b3VyIHVzZSBjYXNlLg0KW1tzdGZdXSBJdCB3YXMg cG9zc2libGUgdG8gbm93IGFuZCBpdCBpcyBnb29kIHRvIHJlbHkgb24gYSBwcm90b2NvbCBsaWtl IFRMUywgd2hpY2ggaXMgZGVmaW5lZCBhbmQgZGlzY3Vzc2VkIGluIHRoaXMgd2F5IGluIHRoZSBJ RVRGLiBJbiB0aGUgSUVDICh3aGljaCBpcyBlbmdhZ2VkIEkgZW5lcmd5IGF1dG9tYXRpb24gY29t bXVuaWNhdGlvbiBkZWZpbml0aW9uKSB0aGVyZSBpcyB0aGUgZGVzaXJlIHRvIHVzZSBzdGFuZGFy ZGl6ZWQgc2VjdXJpdHkgcHJvdG9jb2xzIGF2YWlsYWJsZSB0byBhdm9pZCB0aGUgZGVmaW5pdGlv biBvZiBvd24gc29sdXRpb25zLCB3aGVuZXZlciBwb3NzaWJsZS4NCg0KLS0NCkhhbm5vIELDtmNr DQpodHRwczovL2hib2Vjay5kZS8NCg0KbWFpbC9qYWJiZXI6IGhhbm5vQGhib2Vjay5kZTxtYWls dG86aGFubm9AaGJvZWNrLmRlPg0KR1BHOiBGRTczNzU3RkE2MEU0RTIxQjkzNzU3OUZBNTg4MDA3 MkJCQjUxRTQyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExT QGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Rscw0KDQo= --_000_E6C9F0E527F94F4692731382340B337847FAF5DENBGAT9EH2MSXww9_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91Jm5ic3A7IGFyZSByaWdodCwgSSBkaWQg bm90IHRha2UgdGhhdCBvcHRpb24gaW50byBhY2NvdW50LiBCdXQgYXMgeW91IG1lbnRpb25lZCwg aXQgaXMgbm9uLXN0YW5kYXJkIGFuZCB3aXRoIHRoZSBkZXNpcmUgaXMgdG8gYmUgaW50ZXJvcGVy YWJsZSBhcyBtb3N0IGFzIHBvc3NpYmxlLA0KIHByb3ByaWV0YXJ5IGVuaGFuY2VtZW50cyBhcmUg bGlrZWx5IG5vdCB0byBiZSBmYXZvcmVkLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmJlc3QgcmVnYXJkczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdGVmZmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IE1pdHR3b2NoLCA1LiBBcHJpbCAyMDE3IDE5OjMxPGJyPg0KPGI+VG86PC9i PiBGcmllcywgU3RlZmZlbiAoQ1QgUkRBIElUUyk8YnI+DQo8Yj5DYzo8L2I+IEhhbm5vIELDtmNr OyB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIFN1cHBvcnQgb2Yg aW50ZWdyaXR5IG9ubHkgY2lwaGVyIHN1aXRlcyBpbiBUTFMgMS4zPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5XaXRob3V0IHRha2luZyBhIHBvc2l0aW9uIG9uIG51 bGwgY2lwaGVyIHN1aXRlcywgSSB3b3VsZCBvYnNlcnZlIHRoYXQgdGhlIG5ldyBUTFMgSUFOQSBy dWxlcyB3aWxsIGxldCB5b3UgcmVnaXN0ZXIgeW91ciBvd24gKG5vbi1zdGFuZGFyZCwgbm9uLXJl Y29tbWVuZGVkKSBjb2RlIHBvaW50cyBmb3IgaW50ZWdyaXR5LW9ubHkgc3VpdGVzLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gV2VkLCBB cHIgNSwgMjAxNyBhdCAxMDoxNCBBTSwgRnJpZXMsIFN0ZWZmZW4gJmx0OzxhIGhyZWY9Im1haWx0 bzpzdGVmZmVuLmZyaWVzQHNpZW1lbnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3RlZmZlbi5mcmll c0BzaWVtZW5zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QWRkaW5nIHN1Y2ggYSBtb2RlIHdv dWxkIGFkZCBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgdGhhdCBtaWdodCBsZWFkIHRvIHZ1bG5lcmFi aWx0aWllcywgZS5nLiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBjYW4gYmUgdHJpY2tlZCBpbnRvIHVz aW5nIGEgbm9uZW5jcnlwdGVkIG1vZGUuPGJyPg0KW1tzdGZdXSBpbiBwcmluY2lwbGUgeWVzLCBh cyB0aGlzIHNpbXBsaWZpZXMgdGhlIGNvbmZpZ3VyYXRpb24gYW5kIHBvbGljeSBoYW5kbGluZy4g T24gdGhlIG90aGVyIGhhbmQgaXQgaXMgYSBzZWN1cml0eSBwb2xpY3kgcG9pbnQgdG8gYWxsb3cg Y2VydGFpbiBjaXBoZXIgc3VpdGVzLjxicj4NCjxicj4NCkl0J3MgYmVlbiBhIHRyZW5kIGluIHRo ZSB0bHMgd29ya2luZyBncm91cCB0bzxicj4NCmEpIHJlZHVjZSBjb21wbGV4aXR5IHdoZW4gcG9z c2libGUuPGJyPg0KW1tzdGZdXSB1bmRlcnN0b29kLCBtYWtlcyBvcGVyYXRpb24gbGVzcyBlcnJv ciBwcm9uZTxicj4NCjxicj4NCmIpIG5vdCB0cnkgdG8gYWNjb21vZGF0ZSBvYnNjdXJlIHVzZSBj YXNlcyB0aGF0IGFyZW4ndCByZWxldmFudCBmb3IgdGhlIG1ham9yaXR5IG9mIFRMUyB1c2UgY2Fz ZXMuPGJyPg0KW1tzdGZdXSB3ZWxsLCBhcyBUTFMgaXMgdXNlZCBpbiB1c2UgY2FzZXMgbGlrZSBl bmVyZ3kgYXV0b21hdGlvbiwgaW5kdXN0cmlhbCBjb250cm9sLCByYWlsd2F5IGF1dG9tYXRpb24g ZXRjLiB0aGVyZSBpcyBhbiBpbmNyZWFzaW5nIG51bWJlciBvZiB1c2UgY2FzZXMgYXBwbHlpbmcg VExTIGFuZCB0aGVyZSBhcmUgc29tZSwgd2hpY2ggd291bGQgbGV2ZXJhZ2UgaW50ZWdyaXR5IG9u bHkgZm9yIGFsbG93aW5nIGZvciBtb25pdG9yaW5nPGJyPg0KPGJyPg0KVGh1cyBJIGFzc3VtZSBh IG51bGwgY2lwaGVyIHdvbid0IGZpbmQgc3VwcG9ydCBoZXJlLiBJZiB5b3Ugd2FudCB0byBoYXZl IHRyYWZmaWMgaW5zcGVjdGlvbiB3aXRoIFRMUyBpbWhvIHRoZSByaWdodCB3YXkgaXMgdG8gc3Vw cG9ydCB0aGF0IGF0IHRoZSBlbmQgcG9pbnRzIChsZXQgYWxvbmUgYW55IGFyZ3VtZW50cyB3aHkg eW91J3JlIGRvaW5nIHRyYWZmaWMgaW5zcGVjdGlvbiBpbiB0aGUgZmlyc3QgcGxhY2UgYW5kIHdo ZXRoZXIgdGhvc2UgcmVhc29ucw0KIGFyZSBnb29kIG9uZXMpLjxicj4NCltbc3RmXV0gSW4gcHJp bmNpcGxlIHllcywgYnV0IHRoZSBlbmRwb2ludHMgYXJlIG9mdGVuIGxpbWl0ZWQgYW5kIG1heSBu b3Qgc3VwcG9ydCB0aGlzIHR5cGUgb2YgZnVuY3Rpb25hbGl0eS4gQWdhaW4sIHRoZSB0cmFmZmlj IGluc3BlY3Rpb24gaW4gYXV0b21hdGlvbiByZWxhdGVkIGNvbW11bmljYXRpb24gaXMgZG9uZSBm b3IgYXVkaXRpbmcgYW5kIG1vbml0b3Jpbmcgb2YgdGhlIGNvbnRyb2wgZmxvdy4gSW4gdGhlIGV4 YW1wbGUgb2YgZW5lcmd5DQogYXV0b21hdGlvbiwgVExTIGlzIGFsd2F5cyB1c2VkIHdpdGggbXV0 dWFsIGF1dGhlbnRpY2F0aW9uLiBTbyBib3RoIHBlZXJzIGtub3cgZWFjaCBvdGhlci48YnI+DQo8 YnI+DQpJZiB5b3UgZG9uJ3QgbGlrZSB0aGF0IHRoZW4gVExTIG1heSBiZSBub3QgdGhlIHJpZ2h0 IHByb3RvY29sIGZvciB5b3VyIHVzZSBjYXNlLjxicj4NCltbc3RmXV0gSXQgd2FzIHBvc3NpYmxl IHRvIG5vdyBhbmQgaXQgaXMgZ29vZCB0byByZWx5IG9uIGEgcHJvdG9jb2wgbGlrZSBUTFMsIHdo aWNoIGlzIGRlZmluZWQgYW5kIGRpc2N1c3NlZCBpbiB0aGlzIHdheSBpbiB0aGUgSUVURi4gSW4g dGhlIElFQyAod2hpY2ggaXMgZW5nYWdlZCBJIGVuZXJneSBhdXRvbWF0aW9uIGNvbW11bmljYXRp b24gZGVmaW5pdGlvbikgdGhlcmUgaXMgdGhlIGRlc2lyZSB0byB1c2Ugc3RhbmRhcmRpemVkIHNl Y3VyaXR5DQogcHJvdG9jb2xzIGF2YWlsYWJsZSB0byBhdm9pZCB0aGUgZGVmaW5pdGlvbiBvZiBv d24gc29sdXRpb25zLCB3aGVuZXZlciBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJy Pg0KLS08YnI+DQpIYW5ubyBCw7Zjazxicj4NCjxhIGhyZWY9Imh0dHBzOi8vaGJvZWNrLmRlLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vaGJvZWNrLmRlLzwvYT48YnI+DQo8YnI+DQptYWlsL2ph YmJlcjogPGEgaHJlZj0ibWFpbHRvOmhhbm5vQGhib2Vjay5kZSI+aGFubm9AaGJvZWNrLmRlPC9h Pjxicj4NCkdQRzogRkU3Mzc1N0ZBNjBFNEUyMUI5Mzc1NzlGQTU4ODAwNzJCQkI1MUU0Mjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRM U0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzPC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E6C9F0E527F94F4692731382340B337847FAF5DENBGAT9EH2MSXww9_-- From nobody Thu Apr 6 01:27:14 2017 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 06A961292FD for ; Thu, 6 Apr 2017 01:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 SAnzp6Klo3_N for ; Thu, 6 Apr 2017 01:27:10 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A48A12940B for ; Thu, 6 Apr 2017 01:27:09 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id v368R2B5007092 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 Apr 2017 10:27:02 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net [139.22.70.141]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id v368R2Jd007656 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Apr 2017 10:27:02 +0200 Received: from DENBGAT9ERHMSX.ww902.siemens.net (139.22.70.143) by DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 6 Apr 2017 10:27:02 +0200 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.223]) by DENBGAT9ERHMSX.ww902.siemens.net ([139.22.70.143]) with mapi id 14.03.0339.000; Thu, 6 Apr 2017 10:27:01 +0200 From: "Fries, Steffen" To: "Salz, Rich" , =?utf-8?B?SGFubm8gQsO2Y2s=?= , "tls@ietf.org" Thread-Topic: [TLS] Support of integrity only cipher suites in TLS 1.3 Thread-Index: AdKsldO7ZRItAwyZRXCzcLu6YsWN5QAtyDcAADhSsSD//+J2gP/+5Ogg Date: Thu, 6 Apr 2017 08:27:00 +0000 Message-ID: References: <20170404180838.08ca99cc@pc1> <6ebe1d10b1e8447999f5db2311ec6197@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <6ebe1d10b1e8447999f5db2311ec6197@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Apr 2017 08:27:12 -0000 WWVzLCBzdGlja2luZyB0byBUTFMgMS4yIGlzIGFuIG9wdGlvbi4gT24gdGhlIG90aGVyIGhhbmQg dGhlIGVxdWlwbWVudCBpbiBzY2VuYXJpb3MgbGlrZSBlbmVyZ3kgYXV0b21hdGlvbiBpcyB1c2Vk IGZvciBhIHZlcnkgbG9uZyB0aW1lLiBUTFMgaXMgdXNlZCBoZXJlIHRvIHNlY3VyZSB0aGUgY29t bXVuaWNhdGlvbiBiZXR3ZWVuIHNwZWNpZmljIGRldmljZXMuIEJlc2lkZXMgdGhhdCwgaXQgaXMg YWxzbyB1c2VkIHRvIGFsbG93IGFjY2VzcyBmb3IsIGUuZy4sIHNlcnZpY2UgdGVjaG5pY2lhbnMg IHZpYSB3ZWIgYmFzZWQgbWFuYWdlbWVudCBvbiB0aGUgc2FtZSBkZXZpY2VzLiBPbmUgY29uY2Vy biBpcyB0aGF0IG9uY2UgaW4gYSB3aGlsZSB0aGUgc3VwcG9ydCBmb3IgVExTIDEuMiwgZS5nLiwg aW4gY29tbW9uIGJyb3dzZXJzIHdpbGwgcnVuIG91dCBhbmQgdGhlIGRldmljZXMgbmVlZCB0byBi ZSB1cGdyYWRlZCB0byBzdXBwb3J0IGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBUTFMgdG8gY29wZSB3 aXRoIGRpZmZlcmVudCBzZWN1cml0eSBwb2xpY2llcy4gQnV0IHdlbGwsIHRoaXMgaXMgbGlrZWx5 IHRvIGJlIHRoZSBmYXRlIGZvciBldmVyeSBsb25nIGxhc3RpbmcgZXF1aXBtZW50LiANCg0KVGhl IG90aGVyIHBvaW50IGlzIHRoYXQgZm9yIE5VTEwgY2lwaGVyIHN1aXRlcyB0aGF0IHdvcmsgd2l0 aCBlbGxpcHRpYyBjdXJ2ZXMgbm8gU0hBIDI1NiBzdWl0ZSBpcyBkZWZpbmVkLiBUaGVyZSBpcyBq dXN0IG9uZSB3aXRoIFJTQS4gSW4gc2V2ZXJhbCB1c2UgY2FzZXMgdGhlcmUgRUNEU0EgaXMgcHJl ZmVycmVkIG92ZXIgUlNBIGFsc28gZHVlIHRvIHRoZSByZXF1aXJlZCBpbmNyZWFzaW5nIGtleSBs ZW5ndGggYW5kIHRoZSBjb25uZWN0ZWQgY29tcHV0YXRpb25hbCBsb2FkIG9uIHRoZSBkZXZpY2Vz Lg0KDQpiZXN0IHJlZ2FyZHMNClN0ZWZmZW4NCg0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IFNhbHosIFJpY2ggW21haWx0bzpyc2FsekBha2FtYWkuY29tXSANClNlbnQ6IE1p dHR3b2NoLCA1LiBBcHJpbCAyMDE3IDE5OjE2DQpUbzogRnJpZXMsIFN0ZWZmZW4gKENUIFJEQSBJ VFMpOyBIYW5ubyBCw7ZjazsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW1RMU10gU3VwcG9y dCBvZiBpbnRlZ3JpdHkgb25seSBjaXBoZXIgc3VpdGVzIGluIFRMUyAxLjMNCg0KRG8geW91IGhh dmUgYSBjb21wZWxsaW5nIG5lZWQgZm9yIFRMUyAxLjMgYXMgb3Bwb3NlZCB0byBlYXJsaWVyIHZl cnNpb25zIHdoaWNoIGRvIGhhdmUgbnVsbCBlbmNyeXB0aW9uPw0K From nobody Thu Apr 6 01:34:45 2017 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 3BBE41287A3 for ; Thu, 6 Apr 2017 01:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 5-UKz7l1j_GS for ; Thu, 6 Apr 2017 01:34:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE631201FA for ; Thu, 6 Apr 2017 01:34:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1DFFFBE4D; Thu, 6 Apr 2017 09:34:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhQYIVCN-aCV; Thu, 6 Apr 2017 09:34:36 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 44FDDBE2C; Thu, 6 Apr 2017 09:34:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1491467676; bh=zLseWlybOXvq2Bs/ZD+C8g/qHJW8YgvDoLctz0dKfxY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SVS4O6UbcEEzUCkbKDFBK1o7Hmun0ekwuK3c/lASSKU93Mn6g304xZeoqhmLCTrAc qrJMKh5bkD7CdCcY/f3tjTYJungDy0H6We2cU0LLGBeuaMZjq674noSrMYAZl0lZHW dHCZFqguahqawM2b7YD8YLPZwKOLclaM4FAf0Ykc= To: Subodh Iyengar , Simon Friedberger , "tls@ietf.org" , Richard Salz , "Kaduk, Ben" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <0393df43-918c-934d-92f5-9bc06a708217@cs.tcd.ie> Date: Thu, 6 Apr 2017 09:34:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nnilUxJKww5miHVx5Lw33LxutmoJf9Cgc" Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Apr 2017 08:34:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nnilUxJKww5miHVx5Lw33LxutmoJf9Cgc Content-Type: multipart/mixed; boundary="Lxi3VtlSBdbDxOQe9fCt7j594OMkKCIFd"; protected-headers="v1" From: Stephen Farrell To: Subodh Iyengar , Simon Friedberger , "tls@ietf.org" , Richard Salz , "Kaduk, Ben" Message-ID: <0393df43-918c-934d-92f5-9bc06a708217@cs.tcd.ie> Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts References: In-Reply-To: --Lxi3VtlSBdbDxOQe9fCt7j594OMkKCIFd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/04/17 21:20, Subodh Iyengar wrote: >> With that goal in mind, wouldn't it help mitigate the threat if > the holder of the longer term credential (the cert subject) were to > include within the signature e.g. an IP address range within which > the delegated credential is allowed to be used? >=20 > We thought about this originally, but we discounted this because it > breaks when http and socks proxies are used. Looking at some data I > had a non trivial number of requests access our site using proxies. > I'm not sure whether there's a good method for a client to enforce ip > address ranges when a proxy does the dns resolution. So if you spec'd this so clients using proxies didn't attempt to enforce IP checks, but those going direct did, then you'd I guess better mitigate the stated threat, so long as the set of clients not using a proxy is non-negligible, which I assume is the case. Was that considered? Cheers, S. >=20 >=20 > Subodh >=20 > ________________________________ From: Stephen Farrell > Sent: Wednesday, April 5, 2017 12:30:31 > PM To: Subodh Iyengar; Simon Friedberger; tls@ietf.org; Richard Salz; > Kaduk, Ben Subject: Re: [TLS] security considerations for > draft-rescorla-tls-subcerts >=20 >=20 > I've no strong opinion for or against this. One question below=20 > though. >=20 > On 05/04/17 17:07, Subodh Iyengar wrote: >> The threat model here is that since if a less-trusted host having >> a key is compromised for a certain period of time without >> detection, and an attacker can steal private keys during that >> period. In many situations we are fine with giving the TLS >> terminator a certificate / key, i.e. they actually have a trust >> relationship, however we want a compromise to only give the >> attacker a limited power to use the credential. Revocation is >> arguably effective, so we would not be okay with giving a less >> trusted host a long term private key. However we'd be okay with >> giving a less-trusted host a short term key. >=20 > With that goal in mind, wouldn't it help mitigate the threat if the > holder of the longer term credential (the cert subject) were to > include within the signature e.g. an IP address range within which > the delegated credential is allowed to be used? >=20 > Cheers, S. >=20 >=20 --Lxi3VtlSBdbDxOQe9fCt7j594OMkKCIFd-- --nnilUxJKww5miHVx5Lw33LxutmoJf9Cgc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY5f2bAAoJEC88hzaAX42iqI8H/1cjmr1aOqVMsIbn+OKUI3SI 6cJyyGEENN/9GCmrlj/2jcvw3fJxNd7zurHdtB+WoqN5W5Qz8hn69eWoNzHj3SCo DHwA2RZ0eeE02X8vbwf0QWHFewOrpalZafH1xbAjqyZ//wFPzIy5pZ0mj3OO33sw X4NtWnnMDZEhxyg2NYFTWkmUNg+dFdnvh5+ZSxeX10nAH9q8TQJg1SDlScwMynY3 n/CEV3sjNAODNfuBSKVxRYSuekZvl5gQCE30OOGe9cVuWD9Y41I9f09nqZ5acO6X F7coG4xba1WioIPkEkH6C/izsaucTTNta94Z/3mga/c8xJ4cxNaVCuPyud2ebd8= =4heh -----END PGP SIGNATURE----- --nnilUxJKww5miHVx5Lw33LxutmoJf9Cgc-- From nobody Thu Apr 6 02:46:31 2017 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 774C71293FB for ; Thu, 6 Apr 2017 02:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 G0ILz5Xy_WEA for ; Thu, 6 Apr 2017 02:46:28 -0700 (PDT) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756FF127698 for ; Thu, 6 Apr 2017 02:46:27 -0700 (PDT) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id v369eL9G012286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Apr 2017 15:10:23 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id v369dPDn026572; Thu, 6 Apr 2017 15:09:26 +0530 Received: from webmail.cdac.in (wbms.pune.cdac.in [10.208.1.9]) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id v369dKSo021282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Apr 2017 15:09:21 +0530 Date: Thu, 6 Apr 2017 15:09:16 +0530 (IST) From: Sankalp Bagaria Reply-To: Sankalp Bagaria To: David Benjamin , Eric Rescorla Cc: Ryan Sleevi , R Balaji , "Bagaria, Sankalp" , "tls@ietf.org" , Benjamin Kaduk Message-ID: <396626715.1174.1491471556142.JavaMail.open-xchange@webmail.cdac.in> In-Reply-To: References: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1173_563313632.1491471556083" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v6.20.7-Rev15 X-CDAC-PUNE-MailScanner-ID: v369dPDn026572 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.899, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_00 -1.90, HTML_MESSAGE 0.00, RP_MATCHES_RCVD -0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-2.539, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_20 -0.74, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: v369eL9G012286 X-CDAC-PUNE-MailScanner-From: sankalp@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [TLS] Certificate compression draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Apr 2017 09:46:30 -0000 ------=_Part_1173_563313632.1491471556083 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, I see your point regarding privacy and complexity arising in cache-info. Should we use compression then instead of cache-info every time ? When should we use cache-info and when should we use compression ? Thanks and Regards, Sankalp Bagaria. On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria > wrote: > Hello, > > How is Certificate Compression advantageous over tls cached-info > extension? > Only case I can think of is - when the certificate is being sent for the > first time, > it can be compressed. Since the client doesn't have a copy of the > certificate, > cached-info can't be used. Are there more cases where compression is > useful? > Does cached-info not represent a privacy info-leak by disclosing past sessions prior to authenticating the new session? Versus compression, which limits it to thee session and thus reveals no new/additional information. That was certainly true for TLS1.2 Is compression not a simpler implementation - given the 'two' hard problems of computer science (caching, naming, off-by-one)? For example, you'd need to maintain a per-host cache of certificate information to meaningfully make use of it (... or else you end up with cross-origin state leakage, at least in the context of a browser, which is a Bad Thing). You would either need to read that information from stable storage prior to making the connection (so that you can negotiate the cached info), or you'd need to do a lazy-path where you index the cached entries and send those as available to the server, while in parallel beginning to load those entries. If those entries are corrupted, but used in the connection, the connection will fail. If those entries are removed during the connection establishment, the connection will fail. In short, cached-info represents a much greater degree of complexity and questionable privacy (both cross-origin and same origin - again, something relevant for browsers, but perhaps not relevant for others). Let's keep it simple :) ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- ------=_Part_1173_563313632.1491471556083 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Hello,
 
I see your point regarding privacy and complexity arising in cache-info. Should 
we use compression then instead of cache-info every time ? When should
we use cache-info and when should we use compression ?
 
Thanks and Regards,
Sankalp Bagaria.
 
On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria <sankalp@cdac.in> wrote:
Hello,
 
How is Certificate Compression advantageous over tls cached-info extension?
Only case I can think of is - when the certificate is being sent for the first time,
it can be compressed. Since the client doesn't have a copy of the certificate,
cached-info can't be used. Are there more cases where compression is useful?
 
Does cached-info not represent a privacy info-leak by disclosing past sessions prior to authenticating the new session? Versus compression, which limits it to thee session and thus reveals no new/additional information. That was certainly true for TLS1.2
 
Is compression not a simpler implementation - given the 'two' hard problems of computer science (caching, naming, off-by-one)? For example, you'd need to maintain a per-host cache of certificate information to meaningfully make use of it (... or else you end up with cross-origin state leakage, at least in the context of a browser, which is a Bad Thing). You would either need to read that information from stable storage prior to making the connection (so that you can negotiate the cached info), or you'd need to do a lazy-path where you index the cached entries and send those as available to the server, while in parallel beginning to load those entries. If those entries are corrupted, but used in the connection, the connection will fail. If those entries are removed during the connection establishment, the connection will fail.
 
In short, cached-info represents a much greater degree of complexity and questionable privacy (both cross-origin and same origin - again, something relevant for browsers, but perhaps not relevant for others). Let's keep it simple :)



-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
------------------------------------------------------------------------------------------------------------------------------- ------=_Part_1173_563313632.1491471556083-- From nobody Thu Apr 6 04:12:30 2017 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 9E22A129432 for ; Thu, 6 Apr 2017 04:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kpAtC1f5FOB2 for ; Thu, 6 Apr 2017 04:12:26 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 1926F1279E5 for ; Thu, 6 Apr 2017 04:12:26 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id i34so32895346qtc.0 for ; Thu, 06 Apr 2017 04:12:25 -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=IEv70OpiftbR137+pA+f9Bet4kwF9tn3bDweFyU6WRQ=; b=lYy4RCUIwBQea6ve7hTq0Ipxgt4ddbzU0ByG5Hfk/yrbOkyG2U5+G/+lOjfK1zJ2pd ZhdzvBl6saRALHRITD3p90N1qFlA8AKVbNvYFkaCSXPkW9EFlXvehJRshaGi1J9Kvh7T PE4HRXRndbzluuY5Np5rRYjiUloNNwHf1SEzw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IEv70OpiftbR137+pA+f9Bet4kwF9tn3bDweFyU6WRQ=; b=fHLaW1metI0ybiTuyuzBtBrnsvoPuMyz6xnS25ztW/3yUeR6pRfwMXvy6Fwglg5E7F IeD7D1eJ+ZCoJVyHDpLlAoYjoF7E/hLsmwYApGg/DSpifHUi++x35NU4lgd12XVZfTkm cX/UJxyGkZ3JGLLmAEqsNe5u2xwMgcDI3sR3ofv1grVTrV1xXb21JRwu4GVIz+/EkMtF 3LPPdPYk5eLPMLDUIdBVgqdtTx9hZ3qfrmB8Z3IbHAi/cuNu9pHde8q+y5ME3KOfJrKL GjRz7dmQLUAjrgkqkVZV/thXpOCS9s+rAwk0jLHG0ycA1rhboZU1xygDtIm8WH3OzOaW gF4A== X-Gm-Message-State: AFeK/H1HIq75y8ztopUKHliqJRic1Im0Wp53GcDcxCYgigGjT6CBvqbxCsSaX1nBoQD2QJ0PTLJt8BqiZpimPA== X-Received: by 10.237.62.211 with SMTP id o19mr38402941qtf.135.1491477144765; Thu, 06 Apr 2017 04:12:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Thu, 6 Apr 2017 04:12:24 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:d125:b34:b3a2:be79] Received: by 10.55.129.194 with HTTP; Thu, 6 Apr 2017 04:12:24 -0700 (PDT) In-Reply-To: References: <20170404180838.08ca99cc@pc1> From: Kyle Rose Date: Thu, 6 Apr 2017 07:12:24 -0400 Message-ID: To: "Fries, Steffen" Cc: "" , Eric Rescorla Content-Type: multipart/alternative; boundary=001a114386d467a72b054c7d95df Archived-At: Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Apr 2017 11:12:29 -0000 --001a114386d467a72b054c7d95df Content-Type: text/plain; charset=UTF-8 On Apr 6, 2017 4:08 AM, "Fries, Steffen" wrote: You are right, I did not take that option into account. But as you mentioned, it is non-standard and with the desire is to be interoperable as most as possible, proprietary enhancements are likely not to be favored. >From a security standards perspective, interoperability by-default is expressly *undesirable* for this mode of operation. We want this to break for anyone who hasn't gone through the trouble of explicitly opting-in. This seems to be a perfect case for the "allow registration of code points, but do not standardize or recommend" approach: the mechanism is possible to implement in a way that respects IANA namespacing by those parties with special needs requiring it, but the risk that someone will accidentally implement it in a stack used in end-user software is minimal. Kyle --001a114386d467a72b054c7d95df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Apr 6, 2017 4:08 AM, "Fries, Steffen" <steffen.fries@siemens.com> wrote:

You=C2=A0 are right, I di= d not take that option into account. But as you mentioned, it is non-standa= rd and with the desire is to be interoperable as most as possible, proprietary enhancements are likely not to be favored.

From a security standar= ds perspective, interoperability by-default is expressly *undesirable* for = this mode of operation. We want this to break for anyone who hasn't gon= e through the trouble of explicitly opting-in.

<= /div>
This seems to be a perfect case for the "allow = registration of code points, but do not standardize or recommend" appr= oach: the mechanism is possible to implement in a way that respects IANA na= mespacing by those parties with special needs requiring it, but the risk th= at someone will accidentally implement it in a stack used in end-user softw= are is minimal.

Kyle

--001a114386d467a72b054c7d95df-- From nobody Thu Apr 6 07:08:01 2017 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 9B5FB129415 for ; Thu, 6 Apr 2017 07:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 WXyqvQ2l9VoV for ; Thu, 6 Apr 2017 07:07:57 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD57127333 for ; Thu, 6 Apr 2017 07:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1491487677; x=1523023677; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3qfwf7jyzWCR/3zKkESTOgalI3iYLj/hKe7HUuVwa7w=; b=LIEY8SlwOc/l8YXY4UUyJYguvuNENbczNtwpQW+m/V0dUbaFkJwxm9/L C393LYw+4SGacSw5MilXL8RUgz9otLYQ5LoW1JD6wj4QLTJO+LDrFbYUL qhXMlkshJ8xJQhqLlnjLBYxDIcOgJrOCumjayk9j5GVfZww2p/D2TJd1X SR1suu9fn//CMewOVuBUtn9MC/OeUMsWUHI+1pmSG7Bnmt4Tw+NHuUCzs fd6O3AQ14++8eDC/UqfpvlaVwB02pFmGssmB5pTYuu3q6ycVdfEqOL7Zu xCUnl03w2dxpnmqnetMKRz3yJsCaCCpglS9eSIVgSpqZ60E6WYjBeriZY Q==; X-IronPort-AV: E=Sophos;i="5.37,160,1488798000"; d="scan'208";a="148271843" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from uxcn13-ogg-d.uoa.auckland.ac.nz ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Apr 2017 02:07:55 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Apr 2017 02:07:55 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Fri, 7 Apr 2017 02:07:55 +1200 From: Peter Gutmann To: "Fries, Steffen" , "Salz, Rich" , =?iso-8859-1?Q?Hanno_B=F6ck?= , "tls@ietf.org" Thread-Topic: [TLS] Support of integrity only cipher suites in TLS 1.3 Thread-Index: AdKsldO7ZRItAwyZRXCzcLu6YsWN5QAY08wAADSTLYAAAA5OgAAf1GcAACUJ6FU= Date: Thu, 6 Apr 2017 14:07:54 +0000 Message-ID: <1491487656110.54778@cs.auckland.ac.nz> References: <20170404180838.08ca99cc@pc1> <6ebe1d10b1e8447999f5db2311ec6197@usma1ex-dag1mb1.msg.corp.akamai.com>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Apr 2017 14:08:00 -0000 Fries, Steffen writes:=0A= =0A= >One concern is that once in a while the support for TLS 1.2, e.g., in comm= on=0A= >browsers will run out and the devices need to be upgraded to support=0A= >different versions of TLS to cope with different security policies. But we= ll,=0A= >this is likely to be the fate for every long lasting equipment.=0A= =0A= I don't think you'll need to worry about that for a long time, if ever. Th= e=0A= 20-year-old SSLv3 has only recently been killed off and that had some prett= y=0A= serious security issues. TLS 1.0 devices will be around for years, possibl= y=0A= decades, and TLS 1.2 even longer. Like HTTP 1.1 (vs. HTTP/2), TLS 1.2 coul= d=0A= well stick around forever.=0A= =0A= Peter.=0A= From nobody Thu Apr 6 09:33:50 2017 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 B7B18129568 for ; Thu, 6 Apr 2017 09:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zh0UXVOZrihn for ; Thu, 6 Apr 2017 09:33:46 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 B2D01128854 for ; Thu, 6 Apr 2017 09:33:44 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id 81so41237570pgh.2 for ; Thu, 06 Apr 2017 09:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L7T52+YXrfHwsExhy4eweAvYD1kqnK5Zk1MPs6ApZlU=; b=hxHVyrFREGuuZVj2hhyqEVkzHWwxe6LNmOlluir7lO81Dtl3J/6d/pYzu4rujq5oeM +ZFEBDvmoiJtyojii+RFHlndrWoCIMM57MXSfluKb1Sr6zBedve2/Co9S0CyFnZceCH/ U+aCzQMfWC+PC6fL4x4/MkTInNtPTCIfkhs5DtVH2aBfvBSh1MCbI2881NXBl10kkMmT WWjeJdiljhn6A5F5oHIcPwf9wiYiAxHCwIwq2wPWd2Xw61aQ2DFWiBnf8sm08frXI7w+ R3u3MRoZQF4FfgDnQIizwibdYxV+bwtbda4jxaMLsp+xrCTA2ZC1TzyXsdIe7Bsj+IGv w5GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L7T52+YXrfHwsExhy4eweAvYD1kqnK5Zk1MPs6ApZlU=; b=I+CbBhsgshqvgg7YkXfiyv/mLEs6PujLagxDUmOEYp6O3NwPtucfS8uDd1xyur5ecw nQ2mnXvNzjex1VSvvzs01tS/DnvpMUSBjJA38j9ClQwqFxmLvkf0Y0cL39AF+f+ptS04 1T2lhlKqOTo9gVng49EX0AHkUPIvX/5Xke2pNikhBzNzmYC1olfVaAGMy/sYYahilL9x wphB7QnHlx4WYohtXqfc7muot0s1qR3ImYFTCK0VNAleg93TUvDXmQRGie50UcvZ64Or kf+/YuL1NbtkjpgVC5OxSnJbvku1MwUMNWFViIdMLGlJENpGHR30fuEwYW7touDcARFK 2YWg== X-Gm-Message-State: AFeK/H1cGJr3yrsXbOU8Sh4iNg/8mjaa3Q0KrY11NTRyB1qWPpMMH/C8MGxW3ex7XKB6LfMieJM7tKWVRYCQow== X-Received: by 10.99.232.21 with SMTP id s21mr37788853pgh.67.1491496424179; Thu, 06 Apr 2017 09:33:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.160.194 with HTTP; Thu, 6 Apr 2017 09:33:43 -0700 (PDT) In-Reply-To: <0393df43-918c-934d-92f5-9bc06a708217@cs.tcd.ie> References: <0393df43-918c-934d-92f5-9bc06a708217@cs.tcd.ie> From: Watson Ladd Date: Thu, 6 Apr 2017 09:33:43 -0700 Message-ID: To: Stephen Farrell Cc: Subodh Iyengar , Simon Friedberger , "tls@ietf.org" , Richard Salz , "Kaduk, Ben" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 06 Apr 2017 16:33:49 -0000 On Thu, Apr 6, 2017 at 1:34 AM, Stephen Farrell wrote: > > > On 05/04/17 21:20, Subodh Iyengar wrote: >>> With that goal in mind, wouldn't it help mitigate the threat if >> the holder of the longer term credential (the cert subject) were to >> include within the signature e.g. an IP address range within which >> the delegated credential is allowed to be used? >> >> We thought about this originally, but we discounted this because it >> breaks when http and socks proxies are used. Looking at some data I >> had a non trivial number of requests access our site using proxies. >> I'm not sure whether there's a good method for a client to enforce ip >> address ranges when a proxy does the dns resolution. > > So if you spec'd this so clients using proxies didn't attempt > to enforce IP checks, but those going direct did, then you'd I > guess better mitigate the stated threat, so long as the set of > clients not using a proxy is non-negligible, which I assume is > the case. Was that considered? Too much room for error. Consider all the varieties of network devices that could cause an IP-address mismatch, many of which the client wouldn't see. > > Cheers, > S. > > >> >> >> Subodh >> >> ________________________________ From: Stephen Farrell >> Sent: Wednesday, April 5, 2017 12:30:31 >> PM To: Subodh Iyengar; Simon Friedberger; tls@ietf.org; Richard Salz; >> Kaduk, Ben Subject: Re: [TLS] security considerations for >> draft-rescorla-tls-subcerts >> >> >> I've no strong opinion for or against this. One question below >> though. >> >> On 05/04/17 17:07, Subodh Iyengar wrote: >>> The threat model here is that since if a less-trusted host having >>> a key is compromised for a certain period of time without >>> detection, and an attacker can steal private keys during that >>> period. In many situations we are fine with giving the TLS >>> terminator a certificate / key, i.e. they actually have a trust >>> relationship, however we want a compromise to only give the >>> attacker a limited power to use the credential. Revocation is >>> arguably effective, so we would not be okay with giving a less >>> trusted host a long term private key. However we'd be okay with >>> giving a less-trusted host a short term key. >> >> With that goal in mind, wouldn't it help mitigate the threat if the >> holder of the longer term credential (the cert subject) were to >> include within the signature e.g. an IP address range within which >> the delegated credential is allowed to be used? >> >> Cheers, S. >> >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Apr 7 10:05:56 2017 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 45D5F129514 for ; Fri, 7 Apr 2017 10:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 UASob0y2mKqT for ; Fri, 7 Apr 2017 10:05:51 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 125761296D4 for ; Fri, 7 Apr 2017 10:05:44 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8E258200043 for ; Fri, 7 Apr 2017 17:05:43 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 76872200042 for ; Fri, 7 Apr 2017 17:05:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491584743; bh=O8IDdpgZfZJnYsrq6mAS5qMoge3KZ9nRsyrlsQfBRlU=; l=5352; h=To:From:Date:From; b=QYpVdwgSw7P+JSL7cRJ0ppyukHZ4lK4al6rDz0Qa3pw9MuT7X54J+OM9cFKGQvw5+ HFv4oEBJmDN3avMOnAetMmEGd1yVl4m7xnPpMu0+agj0HCg+OUS+pmhYKcIXuTyeay 9JH1Dn30xtv+fN/W4BjJhLQCi5tqAQ+xka8WtXd8= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 3F9F898084 for ; Fri, 7 Apr 2017 17:05:43 +0000 (GMT) To: "" From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 7 Apr 2017 12:05:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9760DA881F022835E0C2688F" Archived-At: Subject: [TLS] the perils of padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 07 Apr 2017 17:05:54 -0000 This is a multi-part message in MIME format. --------------9760DA881F022835E0C2688F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit With TLS 1.3 we have this new padding scheme for encrypted records, and even allow for padding-only records (of nominal internal content type "application data"). This is generally a good thing, in that it gives a lot of degrees of freedom to introduce countermeasures to traffic analysis, but perhaps we are overgenerous. There doesn't seem to be anything preventing a peer from sending only padding records and never any application data, whether that is in the client's early data or in regular data after the handshake. Now, in some situations you may want to do just that, if you want to keep a channel open and it will only ever send one legitimate signal ("fire the missiles!") but you want to avoid revealing when that happens via traffic analysis. In other cases, it just uses resources without giving an event to the application so as to let the application say "enough of this". I first noticed this in the context of early data, where a malicious client can chew up a server's resources indefinitely at the TLS layer during the handshake, by negotiating early data and then trickling (or spewing) 0-length application data records with padding and never finishing the handshake. We have the max_early_data_size limit that intends to limit how much early data can be sent; the original motivation for this was to limit how much trial decryption a server must do if it doesn't have the key material needed for it, but it also looks like it should serve as a bound on finishing the handshake. In some sense this is not new, as a malicious peer could always string things out by sending highly fragmented records slowly, but the padding allows a way to string things out while making absolutely no progress at all, which seems to be qualitatively different, and worth spending some time considering whether countermeasures are appropriate. One simple and easy option is to have a new extension to indicate the maximum consecutive padding that will be accepted by an endpoint, and abort the connection if too much padding is received in a row without any non-padding content. But that might be too complicated, and we could just note that implementations may get grumpy if they see too much padding and abort the connection; peers are basically allowed to abort the connection at will already, so it's not really a new thing. -Ben --------------9760DA881F022835E0C2688F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit With TLS 1.3 we have this new padding scheme for encrypted records, and even allow for padding-only records (of nominal internal content type "application data").  This is generally a good thing, in that it gives a lot of degrees of freedom to introduce countermeasures to traffic analysis, but perhaps we are overgenerous.  There doesn't seem to be anything preventing a peer from sending only padding records and never any application data, whether that is in the client's early data or in regular data after the handshake.  Now, in some situations you may want to do just that, if you want to keep a channel open and it will only ever send one legitimate signal ("fire the missiles!") but you want to avoid revealing when that happens via traffic analysis.  In other cases, it just uses resources without giving an event to the application so as to let the application say "enough of this".

I first noticed this in the context of early data, where a malicious client can chew up a server's resources indefinitely at the TLS layer during the handshake, by negotiating early data and then trickling (or spewing) 0-length application data records with padding and never finishing the handshake.  We have the max_early_data_size limit that intends to limit how much early data can be sent; the original motivation for this was to limit how much trial decryption a server must do if it doesn't have the key material needed for it, but it also looks like it should serve as a bound on finishing the handshake.

In some sense this is not new, as a malicious peer could always string things out by sending highly fragmented records slowly, but the padding allows a way to string things out while making absolutely no progress at all, which seems to be qualitatively different, and worth spending some time considering whether countermeasures are appropriate.

One simple and easy option is to have a new extension to indicate the maximum consecutive padding that will be accepted by an endpoint, and abort the connection if too much padding is received in a row without any non-padding content.  But that might be too complicated, and we could just note that implementations may get grumpy if they see too much padding and abort the connection; peers are basically allowed to abort the connection at will already, so it's not really a new thing.

-Ben
 --------------9760DA881F022835E0C2688F-- From nobody Fri Apr 7 10:25:41 2017 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 5DB0F129549 for ; Fri, 7 Apr 2017 10:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 ybJ0-uUeY4oK for ; Fri, 7 Apr 2017 10:25:37 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4D71293EC for ; Fri, 7 Apr 2017 10:25:37 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 3EDD6C009F50; Fri, 7 Apr 2017 10:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=PAh7LkNqpA6Qxm IfR0bGNPFLKRw=; b=mXgrWoA1KulfiO8r4wmpcyMn1cO5FGk5w0se3c/cN0AKoz noXgAZwf4GF77okE09IMze7LtG/7C39tslW0QGCvpO1Z9FHBibjwigM4bK+KFe9A rMk+WQg47Nrh8q0QHlANtbdGSJLsH9ndFhZWWjH2FCvny6beRFauCk3YmmFZE= Received: from localhost (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id A988EC0026BA; Fri, 7 Apr 2017 10:25:36 -0700 (PDT) Date: Fri, 7 Apr 2017 12:25:35 -0500 From: Nico Williams To: Benjamin Kaduk Cc: "" Message-ID: <20170407172534.GA5654@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] the perils of padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 07 Apr 2017 17:25:40 -0000 On Fri, Apr 07, 2017 at 12:05:42PM -0500, Benjamin Kaduk wrote: > One simple and easy option is to have a new extension to indicate the > maximum consecutive padding that will be accepted by an endpoint, and > abort the connection if too much padding is received in a row without > any non-padding content. But that might be too complicated, and we > could just note that implementations may get grumpy if they see too much > padding and abort the connection; peers are basically allowed to abort > the connection at will already, so it's not really a new thing. Or, you know, just close the connection. Give them a fatal record to tell them why. No need to tell them up fron how much naughtiness you'll allow. From nobody Fri Apr 7 10:28:25 2017 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 9A5A0129576 for ; Fri, 7 Apr 2017 10:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 JgOZlUXsD0u9 for ; Fri, 7 Apr 2017 10:28:22 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id E74C912956A for ; Fri, 7 Apr 2017 10:28:21 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5207416C912; Fri, 7 Apr 2017 17:28:21 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 3C26016C90D; Fri, 7 Apr 2017 17:28:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491586101; bh=TaAxl81V+r4uzsDDfpsBqxa/wD9Cv2LM2qzAC2GkY4g=; l=2525; h=To:References:Cc:From:Date:In-Reply-To:From; b=p8RdRZqkrW6/GuSw5dXuS+a6wr9XUV1QNmRVLdK7eT9axdDzeaacLqvvmcZauc+n9 WQ3OO/7ZLoBWr2F4wmxnA4eXXD3dFOGMVfIcul4YB2h3TcyTGTOgeQto7vHqB0FBLl 2MLPhXdRUO5F3YTieYAws1ocUx8RZKLY+kIqry4g= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id DE5501E08F; Fri, 7 Apr 2017 17:28:20 +0000 (GMT) To: Nico Williams References: <20170407172534.GA5654@localhost> Cc: "" From: Benjamin Kaduk Message-ID: Date: Fri, 7 Apr 2017 12:28:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170407172534.GA5654@localhost> Content-Type: multipart/alternative; boundary="------------5EDF08FBCE241757D177BD2B" Archived-At: Subject: Re: [TLS] the perils of padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 07 Apr 2017 17:28:24 -0000 This is a multi-part message in MIME format. --------------5EDF08FBCE241757D177BD2B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/07/2017 12:25 PM, Nico Williams wrote: > On Fri, Apr 07, 2017 at 12:05:42PM -0500, Benjamin Kaduk wrote: >> One simple and easy option is to have a new extension to indicate the >> maximum consecutive padding that will be accepted by an endpoint, and >> abort the connection if too much padding is received in a row without >> any non-padding content. But that might be too complicated, and we >> could just note that implementations may get grumpy if they see too much >> padding and abort the connection; peers are basically allowed to abort >> the connection at will already, so it's not really a new thing. > Or, you know, just close the connection. Give them a fatal record to > tell them why. No need to tell them up fron how much naughtiness you'll > allow. Right. But it might be worth adding to the list of things to check about your implementation in Appendix . -Ben --------------5EDF08FBCE241757D177BD2B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/07/2017 12:25 PM, Nico Williams wrote:
On Fri, Apr 07, 2017 at 12:05:42PM -0500, Benjamin Kaduk wrote:

One simple and easy option is to have a new extension to indicate the
maximum consecutive padding that will be accepted by an endpoint, and
abort the connection if too much padding is received in a row without
any non-padding content.  But that might be too complicated, and we
could just note that implementations may get grumpy if they see too much
padding and abort the connection; peers are basically allowed to abort
the connection at will already, so it's not really a new thing.

Or, you know, just close the connection.  Give them a fatal record to
tell them why.  No need to tell them up fron how much naughtiness you'll
allow.

Right.  But it might be worth adding to the list of things to check about your implementation in Appendix <mumble>.

-Ben
--------------5EDF08FBCE241757D177BD2B-- From nobody Fri Apr 7 14:14:52 2017 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 3ED8B12786A for ; Fri, 7 Apr 2017 14:14:47 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 t4CKkykHT0pN for ; Fri, 7 Apr 2017 14:14:36 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 CE62A127867 for ; Fri, 7 Apr 2017 14:14:35 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id r16so3153403ioi.2 for ; Fri, 07 Apr 2017 14:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=BQQdK2QlDvGm0CptI8WfvBF5AjsG6DUBqzzkMn/LzLo=; b=VOW08gxVnA3fOXdk1wRfGsj2n05jbub9Z1iABJSk0hkCXwvygUzWBfjmmb2vi/rNnL 8g/Kd2bliB2r+rrvht+QybO32EvJgmIf1RKUfgNs8Gz0bdrE6HX7ki1NrUAvegFaoGb1 er8eeHHFksh/zlnIl/PlnpkVfUBL/OUbqHvK8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=BQQdK2QlDvGm0CptI8WfvBF5AjsG6DUBqzzkMn/LzLo=; b=n2j41Bmh6mLKNkfQFeqoaHBfrS/B2QYdQeuOfwru0Z3YBvW7ux8tRsYIHy0hAq3s6m R80e0N60x3MNzgUgFeP6xyaeHKcZrj/MxoH0YdfaobL3OrQz/k5JbMo53sR6MJJk0Hwt xqCmuaxrzNBzQSZuArYe0FPBWBhfykTzZaJctTJ3h/pkfEa56CUKF2a+gF4U4BMSWrGT 2TZ2uRCccUBL82AdGdDX8lr2k4ijDECQ0EFUVv2LQD+hvIYNQte1n/36SFsQrl/W1C4N 3kYNA22QGH7kAbTtvbUYqFegsdPTk2REik8x85YIIrne0aGqn9zzoMuH4N8uM8LQeLxX Vgcg== X-Gm-Message-State: AN3rC/6loQ50ZVg0vctKDUb9BQpC3l+6f4XJ9PIWAC8MEJZFTG7nelpWC6Bas1u5x8TcZw== X-Received: by 10.107.18.5 with SMTP id a5mr6881280ioj.189.1491599674933; Fri, 07 Apr 2017 14:14:34 -0700 (PDT) Received: from [5.5.33.122] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id y124sm100887itd.19.2017.04.07.14.14.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 14:14:34 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 17:14:33 -0400 References: <4CBA4B06-411F-4B87-B664-D451260F8C25@sn3rd.com> To: "" In-Reply-To: <4CBA4B06-411F-4B87-B664-D451260F8C25@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-dtls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 07 Apr 2017 21:14:47 -0000 It=E2=80=99s now the 7th so the call for adoption is complete. Though = Ben was the only commenter on list (and thanks Ben) there was definitely = support for adopting this draft at the Chicago session. This bit of = administrivia is complete so authors feel free to submit a WG version at = your leisure. I=E2=80=99ve pre-approved "draft-ietf-tls-dtls13" as the = draft's name and created a github repo: = https://github.com/tlswg/dtls13-spec. spt > On Mar 22, 2017, at 18:50, Sean Turner wrote: >=20 > All, >=20 > -00 of draft-rescorla-tls-dtls13 [0][1] was discussed at IETF 97 [2]. = It=E2=80=99s now at version -01 and GH issues are slowly rolling in. = It=E2=80=99s also on our agenda again at IETF 98, and DTLS a chartered = work item, so it seems like it=E2=80=99s time to get the WG adoption = process started for this individual draft. Please let the list know = whether you support adoption of the draft and are willing to = review/comment on the draft before 20170406. If you object to its = adoption, please let us know why. >=20 > Cheers, >=20 > J&S >=20 > [0] https://github.com/ekr/dtls13-spec=20 > [1] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-dtls13 > [2] = https://www.ietf.org/proceedings/97/slides/slides-97-tls-dtls-13-01.pdf From nobody Fri Apr 7 14:15:11 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E75F120454; Fri, 7 Apr 2017 14:15:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149159970457.11240.4478372867887814984.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 14:15:04 -0700 Archived-At: Subject: [TLS] The TLS WG has placed draft-rescorla-tls-dtls13 in state "Candidate for WG Adoption" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 07 Apr 2017 21:15:06 -0000 The TLS WG has placed draft-rescorla-tls-dtls13 in state Candidate for WG Adoption (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-rescorla-tls-dtls13/ From nobody Fri Apr 7 14:36:35 2017 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 0EF891250B8 for ; Fri, 7 Apr 2017 14:36:34 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 qEHvaec7UjUL for ; Fri, 7 Apr 2017 14:36:30 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 CB30612786A for ; Fri, 7 Apr 2017 14:36:24 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id y18so1325925itc.0 for ; Fri, 07 Apr 2017 14:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=BOctGuZiX2rqXdcFyZPlQI/VbRE7Kx8uPZiuwYKOD4Q=; b=X7PecqNODvWS95ARXEfMXnN48nnsU2UJgybDcb81w6/an5Acu5xpnLqLhjLJ+Ab6hA 7Kmfar1TgF3WptbekXxP07LeFXAMgVLQwz1MDSWoXZ8pOlmrVFgCYJydaiXoqxu6nSIG kXSfO/2wC4WjnNxR3ZKWrP8GlQljjRQd+or4U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=BOctGuZiX2rqXdcFyZPlQI/VbRE7Kx8uPZiuwYKOD4Q=; b=X6KH31wMpBl30iTQlow5i/HGGmUQsolXAT6nYeSZC9l9kBTkB5h3cKb2k0tMaf1nF2 sKEUsr9lVzXkLlidR8gBhAoob31VuvNZs760pvLryDocop+49IOJknbr87oPqIXBPvif OqbK+nrKSA0LrFAdZQWRBrC9C48qg+HHxzShB3qwtkirt0FAy6rAaDNU8gw2wQmgXUN3 A6/k2Q2jAtKsuQjpQ64aPy6zhNN8gyrqK0PU+cZZbH2aFMi/FEsknaEuV0W2Hiq2NZQ0 RXH7ms02K+BZIFfBiEk5Ibqf8zdb0aZ2yY+Z+uFUCU5R3pJlQ6rz3kkhNKvhkZrhdG46 1Jrg== X-Gm-Message-State: AN3rC/7JY4Zqx7QN2YeDgxzUuoet9kO9Q4uxSFtHJjLnaH5+fs/gOYAG dw8gGGedxJtHyzsygmQ= X-Received: by 10.36.181.71 with SMTP id j7mr1705976iti.56.1491600983968; Fri, 07 Apr 2017 14:36:23 -0700 (PDT) Received: from [5.5.33.122] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id p77sm2974302iod.4.2017.04.07.14.36.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 14:36:23 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 17:36:18 -0400 References: <149159976690.11135.5173586786899399531.idtracker@ietfa.amsl.com> To: "" In-Reply-To: <149159976690.11135.5173586786899399531.idtracker@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] IETF WG state changed for draft-rescorla-tls-dtls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 07 Apr 2017 21:36:34 -0000 Interesting that the datatracker doesn=E2=80=99t cc the list when the = draft is officially adopted. Oh well, here=E2=80=99s the state we=E2=80=99= re actually in. > On Apr 7, 2017, at 17:16, IETF Secretariat = wrote: >=20 >=20 > The IETF WG state of draft-rescorla-tls-dtls13 has been changed to > "Adopted by a WG" from "Call For Adoption By WG Issued" by Sean = Turner: >=20 > https://datatracker.ietf.org/doc/draft-rescorla-tls-dtls13/ >=20 Note that the datatracker shows draft-rescorla-tls-dtls13 as a WG item = now (https://datatracker.ietf.org/wg/tls/documents/). When the authors = submit a WG draft the datatracker will automagically drop = draft-rescorla-tls-dtls13 and add draft-ietf-tls-dtls13 to the list of = WG drafts. spt= From nobody Mon Apr 10 04:49:35 2017 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 270A7127977 for ; Mon, 10 Apr 2017 04:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 EG5Ia_LndcfC for ; Mon, 10 Apr 2017 04:49:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D981294A1 for ; Mon, 10 Apr 2017 04:49:31 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DA7DB76E9; Mon, 10 Apr 2017 11:49:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DA7DB76E9 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DA7DB76E9 Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A4873B23F8; Mon, 10 Apr 2017 11:49:30 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 10 Apr 2017 13:49:28 +0200 Message-ID: <7026308.JzWuIzB1lm@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2346149.8UOJfP0d8I"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 10 Apr 2017 11:49:31 +0000 (UTC) Archived-At: Subject: Re: [TLS] the perils of padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 10 Apr 2017 11:49:34 -0000 --nextPart2346149.8UOJfP0d8I Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 7 April 2017 19:05:42 CEST Benjamin Kaduk wrote: > With TLS 1.3 we have this new padding scheme for encrypted records, and > even allow for padding-only records (of nominal internal content type > "application data"). This is generally a good thing, in that it gives a > lot of degrees of freedom to introduce countermeasures to traffic > analysis, but perhaps we are overgenerous. There doesn't seem to be > anything preventing a peer from sending only padding records and never > any application data, whether that is in the client's early data or in > regular data after the handshake.=20 While this indeed may be a possible attack, it's a symmetric attack - the=20 attacker will have to encrypt as much data as the server will decrypt. If h= e=20 or she doesn't do that, the server will reject the records as having incorr= ect=20 mac. That's a big difference between it, and ealy data, where to server there's = no=20 difference between correct ciphertext encrypted with unknown key and string= of=20 random data. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2346149.8UOJfP0d8I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY63FIAAoJEJKo0bgB0vX1I00P/0kg91P219Q/HO8aSPF5ZfYG sgzHCtmLlj/5uxPjpb2T5engQ3rWI2lRR58X5Qwll99maEFeOMnIBit57yKJHo3j FkdUeRS9cU9GCB0dZSNcSom3VlygKzaSu8audyOqj9v24wdiO/dUJZ+2Baz10n1y 9yIJRwumAXVcWOL1j7Axg8flD4w8jkME6WSZiyg44wH7BqE7MCHEdIT4WNWKIvQN dug4HmKBL4vYvI+Kv1WnJLW9/cV0cOlSHq0iaS35b3CW6ITWdP4DEPVuOYVixVdD DJTjxzUTHrKIRJJ66t3y+hFLwBh+E7gsVMadSN5m6tzuGbMR4+C5lDWM/HzQLRxU WXa5fifKzriYN3T9u92980uzb7LKWxyimAyo7SuVRwuJMjuN44HfBCMdC1yTQnuZ 3yVGX9Wz254j69YptMvuPjkKrPESt6/5D2xO7b1K9juDP0C3+5C5s7QKAARAKPrf LOy1yjjEyLXDKac9/RFnjNyhwF85Mk+jSrG8iIxm2se60OqYhUCxA6yXBj/z+nt7 NZIiSief34nv1Ndz6k0gdfX8bjgLxOSMRs5GmQ8Zgsqrl2mgWjzmy+pDSdjHIQTO m1HPwH30JLi+RVFpHH2Y6BL1vB0+kSOQ1H+JmIyH0+ujXOsFq5VezaFL2khJJMPA tLUnc3XnrVsEZMaxJIUU =OyHu -----END PGP SIGNATURE----- --nextPart2346149.8UOJfP0d8I-- From nobody Mon Apr 10 17:19:36 2017 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 98474128CDB for ; Mon, 10 Apr 2017 17:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham 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 xayqWK4ixNOE for ; Mon, 10 Apr 2017 17:19:33 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 E594C1293D6 for ; Mon, 10 Apr 2017 17:19:32 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id r128so1583067ywg.2 for ; Mon, 10 Apr 2017 17:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YY02/0YhvzmoKcLKdml4dsZ6ewRhX2hGfRFhXU684fg=; b=Htn+S+frWAg5YSnoJ7OvmiMSgBIsCch/XxLUFkE8i0mJTy2f+HhW/NLq9lTLdYatQD AN+2zBG0walxEf85ihsTqvjpgYdUKITfL0rD3272BGQGZzMFA7c/imJjiBqUTKtmB0fM 2R+2LPbGVKstBGqwpdNsEUDoi83htjrLAjD/k9E+RSz0x8qiJ1xKo4A+6h8WSiOSdP3C TScVT0cBbeOMwSSqiDtCtR6MHthgOjEdSft45YNk7w2S2jlIs4x1JdEp+TGFLw5vv2cT vqb7wNSjQ20ODvOfnLgi6QbkQySrlGfKtzVlbiyynzwQvsgni0bNYCY/IEdhrzN6kpmE YiRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YY02/0YhvzmoKcLKdml4dsZ6ewRhX2hGfRFhXU684fg=; b=qJSxpOCqHtJ8PoOvdkLwbs6qKlauzQzF/oe1ppKcMbRRWy5ZcvQfdk3fjTKrwt6Qth PrJFQ6qmy7nUic4jUvsEIvsEO0RedAXbqJ6OLYzg3sQ8vk7/BJwhLe54IpjB4wpKW+Lj Yr2D/tekJvUc0gwE9i4Eaipwa9TAUycF0UvxyzviCtANZnA6ZihCNGo13OeVQa0Auc3H nvvuGSRy5J/qAzakjaUIxvBjZZz4eHmmzub/PR+nmtOJ7n2n0GvoNQ/kPCWLmai+lqeO cm9X1UqY6YhWIVmq9DcxbPrVkpPI8cODbv9e4sLOiMjJEPE3eylm07WHD6K1X7XGaaHX oX9w== X-Gm-Message-State: AN3rC/4YzRV6slavvoePK7m7IPbnYZIyKMI89heFfbXpfnrW/9jI1JTpeFBcZrL8uXTGANTbodygDqEwhL8w+Q== X-Received: by 10.13.203.73 with SMTP id n70mr5268106ywd.71.1491869972081; Mon, 10 Apr 2017 17:19:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 10 Apr 2017 17:18:51 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 10 Apr 2017 17:18:51 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114fd3d6bcc731054cd90b02 Archived-At: Subject: Re: [TLS] PRs for review X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 00:19:35 -0000 --001a114fd3d6bcc731054cd90b02 Content-Type: text/plain; charset=UTF-8 Merged On Tue, Apr 4, 2017 at 10:09 AM, Eric Rescorla wrote: > Hi folks, > > As discussed in the meeting, and with an assist from MT, I've prepared > two small PRs: > > * An extension by the client to negotiated post-handshake client auth: > https://github.com/tlswg/tls13-spec/pull/933 > > * Explicitly describing how RFC 7250 Raw Public Keys work with TLS > 1.3 and removing extensions which no longer work from the table. > https://github.com/tlswg/tls13-spec/pull/932 > > Target merge date: Thursday. > > -Ekr > > --001a114fd3d6bcc731054cd90b02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Merged


=
On Tue, Apr 4, 2017 at 10:09 AM, Eric Rescorla <= span dir=3D"ltr"><ekr@= rtfm.com> wrote:
Hi folks,

As discussed in the meeting, and with= an assist from MT, I've prepared
two small PRs:
* An extension by the client to negotiated post-handshake clie= nt auth:

* Explicitly describing how RFC 7250 Raw Public = Keys work with TLS
1.3 and removing extensions which no longer wo= rk from the table.

Target merge date: Thursday.

-Ekr


--001a114fd3d6bcc731054cd90b02-- From nobody Tue Apr 11 06:09:16 2017 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 40D54129B9B for ; Tue, 11 Apr 2017 06:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 lhnwmk9BwVsk for ; Tue, 11 Apr 2017 06:09:07 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 B8109128B4E for ; Tue, 11 Apr 2017 06:09:07 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id v3so80397318qtd.3 for ; Tue, 11 Apr 2017 06:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=TKR+UmeaCn+vGyVw8Z8HLAFqtpnXEUTYbM/+keY7How=; b=KLgel5CsAPCAn9tVKWAAaO5lnCRs1qVP6Vs7ZNAW+hkarsTnQx0RNu9VC8e8FOd/iK GR3Xo+9mxyvtmHHT8x97k+wd+KxEumyWSMYZoAXNx+qepb/7lRvC61NUluqCBqUqu0Nv qRUDpY4vVZr0O4unirWTd82bHoVfs0O4rm3+g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=TKR+UmeaCn+vGyVw8Z8HLAFqtpnXEUTYbM/+keY7How=; b=m0sWho4UoHXXHmvIzBhqU6G5l64xTTxBtp3+/04ltJjDkGYnq9DSmPO54YPhbgVcnZ P2v6neNTwT2PvMWGzZSndmj+m6BUt11tT+dgS0BFz11umzqrDS5Ao56QcGYJ1ZjznC2C lLmNSnX+7jsndtXcgI7kdSOjmNRjzcQrt5EFZI0dFPJA34UNpqDa48b4A/B/Io8TKK1x HbGWuv7fLz4wjyawnTW2Cn37vIE9x6AUMpfkL05FJzDaO8UXOtFa34fkbOaqjv0Hs1Ok U8Wdr1hWqx0phONbR7OV8/z89vHCyIPm3e3Ds4+izHXEAkHvvPYLKEiv3GGxvPsbrVno OAJg== X-Gm-Message-State: AFeK/H3SPO0VlPyYOps3j5xU/ZH/pdv0rwOzwu6s/HGVSEyiHLH8KSi4KpdXRAgJQVx+dg== X-Received: by 10.200.33.182 with SMTP id 51mr61579312qty.65.1491916146537; Tue, 11 Apr 2017 06:09:06 -0700 (PDT) Received: from [172.16.0.18] ([96.231.229.219]) by smtp.gmail.com with ESMTPSA id c26sm6312980qte.19.2017.04.11.06.09.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 06:09:05 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 11 Apr 2017 09:09:04 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] WG review of draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 13:09:14 -0000 All, draft-ietf-tls-rfc4492bis has been revised since it left the WG and we = agree with Yoav=E2=80=99s statement at the mic in Chicago that the WG = should review the changes before we ask Kathleen (our newly appointed = AD) to continue progressing the draft. Please review the differences = from the -12 version that went through WGLC and the latest version [0] = and let us know by 20170426 whether there is anything that would stop = progression of the draft. Thanks, J&S [0] = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-rfc4492bis-12&url2=3Ddr= aft-ietf-tls-rfc4492bis-16= From nobody Tue Apr 11 08:22:05 2017 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 A3B1F129C4D for ; Tue, 11 Apr 2017 08:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.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 vB-LSTNM8Ysn for ; Tue, 11 Apr 2017 08:22:02 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 2DBC912EAAB for ; Tue, 11 Apr 2017 08:22:02 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id 81so170701pgh.2 for ; Tue, 11 Apr 2017 08:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6zGLa2a1dMKbRjGqlY7/tEFjEO8oBKmnJ4xWmH0DN9A=; b=vdEojxMZTfzAKrg8MsKR71ZTWcYS63TDrSMGjce+swNVhl0F1Rr5B7BfSuoHULk3i2 0iEuHBl6SF/ggq2kuz/ac2xU2iy3cRUFqQBiR5mi57A5MakQRtgjWD/cH0Z4rMXIxJMm +bZOw0KwZCgBlN8t/O4ZkXuusI9A5pm9J/J59cTrFk+pCdbUgFH6YtzcVLrr3ejv0LB+ AhzY/OuQ+JMj6r67j7HmV9RlPQI86EHJ5uNUyZvQ6TarTAjV2+fMQ1UhCVYhpf/1CrNZ 4IyVPmkgc8QxB6txO0zIivMEFD4FGorhAqIcwGEqUcYbK9wd1l1byXz+vJmg8dAqM9sP Z12g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6zGLa2a1dMKbRjGqlY7/tEFjEO8oBKmnJ4xWmH0DN9A=; b=unMquTQf1zzrGft6N6H0NzZkDPZKYxnpr5whr6/DhcZPZLZ4hN4Oji6QlXNRJwXq4K 5tXd24iGBRxF+Pz5LE5FH7c0y4L3Loh8fmKKl7zss2LL8uuDDt8g/7weyqP1OrZ+bFWU umMMu4z0k6Q1TLeyy9GjO3AaP4+VjzC8tuEu5yGCGFMszYPu6rNfGIC1fyLzz6pRO4ll 08zOlYbVroD9GIcSzKGJr/pw4ZQPAKmjOsHME5Zvh54Ng+1DPOlIOPV2V6UyxcFMXuMt Y/hhpLTx4Zkfu8uzoP5e6jaSWK8RjiKB8/Nypstj+5ZhmEPxqdaetixfmQ2ZuEx4ApUW 5LyA== X-Gm-Message-State: AFeK/H37tWLlB3vZ/1+2ENOe/rnCKIFQILWFdd55yanxQWi3DiH2PgRztTmdLUKFCrPUyHINYU/Cq5nk3EzZ9g== X-Received: by 10.99.97.77 with SMTP id v74mr62580690pgb.76.1491924121757; Tue, 11 Apr 2017 08:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.7 with HTTP; Tue, 11 Apr 2017 08:21:41 -0700 (PDT) In-Reply-To: References: From: Joseph Salowey Date: Tue, 11 Apr 2017 08:21:41 -0700 Message-ID: To: Daniel Migault Cc: "tls@ietf.org" , draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org Content-Type: multipart/alternative; boundary=94eb2c0cc37a4f3f1b054ce5a70b Archived-At: Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 15:22:04 -0000 --94eb2c0cc37a4f3f1b054ce5a70b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Daniel, Please submit a revised draft with the changes below. Thanks, Joe On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault < daniel.migault@ericsson.com> wrote: > Hi, > > Thank you for the review and comments received. Given the discussion our > understanding was that the consensus was to remove CCM-256 so that suites > defined by the document apply both for TLS1.2 as well as for TLS1.3. The > draft available on github [1 > ] > has been updated as follows: > > > 1. Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead > of SHA384 like the other 256 bit cipher suites? (From Russ Housley) > > MGLT: This was a mistake in the IANA section. The cypher suite was correc= t > in the remaining text. However, the current version does not consider > anymore CCM-256* which also solves this issue. > > 2. Since the security considerations mention passwords (human chosen > secrets) it should mention dictionary attacks. (From Russ Housley) > > MGLT: The issue of human chosen passwords and dictionary attacks has been > mentioned in the security consideration with the following text: > > """ > Use of Pre-Shared Keys of limited entropy may allow an active > attacker attempts to connect to the server and tries different keys. > For example, limited entropy may be provided by using short PSK in > which case an attacker may perform a brute-force attack. Other > example includes the use of a PSK chosen by a human and thus may be > exposed to dictionary attacks. > """ > > > 3. Section 2 and 3 of the document contains more detail about TLS 1.3 > than necessary. > > Section 2: This document only defines cipher suites for TLS 1.2, not TLS > 1.2 or later. A subset of equivalent cipher suites is defined in the TLS > 1.3 specification. > > MGLT: CCM-256 has been removed from the specification so that suites can > be defined for TLS 1.2 as well as TLS1.3. The following text is considere= d. > > """ > This document defines new cipher suites that provide Pre-Shared Key > (PSK) authentication, Perfect Forward Secrecy (PFS), and > Authenticated Encryption with Associated Data (AEAD). The cipher > suites are defined for version 1.2 of the Transport Layer Security > (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer > Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS > [I-D.ietf-tls-tls13]. > """ > > Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to > section 4 that states: > > "TLS 1.3 and above name, negotiate and support a subset of these cipher > suites in a different way." (TLS 1.3 does not support > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256_ > CCM_8_SHA256) > > MGLT: As CCM-256 has been removed, we do not have to deal with the > situation where TLS1.3 only considers a subset of the suites defined for > TLS1.2. > > The following sentence in section 3 clarifies that codes points are only > defined for TLS1.2: =E2=80=9C=E2=80=9D=E2=80=9DThe assigned code points c= an only be used for TLS > 1.2.=E2=80=9D=E2=80=9D=E2=80=9D. The description of the TLS1.3 negotiatio= n has been limited in > section 4 to the following sentence: =E2=80=9C=E2=80=9D=E2=80=9DTLS 1.3 a= nd above version, > negotiate and support these cipher suites in a different way.=E2=80=9D=E2= =80=9D=E2=80=9D > > 4. Section 3 should contain a bit more detail about relationship to 4492 > bis and RFC 4279: > > Something like the following may be enough. > > "This messages and pre-master secret construction in this document are > based on [RFC4279]. The elliptic curve parameters used in in the > Diffie-Hellman parameters are negotiated using extensions defined in > [4492-bis]." > > MGLT: The sentence mentioned above has been added with [4492-bis] > mentioned as normative. > =E2=80=9C=E2=80=9D=E2=80=9D > Messages and pre-master secret construction in this document are > based on [RFC4279]. The elliptic curve parameters used in in the > Diffie-Hellman parameters are negotiated using extensions defined in > [I-D.ietf-tls-rfc4492bis]. > =E2=80=9C=E2=80=9D=E2=80=9D > > [1] https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/ > master/draft-ietf-tls-ecdhe-psk-aead > > Yours, > Daniel and John > > > On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey wrote: > >> Here are the open issues for draft-ietf-tls-ecdhe-psk-aead >> >> 1. Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead >> of SHA384 like the other 256 bit cipher suites? (From Russ Housley) >> >> 2. Since the security considerations mention passwords (human chosen >> secrets) it should mention dictionary attacks. (From Russ Housley) >> >> 3. Section 2 and 3 of the document contains more detail about TLS 1.3 >> than necessary. >> >> Section 2: This document only defines cipher suites for TLS 1.2, not TLS >> 1.2 or later. A subset of equivalent cipher suites is defined in the TL= S >> 1.3 specification. >> >> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to >> section 4 that states: >> >> "TLS 1.3 and above name, negotiate and support a subset of these cipher >> suites in a different way." (TLS 1.3 does not support >> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256 >> _CCM_8_SHA256) >> >> 4. Section 3 should contain a bit more detail about relationship to 4492 >> bis and RFC 4279: >> >> Something like the following may be enough. >> >> "This messages and pre-master secret construction in this document are >> based on [RFC4279]. The elliptic curve parameters used in in the >> Diffie-Hellman parameters are negotiated using extensions defined in >> [4492-bis]." >> >> Thanks, >> >> Joe >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --94eb2c0cc37a4f3f1b054ce5a70b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Daniel,

Please submit a revised draf= t with the changes below.

Thanks,

Joe

O= n Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault <daniel.migault@= ericsson.com> wrote:
Hi,

Thank you for the review and comments recei= ved. Given the discussion our understanding was that the consensus was to r= emove CCM-256 so that suites defined by the document apply both for TLS1.2 = as well as for TLS1.3. The draft available on github [1]=C2=A0 has been updated as follows:=C2= =A0


1.=C2=A0 Why does TLS_ECDHE_PSK_WITH_AES_2= 56_CCM_8_SHA256 use SHA256 instead of SHA384 like the other 256 bit ci= pher suites? (From Russ Housley)

MGLT: This was a mistake in = the IANA section. The cypher suite was correct in the remaining text. Howev= er, the current version does not=C2=A0 consider anymore CCM-256* which also= solves this issue.
=C2=A0
2.=C2=A0 Since the securi= ty considerations mention passwords (human chosen secrets) it should mentio= n dictionary attacks. (From Russ Housley)
=C2=A0
MGLT: The iss= ue of human chosen passwords and dictionary attacks has been mentioned in t= he security consideration with the following text:

"""= ;
=C2=A0=C2=A0 Use of Pre-Shared Keys of limited entropy may allow an a= ctive
=C2=A0=C2=A0 attacker attempts to connect to the server and tries = different keys.
=C2=A0=C2=A0 For example, limited entropy may be provide= d by using short PSK in
=C2=A0=C2=A0 which case an attacker may perform = a brute-force attack.=C2=A0 Other
=C2=A0=C2=A0 example includes the use = of a PSK chosen by a human and thus may be
=C2=A0=C2=A0 exposed to dicti= onary attacks.
"""

=C2=A0
3.= =C2=A0 Section 2 and 3 of the document contains more detail about TLS 1.3 t= han necessary.=C2=A0
=C2=A0
Section 2: This document only defines ci= pher suites for TLS 1.2, not TLS 1.2 or later.=C2=A0 A subset of equivalent= cipher suites is defined in the TLS 1.3 specification.=C2=A0
=C2=A0MGLT: CCM-256 has been removed from the specification so that suite= s can be defined for TLS 1.2 as well as TLS1.3. The following text is consi= dered.

"""
=C2=A0=C2=A0 This document defines ne= w cipher suites that provide Pre-Shared Key
=C2=A0=C2=A0 (PSK) authentic= ation, Perfect Forward Secrecy (PFS), and
=C2=A0=C2=A0 Authenticated Enc= ryption with Associated Data (AEAD).=C2=A0 The cipher
=C2=A0=C2=A0 suite= s are defined for version 1.2 of the Transport Layer Security
=C2=A0=C2= =A0 (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer=C2=A0=C2=A0 Security (DTLS) protocol [RFC6347], as well as version 1.3 o= f TLS
=C2=A0=C2=A0 [I-D.ietf-tls-tls13].
""= ;"
=C2=A0
Section 3 and 4: Maybe replace the last 2 paragraphs w= ith an addition to section 4 that states:
=C2=A0
"TLS 1.3 and ab= ove name, negotiate and support a subset of these cipher suites in a differ= ent way."=C2=A0 (TLS 1.3 does not support TLS_ECDHE_PSK_WITH_AES_256_<= wbr>CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256)
=C2=A0<= br>MGLT: As CCM-256 has been removed, we do not have to deal with th= e situation where TLS1.3 only considers a subset of the suites defined for = TLS1.2.

The following sentence in section 3 clarifies that codes po= ints are only defined for TLS1.2: =E2=80=9C=E2=80=9D=E2=80=9DThe assigned c= ode points can only be used for TLS 1.2.=E2=80=9D=E2=80=9D=E2=80=9D. The de= scription of the TLS1.3 negotiation has been limited in section 4 to the fo= llowing sentence: =E2=80=9C=E2=80=9D=E2=80=9DTLS 1.3 and above version, neg= otiate and support these cipher suites in a different way.=E2=80=9D=E2=80= =9D=E2=80=9D
=C2=A0
4. Section 3 should contain a bi= t more detail about relationship to 4492 bis and RFC 4279:
=C2=A0
Som= ething like the following may be enough.=C2=A0

"This messages = and pre-master secret construction in this document are based on [RFC4279].= =C2=A0 The elliptic curve parameters used in in the Diffie-Hellman paramete= rs are negotiated using extensions defined in [4492-bis]."
=C2=A0MGLT: The sentence mentioned above has been added with [4492-bis] = mentioned as normative.
=E2=80=9C=E2=80=9D=E2=80=9D
=C2=A0=C2=A0=C2= =A0 Messages and pre-master secret construction in this document are
=C2=A0=C2=A0 based on [RFC4279].=C2=A0 The elliptic curve par= ameters used in in the
=C2=A0=C2=A0 Diffie-Hellman parameters are negoti= ated using extensions defined in
=C2=A0=C2=A0 [I-D.ietf-tls-rfc44= 92bis].
=E2=80=9C=E2=80=9D=E2=80=9D

[1] https://github.com/mglt/draft-ietf-tls-ecdh= e-psk-aead/blob/master/draft-ietf-tls-ecdhe-psk-aead

<= /div>Yours,
Daniel and John


On Tue, Feb 21= , 2017 at 1:22 PM, Joseph Salowey <joe@salowey.net> wrote:
=
Here are the open issues for=C2=A0draft-ietf-tls= -ecdhe-psk-aead

1.=C2=A0 Why does=C2=A0TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead of SHA384 like the other= 256 bit cipher suites? (From Russ Housley)

2.=C2=A0 Since the security consid= erations mention passwords (human chosen secrets) it should mention diction= ary attacks. (From Russ Housley)

3.=C2=A0 Section = 2 and 3 of the document contains more detail about TLS 1.3 than necessary. = =C2=A0

Section 2: This document only defines ciphe= r suites for TLS 1.2, not TLS 1.2 or later.=C2=A0 A subset of equivalent ci= pher suites is defined in the TLS 1.3 specification. =C2=A0

<= /div>
Section 3 and 4: Maybe replace the last 2 paragraphs with an addi= tion to section 4 that states:

"TLS 1.3 and a= bove name, negotiate and support a subset of these cipher suites in a diffe= rent way." =C2=A0(TLS 1.3 does not support=C2=A0TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 a= nd=C2=A0TLS_ECD= HE_PSK_WITH_AES_256_CCM_8_SHA256)

= 4. Section 3 should contain a bit more detail about relationship to 4492 bi= s and RFC 4279:

Something like the following may b= e enough. =C2=A0

"This messages and pre-master secret construction in this documen= t are based on [RFC4279].=C2=A0 The elliptic curve parameters used in in th= e Diffie-Hellman parameters are negotiated using extensions defined in [449= 2-bis]."

Thanks,

Joe




_____________________________________= __________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--94eb2c0cc37a4f3f1b054ce5a70b-- From nobody Tue Apr 11 10:33:04 2017 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 05E10129584 for ; Tue, 11 Apr 2017 10:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham 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 rr4-UIfmd9rS for ; Tue, 11 Apr 2017 10:32:59 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 56217128D69 for ; Tue, 11 Apr 2017 10:32:59 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l189so1896203ywb.0 for ; Tue, 11 Apr 2017 10:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rYcpP+yp1bXWaBfjV/heJu4qo0zynPTlK8qEzdFFJv8=; b=lsc8cH/UFaiwquoL9NsUTnrERQp4o9lI76UjeTyD77tc+pktQNVIbLw5tWOMICfAnE Jp6J1zXJbFFT8mq8THlBDQvCqxn/jwCxoNxvqg+yIzwXfuC4nVpbksS3+qHQQNFTPYDV 6sk2rJ7hOme3x2Nt/J2XUgIjCgLofOgUwiB4/ZXRVVrKQCMl54zYMrt13fMAn4OgGz4Q q3hmtUObzoC4gYriVqRHG9uUNiApVwOv0Umg73ykAyq/Ul4+t+Sl2vViJhjGueZcmXSh DEdDdhYDrgQduPS8FSoKpbO8fwi6EO78ICvLUOhBA22pO1jnrP3t1hGzQnx8aUbt8MM1 9TSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rYcpP+yp1bXWaBfjV/heJu4qo0zynPTlK8qEzdFFJv8=; b=ZA9HTQC3ebHn65w2TLM+YjZNOxG6VnqEOozm13r2U78TKo7eN/8tpiPpEZK4SiEa3E aOXUA/JDZdAtAxEjLEwFow4A5oe3QIT67r41Xe2sRIlqGMDu0c04aBpXhoKkmVk8jqRX GRFDL/YIlzMaDhHsflnDfDINkGac6h7pI2XN/Q7bEAXErUZ7SKh7Cm321tTHg2bEIBG2 0Cm3Y2F5XCTPkVTtpFJ645FIDSZsDQnkNq+u+qB7Z5griE/LAL9wIiTRqfOHCboR3k3V Kav2VwrhUxPxisCxZv631s+WBmlUF7zbUyZWWpHjMEE7lowhKgiM/h02gtfp1kMKiPUw sYYA== X-Gm-Message-State: AN3rC/5PmwzhX2ScTFOOyGZhtWnkKCRnuruw08PSqIQLH2PSAsGIdIDXkXYbmVXAVGBPOAesq2eDDMaOk3iTuA== X-Received: by 10.13.203.73 with SMTP id n70mr8177562ywd.71.1491931978492; Tue, 11 Apr 2017 10:32:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 11 Apr 2017 10:32:17 -0700 (PDT) In-Reply-To: <228B1CCF-088B-4F4C-B2FD-A20036B9224A@akamai.com> References: <025D3ABD-199F-421A-9265-6F960135A3B7@sn3rd.com> <228B1CCF-088B-4F4C-B2FD-A20036B9224A@akamai.com> From: Eric Rescorla Date: Tue, 11 Apr 2017 10:32:17 -0700 Message-ID: To: "Kaduk, Ben" Cc: Sean Turner , "" Content-Type: multipart/alternative; boundary=001a114fd3d69b8fa5054ce77bbe Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 17:33:03 -0000 --001a114fd3d69b8fa5054ce77bbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > It was already mentioned that the =E2=80=9Cmajor differences from TLS 1.2= =E2=80=9D > section should not be a changelog, but I agree with that. Yes, this is on my plate. > Should Figure 4 (=E2=80=9Cmessage flow for a zero round trip handshake=E2= =80=9D) > include a =E2=80=9C+ early_data=E2=80=9D for the server=E2=80=99s flight?= (The legend for > Figure 4 also lacks the explanation for the =E2=80=98+=E2=80=99 symbol.) I see you fixed this. > The language on page 30 is perhaps unclear: > > Because TLS 1.3 forbids renegotiation, if a server receives a > ClientHello at any other time, it MUST terminate the connection. > > Is that any TLS server, or just one that has negotiated and is using > TLS 1.3? The latter. Adjusted. > In the description of legacy_compression_methods on page 31, we make > restrictions on =E2=80=9Cevery TLS 1.3 ClientHello=E2=80=9D, but do not s= ay how such > things are identified. (Hmm, maybe we also do so elsewhere in the > document, too, now that I search for where) we explicitly define what > a client =E2=80=9Cconsidered to be attempting to negotiate using this > specification (i.e., a TLS 1.3 ClientHEello) on page 87, as > supported_versions including 1.3. Which, is maybe not the most > future-proof thing. I think I feel OK about this. > The description of version negotiation (to populate > ServerHello.version) on page 32 seems to leave undefined what the > server should do when receiving a ClientHello that does not contain a > supported_versions extension. (Also, I don=E2=80=99t think > =E2=80=9CClientHello.supported_versions extension=E2=80=9D is a well-defi= ned syntax.) I think this clear in the section on Supported Versions. > When covering the server_random version downgrade sentinels, we do not > mention what is to be done when downgrading to TLS 1.0, which I > thought was still a permitted version by this spec. Interesting point. I'm trying to remember why we did things this way. I am tempted to just say "1.1 or 1.0". Thoughts? > It=E2=80=99s a little odd that we list in enum ExtensionType on page 35 a > strict subset of the extensions enumerated in the table on the > following pages. This got fixed in PR#936. > Do we want to add some commentary about the extant SHA1 collisions > when we say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT? Nah. > I=E2=80=99ll note that we define 256 private use ECDHE group code points = but > only four such FFDHE group code points. Probably fine, but a bit > surprising. Too late now!! > Should we forbid duplicate entries in > PreSharedKeyExtension.identities? I don't think that's necessary. > Conversely, we might want to explicitly say that duplicate > OIDFilter.certificate_extension_oid fields should be expected in > OIDFilterExtensions, to enable the case where multiple values must be > present. Or is that supposed to work by concatenating(?) the multiple > values=E2=80=99 DER encodings in the certificate_extension_values field? Yeah, I read this text as saying that those all go in the same DER, not that there can be multiple copies > I=E2=80=99ll call out for Russ=E2=80=99s attention at the end of Section = 4.4.3 where > we say that =E2=80=9Cimplementations MUST NOT combine external PSKs with > certificate-based authentication.=E2=80=9D Is there any reason not to qu= alify > that as some sort of =E2=80=9Cdon=E2=80=99t=E2=80=99 do it until it=E2=80= =99s defined=E2=80=9D? I'm actually going to move and modify this section per your issue #935. > Should Alert.level be Alert.legacy_level? i think we went over this and decided not to. > Appendix B has a claim that =E2=80=9Cvalues listed as _RESERVED were used= in > previous versions of TLS and are listed here for completeness=E2=80=9D, t= hough > that is not exactly true, e.g., for ContentType.invalid_RESERVED(0) I see you fixed this as well. > Section C.3 notes that =E2=80=9CCertificates should always be verified to > ensure proper signing by a trusted Certificate Authority=E2=80=9D, which = does > not use RFC 2119 language, but might be seen as in conflict with > opportunistic encryption in some circumstances. I don=E2=80=99t object t= o > this text, but it seems worth mentioning. I think the "Absent a specific..." > Page 113 still has the =E2=80=9C[[NOTE: TLS 1.3 needs a new channel bindi= ng > definition that has not yet been defined.]]=E2=80=9D, which should not ma= ke it > into the final spec! Fixed. On Mon, Mar 27, 2017 at 11:23 PM, Kaduk, Ben wrote: > On 3/13/17, 12:30, "Sean Turner" wrote: > > This is a working group last call announcement for > draft-ietf-tls-tls13-19, to run through March 27. Please send your revie= ws > to the list as soon as possible so we can prepare for any discussion of > open issues at IETF 98 in Chicago. > > As the price of running the WGLC right during the meeting lead-up, my > review comes in at the last minute. > > Generally, it is in good shape. I think I still owe some text about what > we aim for and expect to achieve with respect to side channel resistance, > though at this point it may be too late to get that text in :( > > The following is basically a laundry list of the minor issues; I will sen= d > editorial notes under separate cover, probably as a pull request. > > It was already mentioned that the =E2=80=9Cmajor differences from TLS 1.2= =E2=80=9D section > should not be a changelog, but I agree with that. > > Should Figure 4 (=E2=80=9Cmessage flow for a zero round trip handshake=E2= =80=9D) include a > =E2=80=9C+ early_data=E2=80=9D for the server=E2=80=99s flight? (The leg= end for Figure 4 also > lacks the explanation for the =E2=80=98+=E2=80=99 symbol.) > > The language on page 30 is perhaps unclear: > > Because TLS 1.3 forbids renegotiation, if a server receives a > ClientHello at any other time, it MUST terminate the connection. > > Is that any TLS server, or just one that has negotiated and is using TLS > 1.3? > > In the description of legacy_compression_methods on page 31, we make > restrictions on =E2=80=9Cevery TLS 1.3 ClientHello=E2=80=9D, but do not s= ay how such things > are identified. (Hmm, maybe we also do so elsewhere in the document, too= , > now that I search for where) we explicitly define what a client > =E2=80=9Cconsidered to be attempting to negotiate using this specificatio= n (i.e., a > TLS 1.3 ClientHEello) on page 87, as supported_versions including 1.3. > Which, is maybe not the most future-proof thing. > > The description of version negotiation (to populate ServerHello.version) > on page 32 seems to leave undefined what the server should do when > receiving a ClientHello that does not contain a supported_versions > extension. (Also, I don=E2=80=99t think =E2=80=9CClientHello.supported_v= ersions > extension=E2=80=9D is a well-defined syntax.) > > When covering the server_random version downgrade sentinels, we do not > mention what is to be done when downgrading to TLS 1.0, which I thought w= as > still a permitted version by this spec. > > It=E2=80=99s a little odd that we list in enum ExtensionType on page 35 a= strict > subset of the extensions enumerated in the table on the following pages. > > Do we want to add some commentary about the extant SHA1 collisions when w= e > say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT? > > I=E2=80=99ll note that we define 256 private use ECDHE group code points = but only > four such FFDHE group code points. Probably fine, but a bit surprising. > > Should we forbid duplicate entries in PreSharedKeyExtension.identities? > > Conversely, we might want to explicitly say that duplicate > OIDFilter.certificate_extension_oid fields should be expected in > OIDFilterExtensions, to enable the case where multiple values must be > present. Or is that supposed to work by concatenating(?) the multiple > values=E2=80=99 DER encodings in the certificate_extension_values field? > > I=E2=80=99ll call out for Russ=E2=80=99s attention at the end of Section = 4.4.3 where we > say that =E2=80=9Cimplementations MUST NOT combine external PSKs with > certificate-based authentication.=E2=80=9D Is there any reason not to qu= alify that > as some sort of =E2=80=9Cdon=E2=80=99t=E2=80=99 do it until it=E2=80=99s = defined=E2=80=9D? > > Should Alert.level be Alert.legacy_level? > > The editors copy has already removed the reference to RFC 4507, which is > obsoleted by RFC 5077 (and was not cited anywhere, anyway). > > Appendix B has a claim that =E2=80=9Cvalues listed as _RESERVED were used= in > previous versions of TLS and are listed here for completeness=E2=80=9D, t= hough that > is not exactly true, e.g., for ContentType.invalid_RESERVED(0) > > Section C.3 notes that =E2=80=9CCertificates should always be verified to= ensure > proper signing by a trusted Certificate Authority=E2=80=9D, which does no= t use RFC > 2119 language, but might be seen as in conflict with opportunistic > encryption in some circumstances. I don=E2=80=99t object to this text, b= ut it > seems worth mentioning. > > Page 113 still has the =E2=80=9C[[NOTE: TLS 1.3 needs a new channel bindi= ng > definition that has not yet been defined.]]=E2=80=9D, which should not ma= ke it into > the final spec! > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114fd3d69b8fa5054ce77bbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> It was already mentioned that the =E2=80=9Cmajor= differences from TLS 1.2=E2=80=9D
> section should not be a c= hangelog, but I agree with that.

Yes, this is on m= y plate.


> Should Figure 4 (=E2= =80=9Cmessage flow for a zero round trip handshake=E2=80=9D)
>= include a =E2=80=9C+ early_data=E2=80=9D for the server=E2=80=99s flight? = =C2=A0(The legend for
> Figure 4 also lacks the explanation fo= r the =E2=80=98+=E2=80=99 symbol.)

I see you fixed= this.


> The language on page 30= is perhaps unclear:
>=C2=A0
> =C2=A0 =C2=A0Becau= se TLS 1.3 forbids renegotiation, if a server receives a
> =C2= =A0 =C2=A0ClientHello at any other time, it MUST terminate the connection.<= /div>
>=C2=A0
> Is that any TLS server, or just one tha= t has negotiated and is using
> TLS 1.3?

<= div>The latter. Adjusted.


> In t= he description of legacy_compression_methods on page 31, we make
= > restrictions on =E2=80=9Cevery TLS 1.3 ClientHello=E2=80=9D, but do no= t say how such
> things are identified. =C2=A0(Hmm, maybe we a= lso do so elsewhere in the
> document, too, now that I search = for where) we explicitly define what
> a client =E2=80=9Cconsi= dered to be attempting to negotiate using this
> specification= (i.e., a TLS 1.3 ClientHEello) on page 87, as
> supported_ver= sions including 1.3.=C2=A0 Which, is maybe not the most
> futu= re-proof thing.

I think I feel OK about this.


> The description of version negotia= tion (to populate
> ServerHello.version) on page 32 seems to l= eave undefined what the
> server should do when receiving a Cl= ientHello that does not contain a
> supported_versions extensi= on. =C2=A0(Also, I don=E2=80=99t think
> =E2=80=9CClientHello.= supported_versions extension=E2=80=9D is a well-defined syntax.)
=
I think this clear in the section on Supported Versions.


> When covering the server_random v= ersion downgrade sentinels, we do not
> mention what is to be = done when downgrading to TLS 1.0, which I
> thought was still = a permitted version by this spec.

Interesting poin= t. I'm trying to remember why we did things this way.
I am te= mpted to just say "1.1 or 1.0". Thoughts?


> It=E2=80=99s a little odd that we list in enum Extens= ionType on page 35 a
> strict subset of the extensions enumera= ted in the table on the
> following pages.

This got fixed in PR#936.


> Do we want to add some commentary about the extant SHA1 co= llisions
> when we say that {rsa_pkcs1,dsa,ecdsa}_sha1 are onl= y SHOULD NOT?

Nah.


> I=E2=80=99ll note that we define 256 private use ECDHE group = code points but
> only four such FFDHE group code points.=C2= =A0 Probably fine, but a bit
> surprising.

Too late now!!


> Should we= forbid duplicate entries in
> PreSharedKeyExtension.identitie= s?

I don't think that's necessary.


> Conversely, we might want to explicit= ly say that duplicate
> OIDFilter.certificate_extension_oid fi= elds should be expected in
> OIDFilterExtensions, to enable th= e case where multiple values must be
> present.=C2=A0 Or is th= at supposed to work by concatenating(?) the multiple
> values= =E2=80=99 DER encodings in the certificate_extension_values field?

Yeah, I read this text as saying that those all go in the = same
DER, not that there can be multiple copies


> I=E2=80=99ll call out for Russ=E2=80=99s attent= ion at the end of Section 4.4.3 where
> we say that =E2=80=9Ci= mplementations MUST NOT combine external PSKs with
> certifica= te-based authentication.=E2=80=9D =C2=A0Is there any reason not to qualify<= /div>
> that as some sort of =E2=80=9Cdon=E2=80=99t=E2=80=99 do it u= ntil it=E2=80=99s defined=E2=80=9D?

I'm actual= ly going to move and modify this section per your issue #935.

> Should Alert.level be Alert.legacy_level?

i think we went over this and decided not to.
=


> Appendix B has a claim that =E2=80= =9Cvalues listed as _RESERVED were used in
> previous versions= of TLS and are listed here for completeness=E2=80=9D, though
>= ; that is not exactly true, e.g., for ContentType.invalid_RESERVED(0)
=

I see you fixed this as well.

=
> Section C.3 notes that =E2=80=9CCertificates should alw= ays be verified to
> ensure proper signing by a trusted Certif= icate Authority=E2=80=9D, which does
> not use RFC 2119 langua= ge, but might be seen as in conflict with
> opportunistic encr= yption in some circumstances.=C2=A0 I don=E2=80=99t object to
>= ; this text, but it seems worth mentioning.

I thin= k the "Absent a specific..."


<= div>> Page 113 still has the =E2=80=9C[[NOTE: TLS 1.3 needs a new channe= l binding
> definition that has not yet been defined.]]=E2=80= =9D, which should not make it
> into the final spec!

Fixed.


On Mon, Mar 27, 2017 at 11:23 PM, Kaduk, Be= n <bkaduk@akamai.com> wrote:
On 3/13/17, 12:30, "Sean Turner" <sean@sn3rd.com> wrote:

=C2=A0 =C2=A0 This is a working group last call announcement for draft-ietf= -tls-tls13-19, to run through March 27.=C2=A0 Please send your reviews to t= he list as soon as possible so we can prepare for any discussion of open is= sues at IETF 98 in Chicago.

As the price of running the WGLC right during the meeting lead-up, m= y review comes in at the last minute.

Generally, it is in good shape.=C2=A0 I think I still owe some text about w= hat we aim for and expect to achieve with respect to side channel resistanc= e, though at this point it may be too late to get that text in :(

The following is basically a laundry list of the minor issues; I will send = editorial notes under separate cover, probably as a pull request.

It was already mentioned that the =E2=80=9Cmajor differences from TLS 1.2= =E2=80=9D section should not be a changelog, but I agree with that.

Should Figure 4 (=E2=80=9Cmessage flow for a zero round trip handshake=E2= =80=9D) include a =E2=80=9C+ early_data=E2=80=9D for the server=E2=80=99s f= light?=C2=A0 (The legend for Figure 4 also lacks the explanation for the = =E2=80=98+=E2=80=99 symbol.)

The language on page 30 is perhaps unclear:

=C2=A0 =C2=A0Because TLS 1.3 forbids renegotiation, if a server receives a<= br> =C2=A0 =C2=A0ClientHello at any other time, it MUST terminate the connectio= n.

Is that any TLS server, or just one that has negotiated and is using TLS 1.= 3?

In the description of legacy_compression_methods on page 31, we make restri= ctions on =E2=80=9Cevery TLS 1.3 ClientHello=E2=80=9D, but do not say how s= uch things are identified.=C2=A0 (Hmm, maybe we also do so elsewhere in the= document, too, now that I search for where)=C2=A0 we explicitly define wha= t a client =E2=80=9Cconsidered to be attempting to negotiate using this spe= cification (i.e., a TLS 1.3 ClientHEello) on page 87, as supported_versions= including 1.3.=C2=A0 Which, is maybe not the most future-proof thing.

The description of version negotiation (to populate ServerHello.version) on= page 32 seems to leave undefined what the server should do when receiving = a ClientHello that does not contain a supported_versions extension.=C2=A0 (= Also, I don=E2=80=99t think =E2=80=9CClientHello.supported_versions ex= tension=E2=80=9D is a well-defined syntax.)

When covering the server_random version downgrade sentinels, we do not ment= ion what is to be done when downgrading to TLS 1.0, which I thought was sti= ll a permitted version by this spec.

It=E2=80=99s a little odd that we list in enum ExtensionType on page 35 a s= trict subset of the extensions enumerated in the table on the following pag= es.

Do we want to add some commentary about the extant SHA1 collisions when we = say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?

I=E2=80=99ll note that we define 256 private use ECDHE group code points bu= t only four such FFDHE group code points.=C2=A0 Probably fine, but a bit su= rprising.

Should we forbid duplicate entries in PreSharedKeyExtension.identities= ?

Conversely, we might want to explicitly say that duplicate OIDFilter.certif= icate_extension_oid fields should be expected in OIDFilterExtensions, = to enable the case where multiple values must be present.=C2=A0 Or is that = supposed to work by concatenating(?) the multiple values=E2=80=99 DER encod= ings in the certificate_extension_values field?

I=E2=80=99ll call out for Russ=E2=80=99s attention at the end of Section 4.= 4.3 where we say that =E2=80=9Cimplementations MUST NOT combine external PS= Ks with certificate-based authentication.=E2=80=9D=C2=A0 Is there any reaso= n not to qualify that as some sort of =E2=80=9Cdon=E2=80=99t=E2=80=99 do it= until it=E2=80=99s defined=E2=80=9D?

Should Alert.level be Alert.legacy_level?

The editors copy has already removed the reference to RFC 4507, which is ob= soleted by RFC 5077 (and was not cited anywhere, anyway).

Appendix B has a claim that =E2=80=9Cvalues listed as _RESERVED were used i= n previous versions of TLS and are listed here for completeness=E2=80=9D, t= hough that is not exactly true, e.g., for ContentType.invalid_RESERVED(0)

Section C.3 notes that =E2=80=9CCertificates should always be verified to e= nsure proper signing by a trusted Certificate Authority=E2=80=9D, which doe= s not use RFC 2119 language, but might be seen as in conflict with opportun= istic encryption in some circumstances.=C2=A0 I don=E2=80=99t object to thi= s text, but it seems worth mentioning.

Page 113 still has the =E2=80=9C[[NOTE: TLS 1.3 needs a new channel binding= definition that has not yet been defined.]]=E2=80=9D, which should not mak= e it into the final spec!

-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114fd3d69b8fa5054ce77bbe-- From nobody Tue Apr 11 11:27:16 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C8F129A92; Tue, 11 Apr 2017 11:27:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149193523484.15726.2369879883187698438@ietfa.amsl.com> Date: Tue, 11 Apr 2017 11:27:14 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:27:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Authors : John Mattsson Daniel Migault Filename : draft-ietf-tls-ecdhe-psk-aead-02.txt Pages : 7 Date : 2017-04-11 Abstract: This document defines several new cipher suites for the Transport Layer Security (TLS) protocol. The cipher suites are all based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides perfect forward secrecy, and AES-GCM and AES-CCM provides encryption and integrity protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 11 11:28:18 2017 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 B198112EC03 for ; Tue, 11 Apr 2017 11:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 crdUtJb92kDg for ; Tue, 11 Apr 2017 11:28:07 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8293312EB7F for ; Tue, 11 Apr 2017 11:27:43 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B91C743342D; Tue, 11 Apr 2017 18:27:42 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 973BC433405; Tue, 11 Apr 2017 18:27:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1491935262; bh=/u/z/Pq3gSypXMavKHLxcRRQsS30OFzs8RPGLDucsMk=; l=25836; h=To:References:Cc:From:Date:In-Reply-To:From; b=BPhFsHazPZGs98c5E9agYiSZrSIpbCENiqzs5GRDJdHrUxac2lUhuprZAyZ/aPMGt u+/xNkrmXm7uV9RLzeKTCl70wOGxITtg8Dv1ZEG6RmwdVsRR/MppZVl6i9yDrGhAPk EvHmcqgcDU9w09T5+3dynHqJh1KgOSdJL57UMe2c= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 2D4B01FC8B; Tue, 11 Apr 2017 18:27:42 +0000 (GMT) To: Eric Rescorla References: <025D3ABD-199F-421A-9265-6F960135A3B7@sn3rd.com> <228B1CCF-088B-4F4C-B2FD-A20036B9224A@akamai.com> Cc: Sean Turner , "" From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <43ce161a-a107-5491-71e0-d6fecd9665a6@akamai.com> Date: Tue, 11 Apr 2017 13:27:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A162052703C229EC80D601D2" Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:28:12 -0000 This is a multi-part message in MIME format. --------------A162052703C229EC80D601D2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 04/11/2017 12:32 PM, Eric Rescorla wrote: > > It was already mentioned that the “major differences from TLS 1.2†> > section should not be a changelog, but I agree with that. > > Yes, this is on my plate. > > > > Should Figure 4 (“message flow for a zero round trip handshakeâ€) > > include a “+ early_data†for the server’s flight? (The legend for > > Figure 4 also lacks the explanation for the ‘+’ symbol.) > > I see you fixed this. > I guess I didn't consult back with what I had put in this mail when preparing my editorial-changes pull request :) > > > The language on page 30 is perhaps unclear: > > > > Because TLS 1.3 forbids renegotiation, if a server receives a > > ClientHello at any other time, it MUST terminate the connection. > > > > Is that any TLS server, or just one that has negotiated and is using > > TLS 1.3? > > The latter. Adjusted. > > > > In the description of legacy_compression_methods on page 31, we make > > restrictions on “every TLS 1.3 ClientHelloâ€, but do not say how such > > things are identified. (Hmm, maybe we also do so elsewhere in the > > document, too, now that I search for where) we explicitly define what > > a client “considered to be attempting to negotiate using this > > specification (i.e., a TLS 1.3 ClientHEello) on page 87, as > > supported_versions including 1.3. Which, is maybe not the most > > future-proof thing. > > I think I feel OK about this. > (For the gallery, there were some tweaks in this area in #936) > > > The description of version negotiation (to populate > > ServerHello.version) on page 32 seems to leave undefined what the > > server should do when receiving a ClientHello that does not contain a > > supported_versions extension. (Also, I don’t think > > “ClientHello.supported_versions extension†is a well-defined syntax.) > > I think this clear in the section on Supported Versions. > It looks like this changed a little via #936 as well; I'm fine with your followup change there. > > > When covering the server_random version downgrade sentinels, we do not > > mention what is to be done when downgrading to TLS 1.0, which I > > thought was still a permitted version by this spec. > > Interesting point. I'm trying to remember why we did things this way. > I am tempted to just say "1.1 or 1.0". Thoughts? > That's probably fine; I expect there is some additional attack in there where an attacker could force 1.0 if 1.1 would otherwise have been used, but both of those are not in a great place right now, so we don't need to try too hard to help them out. > > > > Conversely, we might want to explicitly say that duplicate > > OIDFilter.certificate_extension_oid fields should be expected in > > OIDFilterExtensions, to enable the case where multiple values must be > > present. Or is that supposed to work by concatenating(?) the multiple > > values’ DER encodings in the certificate_extension_values field? > > Yeah, I read this text as saying that those all go in the same > DER, not that there can be multiple copies > Okay. > > > I’ll call out for Russ’s attention at the end of Section 4.4.3 where > > we say that “implementations MUST NOT combine external PSKs with > > certificate-based authentication.†Is there any reason not to qualify > > that as some sort of “don’t’ do it until it’s definedâ€? > > I'm actually going to move and modify this section per your issue #935. > Yeah, I missed the bits I called out in #935 when I was doing my WGLC review, but the two are related and can be handled together. > > > Should Alert.level be Alert.legacy_level? > > i think we went over this and decided not to. > There was a pull request from not-me, yes. Though IIRC it only changed the name locally when describing alerts, and was rejected on the grounds that "we don't use the legacy_level version for this anywhere else in the spec", which is a little bit of circular reasoning. I'm okay with leaving it as-is. > > > Appendix B has a claim that “values listed as _RESERVED were used in > > previous versions of TLS and are listed here for completenessâ€, though > > that is not exactly true, e.g., for ContentType.invalid_RESERVED(0) > > I see you fixed this as well. > Well, maybe. ContentType.invalid is the only one that I marked up in red pen on my paper copy, but I can't certify that I compared the entire list against the IANA registry. I did look at the extensions registry when preparing #936, though. > > > Section C.3 notes that “Certificates should always be verified to > > ensure proper signing by a trusted Certificate Authorityâ€, which does > > not use RFC 2119 language, but might be seen as in conflict with > > opportunistic encryption in some circumstances. I don’t object to > > this text, but it seems worth mentioning. > > I think the "Absent a specific..." > > Yeah, I guess I snuck that fix into #936. So much for keeping things separate... > > Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel binding > > definition that has not yet been defined.]]â€, which should not make it > > into the final spec! > > Fixed. > It looks like that was just by removing the note. Is a channel binding spec for 1.3 still a needed work item, then? -Ben > > On Mon, Mar 27, 2017 at 11:23 PM, Kaduk, Ben > wrote: > > On 3/13/17, 12:30, "Sean Turner" > wrote: > > This is a working group last call announcement for > draft-ietf-tls-tls13-19, to run through March 27. Please send > your reviews to the list as soon as possible so we can prepare for > any discussion of open issues at IETF 98 in Chicago. > > As the price of running the WGLC right during the meeting lead-up, > my review comes in at the last minute. > > Generally, it is in good shape. I think I still owe some text > about what we aim for and expect to achieve with respect to side > channel resistance, though at this point it may be too late to get > that text in :( > > The following is basically a laundry list of the minor issues; I > will send editorial notes under separate cover, probably as a pull > request. > > It was already mentioned that the “major differences from TLS 1.2†> section should not be a changelog, but I agree with that. > > Should Figure 4 (“message flow for a zero round trip handshakeâ€) > include a “+ early_data†for the server’s flight? (The legend for > Figure 4 also lacks the explanation for the ‘+’ symbol.) > > The language on page 30 is perhaps unclear: > > Because TLS 1.3 forbids renegotiation, if a server receives a > ClientHello at any other time, it MUST terminate the connection. > > Is that any TLS server, or just one that has negotiated and is > using TLS 1.3? > > In the description of legacy_compression_methods on page 31, we > make restrictions on “every TLS 1.3 ClientHelloâ€, but do not say > how such things are identified. (Hmm, maybe we also do so > elsewhere in the document, too, now that I search for where) we > explicitly define what a client “considered to be attempting to > negotiate using this specification (i.e., a TLS 1.3 ClientHEello) > on page 87, as supported_versions including 1.3. Which, is maybe > not the most future-proof thing. > > The description of version negotiation (to populate > ServerHello.version) on page 32 seems to leave undefined what the > server should do when receiving a ClientHello that does not > contain a supported_versions extension. (Also, I don’t think > “ClientHello.supported_versions extension†is a well-defined syntax.) > > When covering the server_random version downgrade sentinels, we do > not mention what is to be done when downgrading to TLS 1.0, which > I thought was still a permitted version by this spec. > > It’s a little odd that we list in enum ExtensionType on page 35 a > strict subset of the extensions enumerated in the table on the > following pages. > > Do we want to add some commentary about the extant SHA1 collisions > when we say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT? > > I’ll note that we define 256 private use ECDHE group code points > but only four such FFDHE group code points. Probably fine, but a > bit surprising. > > Should we forbid duplicate entries in > PreSharedKeyExtension.identities? > > Conversely, we might want to explicitly say that duplicate > OIDFilter.certificate_extension_oid fields should be expected in > OIDFilterExtensions, to enable the case where multiple values must > be present. Or is that supposed to work by concatenating(?) the > multiple values’ DER encodings in the certificate_extension_values > field? > > I’ll call out for Russ’s attention at the end of Section 4.4.3 > where we say that “implementations MUST NOT combine external PSKs > with certificate-based authentication.†Is there any reason not > to qualify that as some sort of “don’t’ do it until it’s definedâ€? > > Should Alert.level be Alert.legacy_level? > > The editors copy has already removed the reference to RFC 4507, > which is obsoleted by RFC 5077 (and was not cited anywhere, anyway). > > Appendix B has a claim that “values listed as _RESERVED were used > in previous versions of TLS and are listed here for completenessâ€, > though that is not exactly true, e.g., for > ContentType.invalid_RESERVED(0) > > Section C.3 notes that “Certificates should always be verified to > ensure proper signing by a trusted Certificate Authorityâ€, which > does not use RFC 2119 language, but might be seen as in conflict > with opportunistic encryption in some circumstances. I don’t > object to this text, but it seems worth mentioning. > > Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel > binding definition that has not yet been defined.]]â€, which should > not make it into the final spec! > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --------------A162052703C229EC80D601D2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 04/11/2017 12:32 PM, Eric Rescorla wrote:
> It was already mentioned that the “major differences from TLS 1.2â€
> section should not be a changelog, but I agree with that.

Yes, this is on my plate.


> Should Figure 4 (“message flow for a zero round trip handshakeâ€)
> include a “+ early_data†for the server’s flight?  (The legend for
> Figure 4 also lacks the explanation for the ‘+’ symbol.)

I see you fixed this.


I guess I didn't consult back with what I had put in this mail when preparing my editorial-changes pull request :)


> The language on page 30 is perhaps unclear:
> 
>    Because TLS 1.3 forbids renegotiation, if a server receives a
>    ClientHello at any other time, it MUST terminate the connection.
> 
> Is that any TLS server, or just one that has negotiated and is using
> TLS 1.3?

The latter. Adjusted.


> In the description of legacy_compression_methods on page 31, we make
> restrictions on “every TLS 1.3 ClientHelloâ€, but do not say how such
> things are identified.  (Hmm, maybe we also do so elsewhere in the
> document, too, now that I search for where) we explicitly define what
> a client “considered to be attempting to negotiate using this
> specification (i.e., a TLS 1.3 ClientHEello) on page 87, as
> supported_versions including 1.3.  Which, is maybe not the most
> future-proof thing.

I think I feel OK about this.


(For the gallery, there were some tweaks in this area in #936)


> The description of version negotiation (to populate
> ServerHello.version) on page 32 seems to leave undefined what the
> server should do when receiving a ClientHello that does not contain a
> supported_versions extension.  (Also, I don’t think
> “ClientHello.supported_versions extension†is a well-defined syntax.)

I think this clear in the section on Supported Versions.


It looks like this changed a little via #936 as well; I'm fine with your followup change there.


> When covering the server_random version downgrade sentinels, we do not
> mention what is to be done when downgrading to TLS 1.0, which I
> thought was still a permitted version by this spec.

Interesting point. I'm trying to remember why we did things this way.
I am tempted to just say "1.1 or 1.0". Thoughts?


That's probably fine; I expect there is some additional attack in there where an attacker could force 1.0 if 1.1 would otherwise have been used, but both of those are not in a great place right now, so we don't need to try too hard to help them out.



> Conversely, we might want to explicitly say that duplicate
> OIDFilter.certificate_extension_oid fields should be expected in
> OIDFilterExtensions, to enable the case where multiple values must be
> present.  Or is that supposed to work by concatenating(?) the multiple
> values’ DER encodings in the certificate_extension_values field?

Yeah, I read this text as saying that those all go in the same
DER, not that there can be multiple copies


Okay.


> I’ll call out for Russ’s attention at the end of Section 4.4.3 where
> we say that “implementations MUST NOT combine external PSKs with
> certificate-based authentication.† Is there any reason not to qualify
> that as some sort of “don’t’ do it until it’s defined�

I'm actually going to move and modify this section per your issue #935.


Yeah, I missed the bits I called out in #935 when I was doing my WGLC review, but the two are related and can be handled together.


> Should Alert.level be Alert.legacy_level?

i think we went over this and decided not to.


There was a pull request from not-me, yes.  Though IIRC it only changed the name locally when describing alerts, and was rejected on the grounds that "we don't use the legacy_level version for this anywhere else in the spec", which is a little bit of circular reasoning.  I'm okay with leaving it as-is.


> Appendix B has a claim that “values listed as _RESERVED were used in
> previous versions of TLS and are listed here for completenessâ€, though
> that is not exactly true, e.g., for ContentType.invalid_RESERVED(0)

I see you fixed this as well.


Well, maybe.  ContentType.invalid is the only one that I marked up in red pen on my paper copy, but I can't certify that I compared the entire list against the IANA registry.  I did look at the extensions registry when preparing #936, though.


> Section C.3 notes that “Certificates should always be verified to
> ensure proper signing by a trusted Certificate Authorityâ€, which does
> not use RFC 2119 language, but might be seen as in conflict with
> opportunistic encryption in some circumstances.  I don’t object to
> this text, but it seems worth mentioning.

I think the "Absent a specific..."



Yeah, I guess I snuck that fix into #936.  So much for keeping things separate...

> Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel binding
> definition that has not yet been defined.]]â€, which should not make it
> into the final spec!

Fixed.


It looks like that was just by removing the note.  Is a channel binding spec for 1.3 still a needed work item, then?

-Ben


On Mon, Mar 27, 2017 at 11:23 PM, Kaduk, Ben <bkaduk@akamai.com> wrote:
On 3/13/17, 12:30, "Sean Turner" <sean@sn3rd.com> wrote:

    This is a working group last call announcement for draft-ietf-tls-tls13-19, to run through March 27.  Please send your reviews to the list as soon as possible so we can prepare for any discussion of open issues at IETF 98 in Chicago.

As the price of running the WGLC right during the meeting lead-up, my review comes in at the last minute.

Generally, it is in good shape.  I think I still owe some text about what we aim for and expect to achieve with respect to side channel resistance, though at this point it may be too late to get that text in :(

The following is basically a laundry list of the minor issues; I will send editorial notes under separate cover, probably as a pull request.

It was already mentioned that the “major differences from TLS 1.2†section should not be a changelog, but I agree with that.

Should Figure 4 (“message flow for a zero round trip handshakeâ€) include a “+ early_data†for the server’s flight?  (The legend for Figure 4 also lacks the explanation for the ‘+’ symbol.)

The language on page 30 is perhaps unclear:

   Because TLS 1.3 forbids renegotiation, if a server receives a
   ClientHello at any other time, it MUST terminate the connection.

Is that any TLS server, or just one that has negotiated and is using TLS 1.3?

In the description of legacy_compression_methods on page 31, we make restrictions on “every TLS 1.3 ClientHelloâ€, but do not say how such things are identified.  (Hmm, maybe we also do so elsewhere in the document, too, now that I search for where)  we explicitly define what a client “considered to be attempting to negotiate using this specification (i.e., a TLS 1.3 ClientHEello) on page 87, as supported_versions including 1.3.  Which, is maybe not the most future-proof thing.

The description of version negotiation (to populate ServerHello.version) on page 32 seems to leave undefined what the server should do when receiving a ClientHello that does not contain a supported_versions extension.  (Also, I don’t think “ClientHello.supported_versions extension†is a well-defined syntax.)

When covering the server_random version downgrade sentinels, we do not mention what is to be done when downgrading to TLS 1.0, which I thought was still a permitted version by this spec.

It’s a little odd that we list in enum ExtensionType on page 35 a strict subset of the extensions enumerated in the table on the following pages.

Do we want to add some commentary about the extant SHA1 collisions when we say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?

I’ll note that we define 256 private use ECDHE group code points but only four such FFDHE group code points.  Probably fine, but a bit surprising.

Should we forbid duplicate entries in PreSharedKeyExtension.identities?

Conversely, we might want to explicitly say that duplicate OIDFilter.certificate_extension_oid fields should be expected in OIDFilterExtensions, to enable the case where multiple values must be present.  Or is that supposed to work by concatenating(?) the multiple values’ DER encodings in the certificate_extension_values field?

I’ll call out for Russ’s attention at the end of Section 4.4.3 where we say that “implementations MUST NOT combine external PSKs with certificate-based authentication.â€Â  Is there any reason not to qualify that as some sort of “don’t’ do it until it’s definedâ€?

Should Alert.level be Alert.legacy_level?

The editors copy has already removed the reference to RFC 4507, which is obsoleted by RFC 5077 (and was not cited anywhere, anyway).

Appendix B has a claim that “values listed as _RESERVED were used in previous versions of TLS and are listed here for completenessâ€, though that is not exactly true, e.g., for ContentType.invalid_RESERVED(0)

Section C.3 notes that “Certificates should always be verified to ensure proper signing by a trusted Certificate Authorityâ€, which does not use RFC 2119 language, but might be seen as in conflict with opportunistic encryption in some circumstances.  I don’t object to this text, but it seems worth mentioning.

Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel binding definition that has not yet been defined.]]â€, which should not make it into the final spec!

-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--------------A162052703C229EC80D601D2-- From nobody Tue Apr 11 11:30:43 2017 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 7B9B5129AC2 for ; Tue, 11 Apr 2017 11:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5b9TltYlNbnm for ; Tue, 11 Apr 2017 11:30:39 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 5690B129548 for ; Tue, 11 Apr 2017 11:30:39 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id 75so2863484lfs.2 for ; Tue, 11 Apr 2017 11:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LUBUj0tQqaTK26ADV7B5MNItNn9PswcxXv9nOnNty+o=; b=ZtQGTprOt+iWqvqp/cPi1yeP2dYOwytzrEa1VYXiimQgrQwl0d+uO4QRYmVIlrsMyK UfXVO/a+OjHuSoKbzakC0ZH1MBShOU75EBQ8E+AK2ls9s18867MN2LbcmhxtXjQy1Kr+ H20/S4hs+8AxI2+sIPgUCQOhY8XUoapNLMBLU6YrFM3CgWNGgU9YQz2BZ9pLZ7LU6WoF mppGRngyvXqXPIwTaFLjKy7wN/b9HZuPc+XITu2jC7cPPdpXkQX6xVCdGTgd73AZQFoU UY1O6AmQaSzm+mibRtCZCAnUmAL5A6QwCstZ5qwoip0eUrgipfyAkUtRPmRQvvusRjQp HtsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LUBUj0tQqaTK26ADV7B5MNItNn9PswcxXv9nOnNty+o=; b=b//VoyBlcyTyphn14ZfFIdJWFCY6pzF9hzI8NwgEGQ7khXSduw/rMYEmQsrKo8V1mO Bc9OAlXiztOAEYiScNCkgGX72K/nKeAWXqBXw0DIMs/TDf7ZoT4hlTGUI7DJADryedkH 5QH8edwNsKlVKy8J3P6lAQqe83GslJuyqj55zO+voR6wDjcNQMmYAN/E0icPM64qTA9E IcLWse+SHq0HgC6Ja0AUMer7WGMmXedb3GlYPI+rb5nJqwjWAjyrYsAGd2FPjphDCv17 UQSgPPcWBFz51SPzmAnnJbGAgFnbh9f4hMRScWsbucmlqhsrZmz01fyfW+UfJYGNjkPb FVrg== X-Gm-Message-State: AFeK/H1oT+h5lqsUwhaqqabfKSUa3yLxjF3/Ev831IzLUfHTlq1tn6uYWGVDbjrvm7qInXDXgQQXEq2vpMG7hA== X-Received: by 10.46.33.135 with SMTP id h7mr17259274lji.96.1491935437619; Tue, 11 Apr 2017 11:30:37 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Tue, 11 Apr 2017 11:30:36 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Tue, 11 Apr 2017 14:30:36 -0400 X-Google-Sender-Auth: ZLSXUNqiKoVLejZEJgMlIIGSN5I Message-ID: To: Joseph Salowey Cc: draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org, "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1142b632c98d9a054ce849b7 Archived-At: Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:30:42 -0000 --001a1142b632c98d9a054ce849b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joe, Thanks for the reminder. I just posted it. Let me know if there is anything I have to do. Yours, Daniel On Tue, Apr 11, 2017 at 11:21 AM, Joseph Salowey wrote: > Hi Daniel, > > Please submit a revised draft with the changes below. > > Thanks, > > Joe > > > On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi, >> >> Thank you for the review and comments received. Given the discussion our >> understanding was that the consensus was to remove CCM-256 so that suite= s >> defined by the document apply both for TLS1.2 as well as for TLS1.3. The >> draft available on github [1 >> ] >> has been updated as follows: >> >> >> 1. Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead >> of SHA384 like the other 256 bit cipher suites? (From Russ Housley) >> >> MGLT: This was a mistake in the IANA section. The cypher suite was >> correct in the remaining text. However, the current version does not >> consider anymore CCM-256* which also solves this issue. >> >> 2. Since the security considerations mention passwords (human chosen >> secrets) it should mention dictionary attacks. (From Russ Housley) >> >> MGLT: The issue of human chosen passwords and dictionary attacks has bee= n >> mentioned in the security consideration with the following text: >> >> """ >> Use of Pre-Shared Keys of limited entropy may allow an active >> attacker attempts to connect to the server and tries different keys. >> For example, limited entropy may be provided by using short PSK in >> which case an attacker may perform a brute-force attack. Other >> example includes the use of a PSK chosen by a human and thus may be >> exposed to dictionary attacks. >> """ >> >> >> 3. Section 2 and 3 of the document contains more detail about TLS 1.3 >> than necessary. >> >> Section 2: This document only defines cipher suites for TLS 1.2, not TLS >> 1.2 or later. A subset of equivalent cipher suites is defined in the TL= S >> 1.3 specification. >> >> MGLT: CCM-256 has been removed from the specification so that suites can >> be defined for TLS 1.2 as well as TLS1.3. The following text is consider= ed. >> >> """ >> This document defines new cipher suites that provide Pre-Shared Key >> (PSK) authentication, Perfect Forward Secrecy (PFS), and >> Authenticated Encryption with Associated Data (AEAD). The cipher >> suites are defined for version 1.2 of the Transport Layer Security >> (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer >> Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS >> [I-D.ietf-tls-tls13]. >> """ >> >> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to >> section 4 that states: >> >> "TLS 1.3 and above name, negotiate and support a subset of these cipher >> suites in a different way." (TLS 1.3 does not support >> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256_CCM >> _8_SHA256) >> >> MGLT: As CCM-256 has been removed, we do not have to deal with the >> situation where TLS1.3 only considers a subset of the suites defined for >> TLS1.2. >> >> The following sentence in section 3 clarifies that codes points are only >> defined for TLS1.2: =E2=80=9C=E2=80=9D=E2=80=9DThe assigned code points = can only be used for TLS >> 1.2.=E2=80=9D=E2=80=9D=E2=80=9D. The description of the TLS1.3 negotiati= on has been limited in >> section 4 to the following sentence: =E2=80=9C=E2=80=9D=E2=80=9DTLS 1.3 = and above version, >> negotiate and support these cipher suites in a different way.=E2=80=9D= =E2=80=9D=E2=80=9D >> >> 4. Section 3 should contain a bit more detail about relationship to 4492 >> bis and RFC 4279: >> >> Something like the following may be enough. >> >> "This messages and pre-master secret construction in this document are >> based on [RFC4279]. The elliptic curve parameters used in in the >> Diffie-Hellman parameters are negotiated using extensions defined in >> [4492-bis]." >> >> MGLT: The sentence mentioned above has been added with [4492-bis] >> mentioned as normative. >> =E2=80=9C=E2=80=9D=E2=80=9D >> Messages and pre-master secret construction in this document are >> based on [RFC4279]. The elliptic curve parameters used in in the >> Diffie-Hellman parameters are negotiated using extensions defined in >> [I-D.ietf-tls-rfc4492bis]. >> =E2=80=9C=E2=80=9D=E2=80=9D >> >> [1] https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/m >> aster/draft-ietf-tls-ecdhe-psk-aead >> >> Yours, >> Daniel and John >> >> >> On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey wrote: >> >>> Here are the open issues for draft-ietf-tls-ecdhe-psk-aead >>> >>> 1. Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead >>> of SHA384 like the other 256 bit cipher suites? (From Russ Housley) >>> >>> 2. Since the security considerations mention passwords (human chosen >>> secrets) it should mention dictionary attacks. (From Russ Housley) >>> >>> 3. Section 2 and 3 of the document contains more detail about TLS 1.3 >>> than necessary. >>> >>> Section 2: This document only defines cipher suites for TLS 1.2, not TL= S >>> 1.2 or later. A subset of equivalent cipher suites is defined in the T= LS >>> 1.3 specification. >>> >>> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition t= o >>> section 4 that states: >>> >>> "TLS 1.3 and above name, negotiate and support a subset of these cipher >>> suites in a different way." (TLS 1.3 does not support >>> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256 >>> _CCM_8_SHA256) >>> >>> 4. Section 3 should contain a bit more detail about relationship to 449= 2 >>> bis and RFC 4279: >>> >>> Something like the following may be enough. >>> >>> "This messages and pre-master secret construction in this document are >>> based on [RFC4279]. The elliptic curve parameters used in in the >>> Diffie-Hellman parameters are negotiated using extensions defined in >>> [4492-bis]." >>> >>> Thanks, >>> >>> Joe >>> >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1142b632c98d9a054ce849b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

Thanks for the reminder. I just = posted it. Let me know if there is anything I have to do.

You= rs,
Daniel

On Tue, Apr 11, 2017 at 11:21 AM, Joseph Salowey <joe@salowey.n= et> wrote:
Hi Daniel,

Please submit a revised draft with the chang= es below.

Thanks,

Joe


On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault &l= t;daniel.m= igault@ericsson.com> wrote:
Hi,

Thank you for the review and comment= s received. Given the discussion our understanding was that the consensus w= as to remove CCM-256 so that suites defined by the document apply both for = TLS1.2 as well as for TLS1.3. The draft available on github [1]=C2=A0 has been updated as follo= ws:=C2=A0


1.=C2=A0 Why does TLS_ECDHE_PSK_WITH_AES_256_CC= M_8_SHA256 use SHA256 instead of SHA384 like the other 256 bit cipher = suites? (From Russ Housley)

MGLT: This was a mistake in the I= ANA section. The cypher suite was correct in the remaining text. However, t= he current version does not=C2=A0 consider anymore CCM-256* which also solv= es this issue.
=C2=A0
2.=C2=A0 Since the security consideration= s mention passwords (human chosen secrets) it should mention dictionary att= acks. (From Russ Housley)
=C2=A0
MGLT: The issue of human chos= en passwords and dictionary attacks has been mentioned in the security cons= ideration with the following text:

"""
=C2=A0=C2= =A0 Use of Pre-Shared Keys of limited entropy may allow an active
=C2=A0= =C2=A0 attacker attempts to connect to the server and tries different keys.=
=C2=A0=C2=A0 For example, limited entropy may be provided by using shor= t PSK in
=C2=A0=C2=A0 which case an attacker may perform a brute-force a= ttack.=C2=A0 Other
=C2=A0=C2=A0 example includes the use of a PSK chosen= by a human and thus may be
=C2=A0=C2=A0 exposed to dictionary attacks.<= span>
"""

=C2=A0
3.=C2=A0 Section 2 and 3 of t= he document contains more detail about TLS 1.3 than necessary.=C2=A0
= =C2=A0
Section 2: This document only defines cipher suites for TLS 1.2, = not TLS 1.2 or later.=C2=A0 A subset of equivalent cipher suites is defined= in the TLS 1.3 specification.=C2=A0
=C2=A0
MGLT: CCM-256 has= been removed from the specification so that suites can be defined for TLS = 1.2 as well as TLS1.3. The following text is considered.

"&quo= t;"
=C2=A0=C2=A0 This document defines new cipher suites that prov= ide Pre-Shared Key
=C2=A0=C2=A0 (PSK) authentication, Perfect Forward Se= crecy (PFS), and
=C2=A0=C2=A0 Authenticated Encryption with Associated D= ata (AEAD).=C2=A0 The cipher
=C2=A0=C2=A0 suites are defined for version= 1.2 of the Transport Layer Security
=C2=A0=C2=A0 (TLS) [RFC5246] protoc= ol, version 1.2 of the Datagram Transport Layer
=C2=A0=C2=A0 Security (D= TLS) protocol [RFC6347], as well as version 1.3 of TLS
=C2=A0=C2=A0 [I-D= .ietf-tls-tls13].
"""
=C2=A0
Section 3 and 4:= Maybe replace the last 2 paragraphs with an addition to section 4 that sta= tes:
=C2=A0
"TLS 1.3 and above name, negotiate and support a sub= set of these cipher suites in a different way."=C2=A0 (TLS 1.3 does no= t support TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH= _AES_256_CCM_8_SHA256)
=C2=A0
MGLT: As CCM-256 has been r= emoved, we do not have to deal with the situation where TLS1.3 only conside= rs a subset of the suites defined for TLS1.2.

The following sentenc= e in section 3 clarifies that codes points are only defined for TLS1.2: =E2= =80=9C=E2=80=9D=E2=80=9DThe assigned code points can only be used for TLS 1= .2.=E2=80=9D=E2=80=9D=E2=80=9D. The description of the TLS1.3 negotiation h= as been limited in section 4 to the following sentence: =E2=80=9C=E2=80=9D= =E2=80=9DTLS 1.3 and above version, negotiate and support these cipher suit= es in a different way.=E2=80=9D=E2=80=9D=E2=80=9D
=C2=A0
4. Sec= tion 3 should contain a bit more detail about relationship to 4492 bis and = RFC 4279:
=C2=A0
Something like the following may be enough.=C2=A0
"This messages and pre-master secret construction in this docume= nt are based on [RFC4279].=C2=A0 The elliptic curve parameters used in in t= he Diffie-Hellman parameters are negotiated using extensions defined in [44= 92-bis]."
=C2=A0
MGLT: The sentence mentioned above has b= een added with [4492-bis] mentioned as normative.
=E2=80=9C=E2=80=9D=E2= =80=9D
=C2=A0=C2=A0=C2=A0 Messages and pre-master secret construction in= this document are
=C2=A0=C2=A0 based on [RFC4279].=C2=A0 The elli= ptic curve parameters used in in the
=C2=A0=C2=A0 Diffie-Hellman paramet= ers are negotiated using extensions defined in
=C2=A0=C2=A0 [I-D.= ietf-tls-rfc4492bis].
=E2=80=9C=E2=80=9D=E2=80=9D

[1] https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/master/draft-ietf-tls-ecdhe-psk-aea= d

Yours,
Daniel and John


On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey <joe@sa= lowey.net> wrote:
Here are the open issues for=C2=A0draft-ietf-tls-ecdhe-psk-ae= ad

1.=C2=A0 Why does=C2=A0TLS_ECDHE_PSK_WITH_AES_256_= CCM_8_SHA256 use SHA256 instead of SHA384 like the other 256 bit cipher sui= tes? (From Russ Housley)
=
2.=C2=A0 Since the security considerations mention pa= sswords (human chosen secrets) it should mention dictionary attacks. (From = Russ Housley)

3.=C2=A0 Section 2 and 3 of the docu= ment contains more detail about TLS 1.3 than necessary. =C2=A0
Section 2: This document only defines cipher suites for TLS 1.= 2, not TLS 1.2 or later.=C2=A0 A subset of equivalent cipher suites is defi= ned in the TLS 1.3 specification. =C2=A0

Section 3= and 4: Maybe replace the last 2 paragraphs with an addition to section 4 t= hat states:

"TLS 1.3 and above name, negotiat= e and support a subset of these cipher suites in a different way." =C2= =A0(TLS 1.3 does not support=C2=A0TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and=C2=A0TLS_ECDHE_PSK_WITH_AES_256= _CCM_8_SHA256)

4. Section 3 should= contain a bit more detail about relationship to 4492 bis and RFC 4279:

Something like the following may be enough. =C2=A0

"This messages and pre-master secret construction in this docum= ent are based on [RFC4279].=C2=A0 The elliptic curve parameters used in in = the Diffie-Hellman parameters are negotiated using extensions defined in [4= 492-bis]."

<= /span>
Thanks,
=
Joe




_______________________________________________<= br> TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls




_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a1142b632c98d9a054ce849b7-- From nobody Tue Apr 11 11:45:53 2017 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 2E5A712EC14 for ; Tue, 11 Apr 2017 11:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham 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 B57biQFUnTu8 for ; Tue, 11 Apr 2017 11:45:49 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 6E9BB12EC1C for ; Tue, 11 Apr 2017 11:45:48 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id j9so2651605ywj.3 for ; Tue, 11 Apr 2017 11:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SNGhUpbmPDu+/p42fTQ5e4h6NO13T0byoh9l1XUfExY=; b=jW2ux08m6NPqZR/6zmEIW4Qz4FF/TFdhKr7nUSVdbpoMj7tWfnTW0EabQk/7GTC00h H6cPNXj0A/uvIbMX6CHjaIlZWuuOZzEt0OCjLcdW/ZuiwA4mGwuEkXGD/AZt6ByrL2q+ eabNwpMfp2wUCJWReXxkIFnXD/KvWczdJXfyxefIOCjbe5DW3gH4uND/t1pYiKYGx2yx 8D7ZRuAa+RE1ZJsvpiy4tYPnzKldonarhvU0eLsiU7P0MZgNwud56ic7iLVyQFeZKgsh Io53PNRTt8MjtyinNjQcbGw08srYbwXO1sj/GUpiubdexFsICnJ0PKGwanvsjoQE9QFs JD4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SNGhUpbmPDu+/p42fTQ5e4h6NO13T0byoh9l1XUfExY=; b=p5b0T6p2H3s1Je53xZ7B1pBZ1dvgMZHGafzUYLHgmqEFZ+08E6kn5zYcl8XDCKE3Pc FlpOv9XtZ6SqFsSEow5IHm6hBCYn7wiDHqlc9inTiOOTmWGyx3PW0agdzkvaWlkQtsKM N91wzHYhXsUoTNOewgF64xiMWn+bxTNz6dV/lf3Qgl4+BfZ+WLgwfNiO+1nyT620kksy V1CZhv8gFFCu8HnUUn0EA3GZ1i7KPzqbHqqbcVpbrctfy3/voMSncWuQCkGMMq666GH1 JDJ8JgUTxdxMxTcWY5LNqWfx75Ugd9HhrmdvM/9Js1k+nD1R8slgl6cityYAm3kQC4Lg w4vA== X-Gm-Message-State: AN3rC/6CYSR/3rVHd22xI1MjDQYMpMQsXh6EJkrrudVtzbZOcA6W9dP+zN1ITTlnd9odmiRjFeeQli3rBUE9Cw== X-Received: by 10.129.76.85 with SMTP id z82mr6713857ywa.87.1491936347552; Tue, 11 Apr 2017 11:45:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 11 Apr 2017 11:45:07 -0700 (PDT) In-Reply-To: <43ce161a-a107-5491-71e0-d6fecd9665a6@akamai.com> References: <025D3ABD-199F-421A-9265-6F960135A3B7@sn3rd.com> <228B1CCF-088B-4F4C-B2FD-A20036B9224A@akamai.com> <43ce161a-a107-5491-71e0-d6fecd9665a6@akamai.com> From: Eric Rescorla Date: Tue, 11 Apr 2017 11:45:07 -0700 Message-ID: To: Benjamin Kaduk Cc: Sean Turner , "" Content-Type: multipart/alternative; boundary=001a113f238e060fb6054ce8805f Archived-At: Subject: Re: [TLS] WGLC: draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 18:45:52 -0000 --001a113f238e060fb6054ce8805f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 11, 2017 at 11:27 AM, Benjamin Kaduk wrote: > > Yeah, I guess I snuck that fix into #936. So much for keeping things > separate... > > > Page 113 still has the =E2=80=9C[[NOTE: TLS 1.3 needs a new channel bin= ding > > definition that has not yet been defined.]]=E2=80=9D, which should not = make it > > into the final spec! > > Fixed. > > > It looks like that was just by removing the note. Is a channel binding > spec for 1.3 still a needed work item, then > Yeah, I think so. -Ekr > > -Ben > > > > On Mon, Mar 27, 2017 at 11:23 PM, Kaduk, Ben wrote: > >> On 3/13/17, 12:30, "Sean Turner" wrote: >> >> This is a working group last call announcement for >> draft-ietf-tls-tls13-19, to run through March 27. Please send your revi= ews >> to the list as soon as possible so we can prepare for any discussion of >> open issues at IETF 98 in Chicago. >> >> As the price of running the WGLC right during the meeting lead-up, my >> review comes in at the last minute. >> >> Generally, it is in good shape. I think I still owe some text about wha= t >> we aim for and expect to achieve with respect to side channel resistance= , >> though at this point it may be too late to get that text in :( >> >> The following is basically a laundry list of the minor issues; I will >> send editorial notes under separate cover, probably as a pull request. >> >> It was already mentioned that the =E2=80=9Cmajor differences from TLS 1.= 2=E2=80=9D >> section should not be a changelog, but I agree with that. >> >> Should Figure 4 (=E2=80=9Cmessage flow for a zero round trip handshake= =E2=80=9D) include >> a =E2=80=9C+ early_data=E2=80=9D for the server=E2=80=99s flight? (The = legend for Figure 4 also >> lacks the explanation for the =E2=80=98+=E2=80=99 symbol.) >> >> The language on page 30 is perhaps unclear: >> >> Because TLS 1.3 forbids renegotiation, if a server receives a >> ClientHello at any other time, it MUST terminate the connection. >> >> Is that any TLS server, or just one that has negotiated and is using TLS >> 1.3? >> >> In the description of legacy_compression_methods on page 31, we make >> restrictions on =E2=80=9Cevery TLS 1.3 ClientHello=E2=80=9D, but do not = say how such things >> are identified. (Hmm, maybe we also do so elsewhere in the document, to= o, >> now that I search for where) we explicitly define what a client >> =E2=80=9Cconsidered to be attempting to negotiate using this specificati= on (i.e., a >> TLS 1.3 ClientHEello) on page 87, as supported_versions including 1.3. >> Which, is maybe not the most future-proof thing. >> >> The description of version negotiation (to populate ServerHello.version) >> on page 32 seems to leave undefined what the server should do when >> receiving a ClientHello that does not contain a supported_versions >> extension. (Also, I don=E2=80=99t think =E2=80=9CClientHello.supported_= versions >> extension=E2=80=9D is a well-defined syntax.) >> >> When covering the server_random version downgrade sentinels, we do not >> mention what is to be done when downgrading to TLS 1.0, which I thought = was >> still a permitted version by this spec. >> >> It=E2=80=99s a little odd that we list in enum ExtensionType on page 35 = a strict >> subset of the extensions enumerated in the table on the following pages. >> >> Do we want to add some commentary about the extant SHA1 collisions when >> we say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT? >> >> I=E2=80=99ll note that we define 256 private use ECDHE group code points= but only >> four such FFDHE group code points. Probably fine, but a bit surprising. >> >> Should we forbid duplicate entries in PreSharedKeyExtension.identities? >> >> Conversely, we might want to explicitly say that duplicate >> OIDFilter.certificate_extension_oid fields should be expected in >> OIDFilterExtensions, to enable the case where multiple values must be >> present. Or is that supposed to work by concatenating(?) the multiple >> values=E2=80=99 DER encodings in the certificate_extension_values field? >> >> I=E2=80=99ll call out for Russ=E2=80=99s attention at the end of Section= 4.4.3 where we >> say that =E2=80=9Cimplementations MUST NOT combine external PSKs with >> certificate-based authentication.=E2=80=9D Is there any reason not to q= ualify that >> as some sort of =E2=80=9Cdon=E2=80=99t=E2=80=99 do it until it=E2=80=99s= defined=E2=80=9D? >> >> Should Alert.level be Alert.legacy_level? >> >> The editors copy has already removed the reference to RFC 4507, which is >> obsoleted by RFC 5077 (and was not cited anywhere, anyway). >> >> Appendix B has a claim that =E2=80=9Cvalues listed as _RESERVED were use= d in >> previous versions of TLS and are listed here for completeness=E2=80=9D, = though that >> is not exactly true, e.g., for ContentType.invalid_RESERVED(0) >> >> Section C.3 notes that =E2=80=9CCertificates should always be verified t= o ensure >> proper signing by a trusted Certificate Authority=E2=80=9D, which does n= ot use RFC >> 2119 language, but might be seen as in conflict with opportunistic >> encryption in some circumstances. I don=E2=80=99t object to this text, = but it >> seems worth mentioning. >> >> Page 113 still has the =E2=80=9C[[NOTE: TLS 1.3 needs a new channel bind= ing >> definition that has not yet been defined.]]=E2=80=9D, which should not m= ake it into >> the final spec! >> >> -Ben >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > > --001a113f238e060fb6054ce8805f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 11, 2017 at 11:27 AM, Benjamin Kaduk <= bkaduk@akamai.com> wrote:
Yeah, I guess I snuck that fix into #936.=C2=A0 So much for keeping things separate...

> Page 113 still has the =E2=80=9C[[NOTE: TLS 1.3 needs a n= ew channel binding
> definition that has not yet been defined.]]=E2=80=9D, whi= ch should not make it
> into the final spec!

Fixed.


 It looks like that was just by removing the note.=C2=A0 Is a channel binding spec for 1.3 still a needed work item, then
<= div>

=C2=A0

-Ben



On Mon, Mar 27, 2017 at 11:23 PM, Kaduk, Ben <bkaduk@akamai.com> wrote:
On 3/13/17, 12:30, "Sea= n Turner" <sean= @sn3rd.com> wrote:

=C2=A0 =C2=A0 This is a working group last call announcement = for draft-ietf-tls-tls13-19, to run through March 27.=C2=A0 Pleas= e send your reviews to the list as soon as possible so we can prepare for any discussion of open issues at IETF 98 in Chicago.

As the price of running the WGLC right during the meeting lead-up, my review comes in at the last minute.

Generally, it is in good shape.=C2=A0 I think I still owe some text about what we aim for and expect to achieve with respect to side channel resistance, though at this point it may be too late to get that text in :(

The following is basically a laundry list of the minor issues; I will send editorial notes under separate cover, probably as a pull request.

It was already mentioned that the =E2=80=9Cmajor differences fr= om TLS 1.2=E2=80=9D section should not be a changelog, but I agree= with that.

Should Figure 4 (=E2=80=9Cmessage flow for a zero round trip handshake=E2=80=9D) include a =E2=80=9C+ early_data=E2=80=9D fo= r the server=E2=80=99s flight?=C2=A0 (The legend for Figure 4 also lacks the explanati= on for the =E2=80=98+=E2=80=99 symbol.)

The language on page 30 is perhaps unclear:

=C2=A0 =C2=A0Because TLS 1.3 forbids renegotiation, if a server receives a
=C2=A0 =C2=A0ClientHello at any other time, it MUST terminate t= he connection.

Is that any TLS server, or just one that has negotiated and is using TLS 1.3?

In the description of legacy_compression_methods on page 31, we make restrictions on =E2=80=9Cevery TLS 1.3 ClientHello=E2= =80=9D, but do not say how such things are identified.=C2=A0 (Hmm, maybe we al= so do so elsewhere in the document, too, now that I search for where)=C2=A0 we explicitly define what a client =E2=80=9Cconsid= ered to be attempting to negotiate using this specification (i.e., a TLS 1.3 ClientHEello) on page 87, as supported_versions including 1.3.=C2=A0 Which, is maybe not the most future-proof thing.

The description of version negotiation (to populate ServerHello.version) on page 32 seems to leave undefined what the server should do when receiving a ClientHello that does not contain a supported_versions extension.=C2=A0 (Also, I don=E2=80=99t think =E2=80=9CClientHello.supported_version= s extension=E2=80=9D is a well-defined syntax.)

When covering the server_random version downgrade sentinels, we do not mention what is to be done when downgrading to TLS 1.0, which I thought was still a permitted version by this spec.

It=E2=80=99s a little odd that we list in enum ExtensionType on= page 35 a strict subset of the extensions enumerated in the table on the following pages.

Do we want to add some commentary about the extant SHA1 collisions when we say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?

I=E2=80=99ll note that we define 256 private use ECDHE group co= de points but only four such FFDHE group code points.=C2=A0 Probab= ly fine, but a bit surprising.

Should we forbid duplicate entries in PreSharedKeyExtension.ide= ntities?

Conversely, we might want to explicitly say that duplicate OIDFilter.certificate_extension_oid fields should be expected in OIDFilterExtensions, to enable the case where multiple values must be present.=C2=A0 Or is that supposed to work by concatenating(?) the multiple values=E2=80=99 DER encod= ings in the certificate_extension_values field?

I=E2=80=99ll call out for Russ=E2=80=99s attention at the end o= f Section 4.4.3 where we say that =E2=80=9Cimplementations MUST NOT combi= ne external PSKs with certificate-based authentication.=E2=80=9D= =C2=A0 Is there any reason not to qualify that as some sort of =E2=80=9Cd= on=E2=80=99t=E2=80=99 do it until it=E2=80=99s defined=E2=80=9D?

Should Alert.level be Alert.legacy_level?

The editors copy has already removed the reference to RFC 4507, which is obsoleted by RFC 5077 (and was not cited anywhere, anyway).

Appendix B has a claim that =E2=80=9Cvalues listed as _RESERVED= were used in previous versions of TLS and are listed here for completeness=E2=80=9D, though that is not exactly true, e.g., f= or ContentType.invalid_RESERVED(0)

Section C.3 notes that =E2=80=9CCertificates should always be verified to ensure proper signing by a trusted Certificate Authority=E2=80=9D, which does not use RFC 2119 language, but m= ight be seen as in conflict with opportunistic encryption in some circumstances.=C2=A0 I don=E2=80=99t object to this text, but i= t seems worth mentioning.

Page 113 still has the =E2=80=9C[[NOTE: TLS 1.3 needs a new cha= nnel binding definition that has not yet been defined.]]=E2=80=9D, w= hich should not make it into the final spec!

-Ben

_______________________________________________
TLS mailing list
TLS@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tls



--001a113f238e060fb6054ce8805f-- From nobody Tue Apr 11 13:48:04 2017 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 E58CD129AC5 for ; Tue, 11 Apr 2017 13:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham 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 2EW4b8CYdbj3 for ; Tue, 11 Apr 2017 13:47:50 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 C7D5F129A9F for ; Tue, 11 Apr 2017 13:47:49 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id k13so4047732ywk.1 for ; Tue, 11 Apr 2017 13:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=78MXOqO9vpFKYpBAINSCorC0pOEE8uU5YdZAEs3VGRg=; b=Y1hM+/aQ7GLbCuuOC3w+qQrN6tn7qPNxRQc7dSgbgtBFISb9438Xv/t2n5jbz4ljY0 oeZEXzuWp9IrVliu+neC3XrIjjDyHMhkBAdkzHWRoCcmCK3iEn4B770ZRJaH8x7+53rg wT8+dAaX5tzjLSpxQXbWRmPPl/WhTO6SuENhGlDrtOLv1etQL7cWTPpJEhZVLI4c2Zsn GJMIiZIMdsN5emfuUZu2qcQpuakkqcCp9tng1Nk4W7MwleM8eRDTTNeV4yjS1BjwYFXk gfbKYyIGxOhDsUVgRCjE5roiECdaYMKbXFSzpXYUZRAy7FBEQLv6AKUA4X+VaMih2/w9 4ihg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=78MXOqO9vpFKYpBAINSCorC0pOEE8uU5YdZAEs3VGRg=; b=JSnXyXSZNhHkpcX6wA2FV00hCfK43H8tpZ+1yRiXYMDAajGr2T/aHlCAfdrnEgcaNp 136e5BmxJPBMckMcJoTeFl/zgvJfMNF3GtyvxUWYfj6R5SYIrgjSKLWBbNhEK5EMJDt9 XXTOmT+bj85MfsxT7AswUQCihmlptt0/NyouHYwPp05GDQBAxv+WafIi/6vhBcu5DiG2 jspDewX6p7dmxC33QjbRP5HRA9dI8jdXLqSKJqWDrIRQj14WIVh2dwu8uebR9z8Df9vI 8KTujyQf8zMsg9jGg4AfPE82RnzFGqp2l/qNKNOyzECmzq15VvKiNOfvy32VyVvQ5vW2 mjFQ== X-Gm-Message-State: AN3rC/5sRFGW1EYeC041jmmLawb+hjdxr5+Rs6sWKFi/pr0QtemAfpawxwzIrDFysRdARtjzzvMT/SJcZeP+JQ== X-Received: by 10.129.182.65 with SMTP id h1mr7486366ywk.337.1491943668642; Tue, 11 Apr 2017 13:47:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 11 Apr 2017 13:47:08 -0700 (PDT) In-Reply-To: <1490797957.28079.20.camel@redhat.com> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> From: Eric Rescorla Date: Tue, 11 Apr 2017 13:47:08 -0700 Message-ID: To: Nikos Mavrogiannopoulos Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1bde9c651056054cea3434 Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 20:47:54 -0000 --94eb2c1bde9c651056054cea3434 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your comments. > 1.2. Major Differences from TLS 1.2 > It is very hard to make use of this section as is. It is organized on > per-draft, while it would be expected to have the changes of the > document since TLS 1.2. It contains phrases like "Remove spurious > requirement to implement "pre_shared_key"." At its current state it is > not useful to someone familiar with TLS 1.2. Yes, I agree. This is an action item for me. > 2. Figure 1 ascii art is a bit awkward (IMHO). "Key Exch" looks like > bad shortening. Symbols '^' and 'v' were confusing on the first read. > A suggestion could be to avoid ^v, and define shortened terminology > upfront and use it on the figures. > > One the content, Figure 1 contents are too many to swallow at an > overview. A suggestion would be to split into two diagrams (preshared > keys and not). I agree that this is a bit hard to take in, but I'd like to have a unified diagram. I'll see what I can do about the shortening. > A more general note on the section/document, is that although the PKIX > identity (certificate) is protected from passive adversaries, the PSK > identity is not. This is a discrepancy in terms of protecting the > user's identity between PSK and certificate authentication (that should > warrant . I agree. I will mention this. > 4.1.1. HelloRetryRequest how many times can it be re-sent by the > server? I assume only a single one, but it maybe good to make it > explicit. This is forbidden in S 4.1.4. https://tlswg.github.io/tls13-spec/#hello-retry-request If a client receives a second HelloRetryRequest in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest), it MUST abort the handshake with an =E2=80=9Cunexpected_message=E2=80=9D alert. Does this seem sufficient? > 4.1.2. It is not defined what a server should do if encountered with a > ProtocolVersion of TLS 1.3. https://tlswg.github.io/tls13-spec/#supported-versions says: If this extension is not present, servers which are compliant with this specification MUST negotiate TLS 1.2 or prior as specified in [RFC5246], even if ClientHello.legacy_version is 0x0304 or later. Servers MAY abort the handshake upon receiving a ClientHello with legacy_version 0x0304 or later. > 4.2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066 > status request. Why not require RFC6961? Because TLS 1.3 allows you to attach OSCP-stapled responses to each certificate with status_request, we felt that 6961 was superseded. > 4.2. the exception for including cookie in HelloRetryRequest seems like > something that could cause issues in future revisions. Any future > revision of the protocol would not be able to add such exceptions > (since they will be rejected by existing clients), and the fact that > the cookie is there, it indicates that such an exception may be useful. > A suggestion to address that would be to allow the HelloRetryRequest > contain any extension or grant an exception to a specific extension > number range. Yes, this is an interesting suggestion. I have filed issue: https://github.com/tlswg/tls13-spec/issues/939 However, as David Benjamin points out, it's not clear how one would handle this in practice, because HRR is an instruction to the client to do something, so if it can't parse that then the handshake fails. > 4.2.5.2. The parameters are informally defined. > I'd suggest to follow rfc4492bis and use its text as in: > https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-16#section-5.4.1 Good idea. https://github.com/tlswg/tls13-spec/issues/943 > 4.2.7. There is no guidance on the use of max_early_data_size. > I'd find it natural to have a recommended minimum value for application > protocols layered on TLS to take into account. E.g., text like servers > supporting early_data SHOULD allow at least 1024 bytes of data > (arbitrary number). Is the 32-bit upper limit intentional? I think it's just a result of the way the PDU is formatted. I would be interested in seeing a PR with guidance... > 4.2.8. This section changes the semantics for pre-shared keys as used > in any other protocol (including TLS 1.2). With the new text it > implies, pre-shared keys must be combined with a hash algorithm. Thus > existing PSK deployments which share keys and would like to upgrade to > TLS 1.3 cannot do transparently. They would have to fix to a specific > hash algorithm for their existing PSKs, and make sure they provide that > information to all the underlying software (which may be different on > the server and client side). I could find no implementation guideline > on what to do in the case of pre-existing PSKs in that text. > > My recommendation would be to switch the sentence "For externally > established PSKs, the Hash algorithm MUST be set when the PSK is > established" to "For externally established PSKs, the Hash algorithm > MUST be set when the PSK is established, or default to SHA-256". That > way implementations can cope transparently with an upgrade to TLS 1.3 > for already present PSK keys without requiring an additional RFC > describing that. This seems like a good change. I have made it. > 4.2.8. The overlap of the namespace for usernames to be used in PSK > authentication, and the namespace for "resumption" does not give a good > feeling. Yeah, I can see that perspective. That's part of why we domain separate in the implementation. > 4.2.8. Related to the above, it is unclear what obfuscated_ticket_age > should contain when using PSK authentication (but not resumption). https://tlswg.github.io/tls13-spec/#pre-shared-key-extension: For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. > 4.2.8.1. It is not defined what the binder should contain when using > PSK authentication (but not resumption). It's intended to be the same (modulo the domain separation in the label). > 4.2.8.1. If a single binder corresponds to a single identity, the > parsing and mapping of binders in the PreSharedKeyExtension seems > unnecessarily complicated. A suggestion is to move the binder inside > each identity structure: > struct { > opaque identity<1..2^16-1>; > uint32 obfuscated_ticket_age; > opaque PskBinderEntry<32..255>; > } PskIdentity; I did consider that, but it's not possible because you want the binders to cover the other key identities so that it's not possible to remove one without detection (unless you reject PSK entirely, in which case this is detected in the Finished). > 4.2.8.3. I believe that section can benefit from some improvements. > >From a first read it is not clear what this section wants to protect > from. It provides some checks, but it is unclear to me what these > protect from. > > Some more concrete comments on the same section: > It mentions "see if the value used by the client matches its > expectations". A question that arises, is what is the recommended > expectation for a server? Given the text in 4.2.8 that should be a > week, but the text in 4.2.8 seems to imply that the restriction is > defined somewhere else, and I would have expected it to be here. > > The text recommends: "a server SHOULD measure the round trip time prior > to sending the NewSessionTicket message". I see two issues here. (1) it > doesn't mention how to do this measurement --my guess is that this can > be done in the context of TLS--, and (2) it assumes that round-trips > are fixed over time. About (1), I ask because the obvious measurement > time between [server Application Data*] and client [Certificate*] would > include the processing of the application data by the client. > On (2), this check will not work as is for mobile clients which will > have variable round-trips. > > The check 'ticket age must be shorter than elapsed time by a round- > trip', is unclear to me what it intends to protect from. > > A clarification: "the actual time elapsed on the server", elapsed since > when? (I guess since the first message was received). Thanks. I will try to clean this up. I have filed > 4.3.2.1. The OID Filters extension on a first look seems quite > independent and unrelated to everything else in this document (seemed > quite a distraction that could have been in an appendix as well). This is a fair point, but it's been in the document a long time, so I think this would require WG Consensus. > 4.4.2.1. OCSP Status and SCT Extensions > This is a very nice addition to TLS 1.3. Something that I miss as an > implementer is guidelines on how to determine the (time) validity of an > OCSP stapled response. Here my point is that OCSP responses have > several fields optional (e.g., nextUpdate), which make a validation to > be hand-wavy. It would be nice to have a profile of OCSP responses that > would be recommended for use in TLS, as well or a recommendation of > what constitutes a "fresh" response for use in TLS. Do you have any thoughts on what text we should insert here? I admit to being not that familiar with the practical matters of OCSP stapling. > 4.4.2.2., 4.4.2.3. > I think the reference to RFC5081 should be replaced with RFC5270 which > obsoletes the former even though not explicitly. Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion in Chicago. > 4.4.3. "RSA signatures MUST use an RSASSA-PSS algorithm". What should a > client or server do when encounters an non RSA-PSS signature in TLS > 4.6.3. My comment on this section, is that leaving up to the > implementer to decide the re-key, would most probably result in the > implementer delegating that decision to the application. In my > experience that would mean no re-key in practice for the majority of > applications. I'd have preferred a one-size fits all approach, where > re-key is done on decided points. I can understand that, but we did litigate this extensively, so I think any change would require WG consensus at this point. > 5.1. I miss a maximum number of alerts received per session, or some > other alert limiting mechanism (having CVE-2016-8610 in mind). All alerts now result in connection termination, so the limit seems to implicitly be 1. > 7.5. There is no definition of early_exporter_secret, and it is unclear > why it is even mentioned. In short how is this supposed to be used, and > why should implementations consider adding an interface to it? It is defined in: https://tlswg.github.io/tls13-spec/#key-schedule I added some text to explain why you would want it. > A. Is the described state machine intended to be normative or > informative? I.e., which takes precedence, this description or the text > above? (would be nice to clarify) They are intended to be consistent. I wiould appreciate WG feedback on this point. > B.4. > I believe it was discussed before, but I miss the AES-256-CCM > ciphersuites. If only one must be defined, it may be better to only > have the 256-bit variants (at least for the non-mac-truncated version) Open to WG feedback here as well. > E. I'd find it natural for this to be the security considerations > rather than an appendix. > > > G. Quite a long list. Would be nice to have the contributors to TLS 1.3 > separately. I'd rather not try to draw this distinction in acknowledgements. My feeling is that people have been doing good work on this back to SSLv3. I will, however, try to typeset it into two columns. > Bibliography: There are references to PKCS6 and PKCS7 that are never > used throughout the text (I guess there are more). Thanks. We will fix this pre-publication. -Ekr On Wed, Mar 29, 2017 at 7:32 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2017-03-29 at 16:28 +0200, Nikos Mavrogiannopoulos wrote: > > > A more general note on the section/document, is that although the > > PKIX > > identity (certificate) is protected from passive adversaries, the PSK > > identity is not. This is a discrepancy in terms of protecting the > > user's identity between PSK and certificate authentication (that > > should > > warrant . > > ... an entry in the security considerations. > > > 4.2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066 > > status request. Why not require RFC6961? > > Please ignore that. I forgot to delete in my draft. > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1bde9c651056054cea3434 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your comments.

> 1.2. Major Differences from TLS 1.2
> =C2=A0= It is very hard to make use of this section as is. It is organized on
=
> per-draft, while it would be expected to have the changes of the<= /div>
> document since TLS 1.2. It contains phrases like "Remov= e spurious
> requirement to implement "pre_shared_key&quo= t;." At its current state it is
> not useful to someone f= amiliar with TLS 1.2.

Yes, I agree. This is an act= ion item for me.



>= ; 2. Figure 1 ascii art is a bit awkward (IMHO). "Key Exch" looks= like
> bad shortening. Symbols '^' and 'v' we= re confusing on the first read.
> A suggestion could be to avo= id ^v, and define shortened terminology
> upfront and use it o= n the figures.
>=C2=A0
> One the content, Figure = 1 contents are too many to swallow at an
> overview. A suggest= ion would be to split into two diagrams (preshared
> keys and = not).

I agree that this is a bit hard to take in, = but I'd like to have
a unified diagram. I'll see what I c= an do about the shortening.


> A = more general note on the section/document, is that although the PKIX
<= div>> identity (certificate) is protected from passive adversaries, the = PSK
> identity is not. This is a discrepancy in terms of prote= cting the
> user's identity between PSK and certificate au= thentication (that should
> warrant .

I agree. I will mention this.


>= 4.1.1. HelloRetryRequest how many times can it be re-sent by the
> server? I assume only a single one, but it maybe good to make it
> explicit.

This is forbidden in S 4.1.4.=
<= br>
=C2=A0 =C2=A0If a client receives a second HelloRetryRequest = in the same
=C2=A0 =C2=A0connection (i.e., where the ClientHello = was itself in response to a
=C2=A0 =C2=A0HelloRetryRequest), it M= UST abort the handshake with an
=C2=A0 =C2=A0=E2=80=9Cunexpected_= message=E2=80=9D alert.
=C2=A0 =C2=A0
Does this seem su= fficient?




=

> 4.1.2. It is not defined what a server should do i= f encountered with a
> ProtocolVersion of TLS 1.3.
<= br>
https://tlswg.github.io/tls13-spec/#supported-versions says:

=C2=A0 =C2=A0If this extension is not present, servers= which are compliant with
=C2=A0 =C2=A0this specification MUST ne= gotiate TLS 1.2 or prior as specified in
=C2=A0 =C2=A0[RFC5246], = even if ClientHello.legacy_version is 0x0304 or
=C2=A0 =C2=A0late= r. Servers MAY abort the handshake upon receiving a ClientHello
= =C2=A0 =C2=A0with legacy_version 0x0304 or later.
=C2=A0 =C2=A0




> 4= .2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066
=
> status request. Why not require RFC6961?

Because TLS 1.3 allows you to attach OSCP-stapled responses to each
<= div>certificate with status_request, we felt that 6961 was superseded.


> 4.2. the exception for including c= ookie in HelloRetryRequest seems like
> something that could c= ause issues in future revisions. Any future
> revision of the = protocol would not be able to add such exceptions
> (since the= y will be rejected by existing clients), and the fact that
> t= he cookie is there, it indicates that such an exception may be useful.
> A suggestion to address that would be to allow the HelloRetryReq= uest
> contain any extension or grant an exception to a specif= ic extension
> number range.

Yes, thi= s is an interesting suggestion. I have filed issue:

https://github= .com/tlswg/tls13-spec/issues/939

However, as D= avid Benjamin points out, it's not clear how one would
handle= this in practice, because HRR is an instruction to the client
to= do something, so if it can't parse that then the handshake fails.


> 4.2.5.2. The parameters are inform= ally defined.
> I'd suggest to follow rfc4492bis and use i= ts text as in:

Good i= dea.

=
> 4.2.7. There is no guidance on the use of max_early_dat= a_size.=C2=A0
> I'd find it natural to have a recommended = minimum value for application
> protocols layered on TLS to ta= ke into account. E.g., text like servers
> supporting early_da= ta SHOULD allow at least 1024 bytes of data
> (arbitrary numbe= r). Is the 32-bit upper limit intentional?

I think= it's just a result of the way the PDU is formatted. I
would = be interested in seeing a PR with guidance...


=
> 4.2.8. This section changes the semantics for pre-shared ke= ys as used
> in any other protocol (including TLS 1.2). With t= he new text it
> implies, pre-shared keys must be combined wit= h a hash algorithm. Thus
> existing PSK deployments which shar= e keys and would like to upgrade to
> TLS 1.3 cannot do transp= arently. They would have to fix to a specific
> hash algorithm= for their existing PSKs, and make sure they provide that
> in= formation to all the underlying software (which may be different on
> the server and client side). I could find no implementation guideli= ne
> on what to do in the case of pre-existing PSKs in that te= xt.
>=C2=A0
> My recommendation would be to switc= h the sentence "For externally
> established PSKs, the Ha= sh algorithm MUST be set when the PSK is
> established" t= o "For externally established PSKs, the Hash algorithm
> = MUST be set when the PSK is established, or default to SHA-256". That<= /div>
> way implementations can cope transparently with an upgrade t= o TLS 1.3
> for already present PSK keys without requiring an = additional RFC
> describing that.

Thi= s seems like a good change. I have made it.


> 4.2.8. The overlap of the namespace for usernames to be used = in PSK
> authentication, and the namespace for "resumptio= n" does not give a good
> feeling.

Yeah, I can see that perspective. That's part of why we domain
=
separate in the implementation.



> 4.2.8. Related to the above, it is unclear what obfus= cated_ticket_age
> should contain when using PSK authenticatio= n (but not resumption).


=C2=A0 =C2= =A0 For identities established externally an obfuscated_ticket_age of
=
=C2=A0 =C2=A0 0 SHOULD be used, and servers MUST ignore the value.


> 4.2.8.1. It is not defined what t= he binder should contain when using
> PSK authentication (but = not resumption).

It's intended to be the same = (modulo the domain separation in the label).


<= /div>
> 4.2.8.1. If a single binder corresponds to a single identity= , the
> parsing and mapping of binders in the PreSharedKeyExte= nsion seems
> unnecessarily complicated. A suggestion is to mo= ve the binder inside
> each identity structure:
>= struct {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque identity= <1..2^16-1>;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32= obfuscated_ticket_age;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o= paque PskBinderEntry<32..255>;
> } PskIdentity;

I did consider that, but it's not possible because you= want the
binders to cover the other key identities so that it= 9;s not possible
to remove one without detection (unless you reje= ct PSK entirely,
in which case this is detected in the Finished).=


> 4.2.8.3. I believe that secti= on can benefit from some improvements.
> >From a first read= it is not clear what this section wants to protect
> from. It= provides some checks, but it is unclear to me what these
> pr= otect from.
>=C2=A0
> Some more concrete comments= on the same section:
> It mentions "see if the value use= d by the client matches its
> expectations". A question t= hat arises, is what is the recommended
> expectation for a ser= ver? Given the text in 4.2.8 that should be a
> week, but the = text in 4.2.8 seems to imply that the restriction is
> defined= somewhere else, and I would have expected it to be here.
>=C2= =A0
> The text recommends: "a server SHOULD measure the r= ound trip time prior
> to sending the NewSessionTicket message= ". I see two issues here. (1) it
> doesn't mention ho= w to do this measurement --my guess is that this can
> be done= in the context of TLS--, and (2) it assumes that round-trips
>= ; are fixed over time. About (1), I ask because the obvious measurement
> time between [server Application Data*] and client [Certificate= *] would
> include the processing of the application data by t= he client.
> On (2), this check will not work as is for mobile= clients which will
> have variable round-trips.
>= ;=C2=A0
> The check 'ticket age must be shorter than elaps= ed time by a round-
> trip', is unclear to me what it inte= nds to protect from.
>=C2=A0
> A clarification: &= quot;the actual time elapsed on the server", elapsed since
&= gt; when? (I guess since the first message was received).

Thanks. I will try to clean this up. I have filed=C2=A0
<= br>

> 4.3.2.1. The OID Filters extension on a f= irst look seems quite
> independent and unrelated to everythin= g else in this document (seemed
> quite a distraction that cou= ld have been in an appendix as well).

This is a fa= ir point, but it's been in the document a long time,
so I thi= nk this would require WG Consensus.


> 4.4.2.1.=C2=A0 OCSP Status and SCT Extensions
> This is = a very nice addition to TLS 1.3. Something that I miss as an
>= implementer is guidelines on how to determine the (time) validity of an
> OCSP stapled response. Here my point is that OCSP responses ha= ve
> several fields optional (e.g., nextUpdate), which make a = validation to
> be hand-wavy. It would be nice to have a profi= le of OCSP responses that
> would be recommended for use in TL= S, as well or a recommendation of
> what constitutes a "f= resh" response for use in TLS.

Do you have an= y thoughts on what text we should insert here? I admit
to being n= ot that familiar with the practical matters of OCSP stapling.


> 4.4.2.2., 4.4.2.3.
> I think the reference to RFC5081 should be replaced with RFC5270 whic= h
> obsoletes the former even though not explicitly.

Indeed. Also, we are now explicitly prohibiting OpenPGP per= discussion
in Chicago.


&= gt; 4.4.3. "RSA signatures MUST use an RSASSA-PSS algorithm". Wha= t should a
> client or server do when encounters an non RSA-PS= S signature in TLS


> 4.6.3. My c= omment on this section, is that leaving up to the
> implemente= r to decide the re-key, would most probably result in the
> im= plementer delegating that decision to the application. In my
>= experience that would mean no re-key in practice for the majority of
=
> applications. I'd have preferred a one-size fits all approach= , where
> re-key is done on decided points.

I can understand that, but we did litigate this extensively, so I th= ink
any change would require WG consensus at this point.


> 5.1. I miss a maximum number of alerts= received per session, or some
> other alert limiting mechanis= m (having CVE-2016-8610 in mind).

All alerts now r= esult in connection termination, so the limit
seems to implicitly= be 1.


> 7.5. There is no defini= tion of early_exporter_secret, and it is unclear
> why it is e= ven mentioned. In short how is this supposed to be used, and
>= why should implementations consider adding an interface to it?
<= br>
It is defined in:

I added some text to explain why you would w= ant it.


> A. Is the described st= ate machine intended to be normative or
> informative? I.e., w= hich takes precedence, this description or the text
> above? (= would be nice to clarify)

They are intended to be = consistent. I wiould appreciate WG feedback
on this point.
<= div>

> B.4.
> I believe it was= discussed before, but I miss the AES-256-CCM
> ciphersuites. = If only one must be defined, it may be better to only
> have t= he 256-bit variants (at least for the non-mac-truncated version)
=
Open to WG feedback here as well.

<= br>
> E. I'd find it natural for this to be the security c= onsiderations
> rather than an appendix.
>=C2=A0<= /div>
>=C2=A0
> G. Quite a long list. Would be nice to = have the contributors to TLS 1.3
> separately.

<= /div>
I'd rather not try to draw this distinction in acknowledgemen= ts. My
feeling is that people have been doing good work on this b= ack to =C2=A0
SSLv3. I will, however, try to typeset it into two = columns.


> Bibliography: There a= re references to PKCS6 and PKCS7 that are never
> used through= out the text (I guess there are more).

Thanks. We = will fix this pre-publication.


-Ekr=


On Wed, Mar 29, 2017 at 7:32 AM, Nikos Mavrogiannopoulos <nmav@red= hat.com> wrote:
On Wed, 2017-03-29 at 16:28 +0200, Nikos Mavrogiannopoulos wrote:

> A more general note on the section/document, is that although the
> PKIX
> identity (certificate) is protected from passive adversaries, the PSK<= br> > identity is not. This is a discrepancy in terms of protecting the
> user's identity between PSK and certificate authentication (that > should
> warrant .

... an entry in the security considerations.

> 4.2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066=
> status request. Why not require RFC6961?

Please ignore that. I forgot to delete in my draft.

regards,
Nikos

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c1bde9c651056054cea3434-- From nobody Tue Apr 11 14:25:47 2017 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 97078129AB6 for ; Tue, 11 Apr 2017 14:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 1euYT1geSnrw for ; Tue, 11 Apr 2017 14:25:42 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8B8129A91 for ; Tue, 11 Apr 2017 14:25:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 5464122F57; Wed, 12 Apr 2017 00:25:40 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Z9Ey-JApUrA2; Wed, 12 Apr 2017 00:25:39 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C552AC4; Wed, 12 Apr 2017 00:25:39 +0300 (EEST) Date: Wed, 12 Apr 2017 00:25:38 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Message-ID: <20170411212538.GA17709@LK-Perkele-V2.elisa-laajakaista.fi> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 21:25:46 -0000 On Tue, Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote: > Thanks for your comments. > > > 4.1.2. It is not defined what a server should do if encountered with a > > ProtocolVersion of TLS 1.3. > > https://tlswg.github.io/tls13-spec/#supported-versions says: > > If this extension is not present, servers which are compliant with > this specification MUST negotiate TLS 1.2 or prior as specified in > [RFC5246], even if ClientHello.legacy_version is 0x0304 or > later. Servers MAY abort the handshake upon receiving a ClientHello > with legacy_version 0x0304 or later. I think that MAY abort should be removed. client_version field has always been defined to be tolerant to higher values. > However, as David Benjamin points out, it's not clear how one would > handle this in practice, because HRR is an instruction to the client > to do something, so if it can't parse that then the handshake fails. I think if one wanted to have new mandatory HRR extension, one could just have it sent, resulting older clients blowing up. But those would not be able to connect anyway. > > 4.2.7. There is no guidance on the use of max_early_data_size. > > I'd find it natural to have a recommended minimum value for application > > protocols layered on TLS to take into account. E.g., text like servers > > supporting early_data SHOULD allow at least 1024 bytes of data > > (arbitrary number). Is the 32-bit upper limit intentional? > > I think it's just a result of the way the PDU is formatted. I > would be interested in seeing a PR with guidance... The max_early_data_size looks kinda iffy. I understand the justification is about buffering for verification, but that kind of buffering AFAICT destroys the benefits of 0-RTT, so I would just skip 0-RTT if I knew such buffering would take place. > > The text recommends: "a server SHOULD measure the round trip time prior > > to sending the NewSessionTicket message". I see two issues here. (1) it > > doesn't mention how to do this measurement --my guess is that this can > > be done in the context of TLS--, and (2) it assumes that round-trips > > are fixed over time. About (1), I ask because the obvious measurement > > time between [server Application Data*] and client [Certificate*] would > > include the processing of the application data by the client. > > On (2), this check will not work as is for mobile clients which will > > have variable round-trips. The thresholds seem so loose anyway, that I don't see much need to even try to measure the RTT, one can seemingly just ignore them. > > 4.3.2.1. The OID Filters extension on a first look seems quite > > independent and unrelated to everything else in this document (seemed > > quite a distraction that could have been in an appendix as well). > > This is a fair point, but it's been in the document a long time, > so I think this would require WG Consensus. Also, I have no idea of exact contents of that extension (maybe some mail to this list has those, but that won't do with RFCs), as I can interpret the thing in multiple ways. > > 4.4.2.1. OCSP Status and SCT Extensions > > This is a very nice addition to TLS 1.3. Something that I miss as an > > implementer is guidelines on how to determine the (time) validity of an > > OCSP stapled response. Here my point is that OCSP responses have > > several fields optional (e.g., nextUpdate), which make a validation to > > be hand-wavy. It would be nice to have a profile of OCSP responses that > > would be recommended for use in TLS, as well or a recommendation of > > what constitutes a "fresh" response for use in TLS. > > Do you have any thoughts on what text we should insert here? I admit > to being not that familiar with the practical matters of OCSP stapling. Well, my implementation considers OCSP responses valid to NextUpdate, and fails handshake if it is absent but OCSP staple is sent. > > 4.4.2.2., 4.4.2.3. > > I think the reference to RFC5081 should be replaced with RFC5270 which > > obsoletes the former even though not explicitly. > > Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion > in Chicago. Also, maybe needs some text about possible future Certificate Types (or are those akin to DNS classes: heavy objects dropped by bad idea fairy? :-) ). Also, client_certificate_type looks to be still CH,EE, which is not good if any future certificate types might get defined (or even if just RPK is allowed). > > 4.4.3. "RSA signatures MUST use an RSASSA-PSS algorithm". What should a > > client or server do when encounters an non RSA-PSS signature in TLS Well, my implementation just aborts. I have actually seen an TLS 1.3 draft implementation sign with RSA PKCS#1 (it did so if one sent a ClientHello that only had that and ECDSA and EdDSAs). > > 4.6.3. My comment on this section, is that leaving up to the > > implementer to decide the re-key, would most probably result in the > > implementer delegating that decision to the application. In my > > experience that would mean no re-key in practice for the majority of > > applications. I'd have preferred a one-size fits all approach, where > > re-key is done on decided points. > > I can understand that, but we did litigate this extensively, so I think > any change would require WG consensus at this point. Might be a good idea to have suggestion to send one fairly early in the connection. > > B.4. > > I believe it was discussed before, but I miss the AES-256-CCM > > ciphersuites. If only one must be defined, it may be better to only > > have the 256-bit variants (at least for the non-mac-truncated version) > > Open to WG feedback here as well. Also, who uses those? It seems like CCM is mostly for things, and those don't use AES-256, as AES-128 already seems quite much for various IoS. Also, if one wanted special ciphersuite for things, I think there are ones that are implementable in smaller space than AES CCM. -Ilari From nobody Tue Apr 11 14:54:01 2017 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 C2E30128768 for ; Tue, 11 Apr 2017 14:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham 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 BYyM1bFBXHAf for ; Tue, 11 Apr 2017 14:53:47 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::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 74C4412EBF0 for ; Tue, 11 Apr 2017 14:53:47 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id m133so2654138ybb.1 for ; Tue, 11 Apr 2017 14:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H+rGZ7igG1j0eDM/9gFuU18ktiTN9wETe/WUHnCxptU=; b=Fw9AqMka2MmqZAiJfvFgimh2P1YnFtNlIVKdfTVU55qu6uP0WYQ9WAjVhknIIaeWzK CgifzCRB9H9ubFQQywwHmbhh7+/0XJmQnhz7E9AT79MTkXdf9hNOzNcqN8/FEwoHExJJ M5f16V3EnmmdCUuYpWkAePtUrZyU4IjBy4emAaH0cHPsXjmkGe/6YFxRy+pq9L+ntizV VNtlo+j2JYxh12n8CKAx3PSWGsccVWToh7UT0l/9sqmC85UbehLvovr443nBDRvETfmO IMisPb8ghZT+Tc87QVw5VHOuTntpKTxAA4XbYAl9LCrZ0awbE1mS13S0nQFzTiv3Th7U Weqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H+rGZ7igG1j0eDM/9gFuU18ktiTN9wETe/WUHnCxptU=; b=LRxD9kI99w4ESXwh0YXdP/QIwv7iHKpp6/Us5rtIViiJx9lGgpH9PUKj4r+R9Nz8HU RXj8ZeDO2z33/7s8nkAuel1zkWcKmI1VCi1zSlBYzDMf5bz5TBAV1kvpQKhlf0Ow72oN BcFU7omIrfS+YLVz0V0p+Ze/jJMFItaguPLsdIwB4ht7lOpp9gzMZZuBVxN1s7BAYaiF jLy3bFdzKG70aygLbY2WS9udkeEq34MxE+6wNOcEEgKuBHNP6xNp3OccisZBw4MUCi1N FIEknG5mJGd60PCoBejYppOWxUMb8bFicyh6w5xhzvl3P7bSEmoL4mUyc8LZSufkmZx+ llNA== X-Gm-Message-State: AN3rC/7w7/+HazCtSy2kAUopY8fB6AwnnXoZ4Hccair/FTOOWHpJzCAlzyRrv49k4nz+a5di5xiMglISk8m5tw== X-Received: by 10.37.173.225 with SMTP id d33mr9742909ybe.64.1491947626706; Tue, 11 Apr 2017 14:53:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 11 Apr 2017 14:53:06 -0700 (PDT) In-Reply-To: <20170411212538.GA17709@LK-Perkele-V2.elisa-laajakaista.fi> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <20170411212538.GA17709@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 11 Apr 2017 14:53:06 -0700 Message-ID: To: Ilari Liusvaara Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Content-Type: multipart/alternative; boundary=f403045eb87a506159054ceb20fe Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 11 Apr 2017 21:53:50 -0000 --f403045eb87a506159054ceb20fe Content-Type: text/plain; charset=UTF-8 On Tue, Apr 11, 2017 at 2:25 PM, Ilari Liusvaara wrote: > On Tue, Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote: > > Thanks for your comments. > > > > > 4.1.2. It is not defined what a server should do if encountered with a > > > ProtocolVersion of TLS 1.3. > > > > https://tlswg.github.io/tls13-spec/#supported-versions says: > > > > If this extension is not present, servers which are compliant with > > this specification MUST negotiate TLS 1.2 or prior as specified in > > [RFC5246], even if ClientHello.legacy_version is 0x0304 or > > later. Servers MAY abort the handshake upon receiving a ClientHello > > with legacy_version 0x0304 or later. > > I think that MAY abort should be removed. client_version field has > always been defined to be tolerant to higher values. > It seems like we are ossifyng that extension point. Otherwise it's very hard to interpret. But I'm willing to defer if the WG objects. > > However, as David Benjamin points out, it's not clear how one would > > handle this in practice, because HRR is an instruction to the client > > to do something, so if it can't parse that then the handshake fails. > > I think if one wanted to have new mandatory HRR extension, one could > just have it sent, resulting older clients blowing up. But those would > not be able to connect anyway. > That's what we have now :) > > > 4.3.2.1. The OID Filters extension on a first look seems quite > > > independent and unrelated to everything else in this document (seemed > > > quite a distraction that could have been in an appendix as well). > > > > This is a fair point, but it's been in the document a long time, > > so I think this would require WG Consensus. > > Also, I have no idea of exact contents of that extension (maybe some mail > to this list has those, but that won't do with RFCs), as I can interpret > the thing in multiple ways. Hmm.. I did think the text was reasonably clear, but maybe I am in too deep. > > > 4.4.2.2., 4.4.2.3. > > > I think the reference to RFC5081 should be replaced with RFC5270 which > > > obsoletes the former even though not explicitly. > > > > Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion > > in Chicago. > > Also, maybe needs some text about possible future Certificate Types > (or are those akin to DNS classes: heavy objects dropped by bad idea > fairy? :-) ). > > Also, client_certificate_type looks to be still CH,EE, which is not > good if any future certificate types might get defined (or even if > just RPK is allowed). > Actually, I think this is still right. The reason is that this extension applies to the client's entire certificate message, not to each certificate, so it needs to be negotiated up front. -Ekr > > > B.4. > > > I believe it was discussed before, but I miss the AES-256-CCM > > > ciphersuites. If only one must be defined, it may be better to only > > > have the 256-bit variants (at least for the non-mac-truncated version) > > > > Open to WG feedback here as well. > > Also, who uses those? It seems like CCM is mostly for things, and those > don't use AES-256, as AES-128 already seems quite much for various IoS. > > Also, if one wanted special ciphersuite for things, I think there are > ones that are implementable in smaller space than AES CCM. > > > -Ilari > --f403045eb87a506159054ceb20fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 11, 2017 at 2:25 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Tue,= Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote:
> Thanks for your comments.
>
> > 4.1.2. It is not defined what a server should do if encountered w= ith a
> > ProtocolVersion of TLS 1.3.
>
> https://tlswg.github.io/tls13-spec/#= supported-versions says:
>
>=C2=A0 =C2=A0 If this extension is not present, servers which are compl= iant with
>=C2=A0 =C2=A0 this specification MUST negotiate TLS 1.2 or prior as spe= cified in
>=C2=A0 =C2=A0 [RFC5246], even if ClientHello.legacy_version is 0x0304 o= r
>=C2=A0 =C2=A0 later. Servers MAY abort the handshake upon receiving a C= lientHello
>=C2=A0 =C2=A0 with legacy_version 0x0304 or later.

I think that MAY abort should be removed. client_version field has always been defined to be tolerant to higher values.
<= br>
It seems like we are ossifyng that extension point. Otherwise= it's very hard to interpret. But I'm willing to defer if the WG ob= jects.


> However, as David Benjamin points out, it's not clear how one woul= d
> handle this in practice, because HRR is an instruction to the client > to do something, so if it can't parse that then the handshake fail= s.

I think if one wanted to have new mandatory HRR extension, one could=
just have it sent, resulting older clients blowing up. But those would
not be able to connect anyway.

That'= ;s what we have now :)

=C2=A0
> > 4.3.2.1. The OID Filters extensi= on on a first look seems quite
> > independent and unrelated to everything else in this document (se= emed
> > quite a distraction that could have been in an appendix as well).=
>
> This is a fair point, but it's been in the document a long time, > so I think this would require WG Consensus.

Also, I have no idea of exact contents of that extension (maybe some= mail
to this list has those, but that won't do with RFCs), as I can interpre= t
the thing in multiple ways.

Hmm.. I did thi= nk the text was reasonably clear, but maybe I am in too deep.

=C2=A0
> > 4.4.2.2., 4.4.2.3.
> > I think the reference to RFC5081 should be replaced with RFC5270 = which
> > obsoletes the former even though not explicitly.
>
> Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion=
> in Chicago.

Also, maybe needs some text about possible future Certificate Types<= br> (or are those akin to DNS classes: heavy objects dropped by bad idea
fairy? :-) ).

Also, client_certificate_type looks to be still CH,EE, which is not
good if any future certificate types might get defined (or even if
just RPK is allowed).

Actually, I think= this is still right. The reason is that this extension applies
t= o the client's entire certificate message, not to each certificate, so = it
needs to be negotiated up front.

-Ekr=

=C2=A0
> > B.4.
> > I believe it was discussed before, but I miss the AES-256-CCM
> > ciphersuites. If only one must be defined, it may be better to on= ly
> > have the 256-bit variants (at least for the non-mac-truncated ver= sion)
>
> Open to WG feedback here as well.

Also, who uses those? It seems like CCM is mostly for things, and th= ose
don't use AES-256, as AES-128 already seems quite much for various IoS.=

Also, if one wanted special ciphersuite for things, I think there are
ones that are implementable in smaller space than AES CCM.


-Ilari

--f403045eb87a506159054ceb20fe-- From nobody Tue Apr 11 21:32:33 2017 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 3A3C9124BFA for ; Tue, 11 Apr 2017 21:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.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 9NtlLtnawkaw for ; Tue, 11 Apr 2017 21:32:29 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 549E61267BB for ; Tue, 11 Apr 2017 21:32:29 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id o126so7980264pfb.3 for ; Tue, 11 Apr 2017 21:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=tIMYq81UKLgsKXekKkQ07fhoOKf1pV1knvO7+qjKM+I=; b=RIsYy3AYGbLzT6LmsCuGxqYgWIgaZZNkAD+uSfPz2SVNVH4tjvL7FUpY/ayg0Z9Z+z FVB6MxilWGyuB/vD/085N5Zk+N3j5/8dNdddFXfcEjVOVCN7XCzv2cZG+1WHxGqUy/CI M0BQyYFqop8WIn42utvuHFqNigG77WzydxXjLnCi9xDi3J59IyymBtBe12WcjYUtcEvi d8OAzFPy2PFXdHpoBCG9Paih5RTwJGIrJijowtRpxt2qRl6pGWQI20SsyJhfmSirvaOi GyMm83hFqkqafeL2m4XELRjl2t+YsWloN1/agOWv/MQPvjtdnnnutNGp6DiJYutI8syZ VP8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tIMYq81UKLgsKXekKkQ07fhoOKf1pV1knvO7+qjKM+I=; b=fwJxBTGZL49kOBzJE34I04b5JWp+6CqC9f4iHosh3mLcWGxhTXg+UdWHp5nn0Uz62y 7xavgZKfAWGJjW8z41ehVu6biAUy0N2grP2mHV0zucTDHmVoeyfuYvEV1MHXse+z+pIr Fj4pfJR5Y8+r+LV/ACqJhYgm6PCAB29b9A2JxOyIosBc4Pa9GlAK+aNl/2oPB3z9XgcV GVOJV2IdAX9kCneCs0GwJElBm7Erqjv8sJqjBzOlYCH8LNQ1MfYOw1g60tNynTw6VUty vMB+X7HHsJcAdvrg2qX7HAi+ZDU9OqIOwqwwxkToO6yycML6xAVB7aRc2M3DfDsN8upd zpXA== X-Gm-Message-State: AFeK/H1f0YymUwO+Um0KonljyswDMWjljp+qlOEWKBgJdVUAFcTFvFz0URoATYPMThGZ2mNYf0k2PCOWb4+Etg== X-Received: by 10.98.9.29 with SMTP id e29mr65123129pfd.101.1491971548827; Tue, 11 Apr 2017 21:32:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.7 with HTTP; Tue, 11 Apr 2017 21:32:08 -0700 (PDT) From: Joseph Salowey Date: Tue, 11 Apr 2017 21:32:08 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1143f6e62eee2a054cf0b21c Archived-At: Subject: [TLS] IETF-98 Minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 12 Apr 2017 04:32:32 -0000 --001a1143f6e62eee2a054cf0b21c Content-Type: text/plain; charset=UTF-8 Draft meeting minutes are now available in the draft proceedings: https://www.ietf.org/proceedings/98/minutes/minutes-98-tls-00.txt Let me know if you have an additions/corrections. Thanks, Joe --001a1143f6e62eee2a054cf0b21c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Draft meeting minutes are now available in the draft proce= edings:=C2=A0https://www.ietf.org/proceedings/98/minutes/minutes-98-tls-= 00.txt

Let me know if you have an additions/correcti= ons.=C2=A0

Thanks,

Joe
--001a1143f6e62eee2a054cf0b21c-- From nobody Wed Apr 12 12:30:02 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9222D12EB55; Wed, 12 Apr 2017 12:30:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149202540059.15698.14576140662463343893.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 12:30:00 -0700 Archived-At: Subject: [TLS] The TLS WG has placed draft-rescorla-tls-subcerts in state "Candidate for WG Adoption" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 12 Apr 2017 19:30:01 -0000 The TLS WG has placed draft-rescorla-tls-subcerts in state Candidate for WG Adoption (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-rescorla-tls-subcerts/ From nobody Wed Apr 12 12:31:26 2017 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 BC19F1294EF for ; Wed, 12 Apr 2017 12:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 uaRBcgH7VF6r for ; Wed, 12 Apr 2017 12:31:18 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 2A2411296CF for ; Wed, 12 Apr 2017 12:31:08 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id v3so30495753qtd.3 for ; Wed, 12 Apr 2017 12:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=Xz5lCeq6uO4BpIULnBxLNf/U6CHP/tSzcE/x5SPnQSY=; b=k6/BUO2Mww6ACbG0xlQ4SYCYMgDftPCdvk5s3nBT9I8tQewlL4ozhf5VhdsRdroPpD Dw8jZ8N6VU8ENYzqIT3DFeh0WVUz39+Ussh61dhxM5ayUtHmOgUjiDTmr9LmVfm52Fm7 pdvJ27AB72gxNk4JMRwaKgnGD9auBlfHCxBVI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=Xz5lCeq6uO4BpIULnBxLNf/U6CHP/tSzcE/x5SPnQSY=; b=kPJPGxGhDn+vPGLGkyi/ZUK2vctsRA/q45woX3rsJF4FVUSF20gLFeiQ8SgIeQIFjo ebgVZ6o6Mjb7qgh0xJ+fq7lvaHxvoaDctIXaVZKxQ8xm08ZARnmd6q86P0jTF0J7YlPJ jQUytSecgK20R1N+BJLAWZfI+H8hVEH2w1gPeV2IdK+RsgftzdD8YO3Tokp/SW53IJDf +rSXJtEuTykBebPaquYCtognO9EpBFr00KI1MC9UGsmu+B85EN0VeLgY9d2DcJSyqWs/ O0v4p2YoX9DOBIOWMoa6f6YvB/ouxF6t2eIsUxwh6Qiw6Vq4Fb19ZRAgoi3NXQe7/3Wg rlaA== X-Gm-Message-State: AN3rC/4WSvsmEc3dxNzA35HHgwz8daZeIvZNCOJH0paNvZGDF5u3ce4XsZfWWm3ffXiJ7Q== X-Received: by 10.200.46.157 with SMTP id h29mr14248140qta.39.1492025467083; Wed, 12 Apr 2017 12:31:07 -0700 (PDT) Received: from [172.16.0.18] ([96.231.229.219]) by smtp.gmail.com with ESMTPSA id n75sm14082858qki.60.2017.04.12.12.31.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 12:31:06 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> Date: Wed, 12 Apr 2017 15:31:05 -0400 Cc: lurk@ietf.org To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 12 Apr 2017 19:31:20 -0000 All, At our IETF 98 session, there was support in the room to adopt = draft-rescorla-tls-subcerts [0]. We need to confirm this support on the = list so please let the list know whether you support adoption of the = draft and are willing to review/comment on the draft before 20170429. = If you object to its adoption, please let us know why. Clearly, the WG is going to need to work through the trade-offs between = short-lived certificates and sub-certs because both seem, to some, to be = addressing the same problem.=20 Cheers, J&S [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts= From nobody Wed Apr 12 12:34:40 2017 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 12C8112943E for ; Wed, 12 Apr 2017 12:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 7zi5aR3TBA-H for ; Wed, 12 Apr 2017 12:34:30 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 780E412952C for ; Wed, 12 Apr 2017 12:34:30 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id j9so16553642ywj.3 for ; Wed, 12 Apr 2017 12:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5xy62kjyJynYa0x0VwtnfisQBcPsh2dk7d0TcBuEFhE=; b=jz7kUxY6VNW/PRjFMPIfJt+ZGcbhT+dr99qzVp6iDDctDBaQZptPI33e1ZhRK19uVc jEyDawx3S/NXN55nX7HGBUoF/uQ8JWcZ0mCXudUQfN38BEcG2S3HbEHwGnt/htralZpn qJcs5xonfeljiC8wR3mo20cejIB02N+VYK7a8Z7pHHbwhPnwm6GcLqyr2qbIBw6DEhmg KJ6EQ5sMMiIe67fNb9lSsRuBhzWDsd5VijmMKNYMMIpxlgukL9eGff+ac+OKXl+0WmXS KBbnJXOCE4uqV5J/yOtPPH2ZzKAnFKWTd6TbWRVksDyWig44W/pKyRpYunFB3o5MLixy j67g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5xy62kjyJynYa0x0VwtnfisQBcPsh2dk7d0TcBuEFhE=; b=TsaeEc2tPfCAuJDfOsdPO/dOJuJOeIMFqgw6DPgPzi+hPelr2Mf9gGrJi5JYuasl3J 6FvXgx0SnW4qiOumMVYZiT59GqIGQs7kucxGEA9hXA5wJ6cKBt09onbn4UOtsdUDmTxm lsyXxx2rUK0BewezsFyvlLkBfYrgNhTScDeHH2cmcuUT8b4YRQf7bk5GNOvuRs2iRPPW w0J5LaaIJ+qvUw4x9p8bN1BT9rlfFDEA9WRbrsLQ6/P7drmre+2E9cDrU4HUDETMb7GS QipwDvXhxMqoOJoAAYw7B1+B4UHP84AeXjsB/7phlIOtS4U5V+DYE8u4Gq6jenXDUIge 4JmA== X-Gm-Message-State: AN3rC/5rhX78q837TOD/hfi+Tl0OXieGM0c95RBluYHY1TZ2KAR7kYyxo3yDv1l/Vv+eUd0DtNN+GXmeJMAftA== X-Received: by 10.13.203.73 with SMTP id n70mr12528647ywd.71.1492025669675; Wed, 12 Apr 2017 12:34:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 12 Apr 2017 12:33:49 -0700 (PDT) In-Reply-To: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> From: Eric Rescorla Date: Wed, 12 Apr 2017 12:33:49 -0700 Message-ID: To: Sean Turner Cc: "" , LURK BoF Content-Type: multipart/alternative; boundary=001a114fd3d609946a054cfd4c93 Archived-At: Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 12 Apr 2017 19:34:33 -0000 --001a114fd3d609946a054cfd4c93 Content-Type: text/plain; charset=UTF-8 Unsurprisingly, I favor adopting this draft. -Ekr On Wed, Apr 12, 2017 at 12:31 PM, Sean Turner wrote: > All, > > At our IETF 98 session, there was support in the room to adopt > draft-rescorla-tls-subcerts [0]. We need to confirm this support on the > list so please let the list know whether you support adoption of the draft > and are willing to review/comment on the draft before 20170429. If you > object to its adoption, please let us know why. > > Clearly, the WG is going to need to work through the trade-offs between > short-lived certificates and sub-certs because both seem, to some, to be > addressing the same problem. > > Cheers, > > J&S > > [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts > _______________________________________________ > Lurk mailing list > Lurk@ietf.org > https://www.ietf.org/mailman/listinfo/lurk > --001a114fd3d609946a054cfd4c93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Unsurprisingly, I favor adopting this draft.

-Ekr


On Wed, Apr 12, 2017 at 12:31 PM, Sean Turner <sean@sn3rd= .com> wrote:
All,

At our IETF 98 session, there was support in the room to adopt draft-rescor= la-tls-subcerts [0].=C2=A0 We need to confirm this support on the list so p= lease let the list know whether you support adoption of the draft and are w= illing to review/comment on the draft before 20170429.=C2=A0 If you object = to its adoption, please let us know why.

Clearly, the WG is going to need to work through the trade-offs between sho= rt-lived certificates and sub-certs because both seem, to some, to be addre= ssing the same problem.

Cheers,

J&S

[0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts
_______________________________________________
Lurk mailing list
Lurk@ietf.org
https://www.ietf.org/mailman/listinfo/lurk

--001a114fd3d609946a054cfd4c93-- From nobody Wed Apr 12 14:25:37 2017 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 A377C12EB62 for ; Wed, 12 Apr 2017 14:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 XhJZPDkJp6tl for ; Wed, 12 Apr 2017 14:25:27 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 EDEBA12EB3F for ; Wed, 12 Apr 2017 14:25:25 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id w64so97963607wma.0 for ; Wed, 12 Apr 2017 14:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1fLObzvuX4XejYFdGR2kzYomX79/vqZYtry00o2Kzak=; b=kK1PY9bh3BnTG/QJT+X3plnY/vb4MCJzgzCcO2KaWw46D8wYPAEvsTMR5AFUNBUJwq IU2KXHxj57Inw9RrzanaDbyPkczZ37DUq8paAC44ikfQr8owe/DHBWnqlqnQ7IUV5qj4 kTHpBEccrfn3k7bkAyubnrJsebzDpCqyqpQJ5E2SlikcemLT+9ZOmgej+l/zaFLIRfGQ xg9nWiILci48Fku8d+vnFH7xqa10a2V2ThAMVTJpthTbmsTf+pUjiNNj10jz3ccENCaT 81DI7U52bb0w+T/fm0iMAWJKFRvR8Aq/thtOXlGPHNsU+siBpaS+pmZltXRI3FIydkOU sQCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1fLObzvuX4XejYFdGR2kzYomX79/vqZYtry00o2Kzak=; b=Yxtta5h/vH9S09Apc3Vp1BdURqgGsLrOXm/Ydu5d0WpLDBdFMk/yYVlvWa+HRlHMFh fHPjzPvmoE20Olazb5wIEk9lbOig/qGGLQeAB6zT4/EPh04w9rfdCL37sEedFHHKyRtm QYV641J9BVOD1nsIzbzHBaNkhiPWQR0G5c5i/8hb84dqoJIKPNigynP/P6LwHOZmN8gt R3K1GJRBOuva8TESlthpgMdFDeDPic4m89N9aqGc9yE8fkz0aX1+9dJOCQBrn7Kb7DzJ zcKcbZdcTnDzvq2x3iaAuyMby4QlLDpBfU5CyrpvAZ5uEMWKlYMYamZdGfAWodQWZn0i KyeA== X-Gm-Message-State: AN3rC/7o/XVyRrfzJrKDz5KvJtKoS09JnUjUqkEDnXgSycmTrTkmIplu OmQ69pKOHRK0wGkQsHLZU0683T17ew== X-Received: by 10.28.66.74 with SMTP id p71mr218739wma.131.1492032324231; Wed, 12 Apr 2017 14:25:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Wed, 12 Apr 2017 14:25:23 -0700 (PDT) In-Reply-To: References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> From: Richard Barnes Date: Wed, 12 Apr 2017 17:25:23 -0400 Message-ID: To: Eric Rescorla Cc: Sean Turner , LURK BoF , "" Content-Type: multipart/alternative; boundary=94eb2c074aaaae023f054cfed83c Archived-At: Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 12 Apr 2017 21:25:29 -0000 --94eb2c074aaaae023f054cfed83c Content-Type: text/plain; charset=UTF-8 Likewise. On Wed, Apr 12, 2017 at 3:33 PM, Eric Rescorla wrote: > Unsurprisingly, I favor adopting this draft. > > -Ekr > > > On Wed, Apr 12, 2017 at 12:31 PM, Sean Turner wrote: > >> All, >> >> At our IETF 98 session, there was support in the room to adopt >> draft-rescorla-tls-subcerts [0]. We need to confirm this support on the >> list so please let the list know whether you support adoption of the draft >> and are willing to review/comment on the draft before 20170429. If you >> object to its adoption, please let us know why. >> >> Clearly, the WG is going to need to work through the trade-offs between >> short-lived certificates and sub-certs because both seem, to some, to be >> addressing the same problem. >> >> Cheers, >> >> J&S >> >> [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts >> _______________________________________________ >> Lurk mailing list >> Lurk@ietf.org >> https://www.ietf.org/mailman/listinfo/lurk >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c074aaaae023f054cfed83c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Likewise.

On Wed, Apr 12, 2017 at 3:33 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
U= nsurprisingly, I favor adopting this draft.

-Ekr


On Wed, Apr 12, 2017 at 12:31 PM, Sean Turner <sean@sn3rd= .com> wrote:
All,

At our IETF 98 session, there was support in the room to adopt draft-rescor= la-tls-subcerts [0].=C2=A0 We need to confirm this support on the list so p= lease let the list know whether you support adoption of the draft and are w= illing to review/comment on the draft before 20170429.=C2=A0 If you object = to its adoption, please let us know why.

Clearly, the WG is going to need to work through the trade-offs between sho= rt-lived certificates and sub-certs because both seem, to some, to be addre= ssing the same problem.

Cheers,

J&S

[0] https://datatracker.ietf.org/d<= wbr>oc/html/draft-rescorla-tls-subcerts
_______________________________________________
 Lurk mailing list
Lurk@ietf.org
https://www.ietf.org/mailman/listinfo/lurk


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--94eb2c074aaaae023f054cfed83c-- From nobody Wed Apr 12 14:37:20 2017 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 8789012EA74 for ; Wed, 12 Apr 2017 14:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.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 ozMsrRyYx6bQ for ; Wed, 12 Apr 2017 14:37:17 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 44F61129A96 for ; Wed, 12 Apr 2017 14:37:17 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id i5so19325835pfc.2 for ; Wed, 12 Apr 2017 14:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=gF6CqnIKbck8TCG37o3jWWuMv47yv9M4uP6tHniQrOc=; b=mqamS4ZHqVQLDax5CvaMuEgJj0L/Pbt2m3kIKvH3857m3rydowzoGP6xoJnLlVLcqt GzSLQjCkvPr8p3b366n7OMSmaKEkdxTdmD6ZLoQ4TYmC1Y9YmoLnE6FRWKMEgcLW294L VVwnPnORRPKICJFBJjUHfDFnfhvqvRxxihxYEPQsg8wg4kpcnzhS4XlzaEXKGbDr3Aw4 FWIJkY0yR8SnDB3CVtrWcoGY/+tBuNs4oFRo3iWzCNAwlNMBcanjZr06ZAAILP97HAZ6 3RwNhFFt27AuVDsfjbZKjN/7PdKTHMG6u1HPCUlWPO1VYSEkt3JrEIXfov0AT4YKh3zz /Uug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=gF6CqnIKbck8TCG37o3jWWuMv47yv9M4uP6tHniQrOc=; b=QOt5sM0cnfeIpx9+H58PRYOL9QsC26eNmHB4st7R3jnkSynBWIwkiQpjdddsa71Jn/ QzpH6/Rjc+ZY/5/3cJigwdQQiy/QRk07KSZisRy11wjgwQDJnn7WnMmKw5E8/cn4YcOc fxHGWY945zbUyxYzfoDmzPvAtND/zRB9m6n4oSjeqhiE1y7mxw/uU9pGtlybPa2CavJZ OnlxXhIDcyTP7Wj6YxM5/dOCMuHmPqfMHmaUiuetjEFi0DPHeJiA0W6jqfMiH4i4uqRV Hx42U7UJDPbRqvcJ+Bau4RruFniLE3e5ibqqATj343ISydN9c9MqfFtIluqez4Rq1IG8 40Lw== X-Gm-Message-State: AFeK/H0hd4LGfqeiTQvmN0v9WaHnheQgAvfLdGK5l2OMp+DSxYSejywqBUtp0K35+yr8JA== X-Received: by 10.84.234.2 with SMTP id m2mr86694040plk.169.1492033036915; Wed, 12 Apr 2017 14:37:16 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-121-9-radius.dynamic.acsalaska.net. [216.67.121.9]) by smtp.gmail.com with ESMTPSA id l127sm38410573pga.7.2017.04.12.14.37.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 14:37:16 -0700 (PDT) To: lurk@ietf.org, tls@ietf.org References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> From: Melinda Shore Message-ID: <6b41cf6f-06db-bac7-94fa-826293f1160e@nomountain.net> Date: Wed, 12 Apr 2017 13:37:14 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xTBjgLLoQq6Jelli8WdJL0ajlEJiEQPHg" Archived-At: Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 12 Apr 2017 21:37:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xTBjgLLoQq6Jelli8WdJL0ajlEJiEQPHg Content-Type: multipart/mixed; boundary="IXx9Bojt5kuMfBa6Dn5bq6oW8uVbWDPF8"; protected-headers="v1" From: Melinda Shore To: lurk@ietf.org, tls@ietf.org Message-ID: <6b41cf6f-06db-bac7-94fa-826293f1160e@nomountain.net> Subject: Re: [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> In-Reply-To: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> --IXx9Bojt5kuMfBa6Dn5bq6oW8uVbWDPF8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/12/17 11:31 AM, Sean Turner wrote: > At our IETF 98 session, there was support in the room to adopt > draft-rescorla-tls-subcerts [0]. We need to confirm this support on > the list so please let the list know whether you support adoption of > the draft and are willing to review/comment on the draft before > 20170429. If you object to its adoption, please let us know why. I support its adoption (for whatever it's worth I work for a CDN) and would be happy to review the draft before the end of the month. Melinda --IXx9Bojt5kuMfBa6Dn5bq6oW8uVbWDPF8-- --xTBjgLLoQq6Jelli8WdJL0ajlEJiEQPHg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY7p4KAAoJELiGRpM6HoEudjAQAIfk08Z0dccfA/ose+d1R1Tm fE2WwEDBrue4rZnraGhtBAZwAzoVTcxitdOVW6hdwidth4ifOb0MvAtiRVhKeMdu Jo+8TPfaFSJvnfqXR3EXEc8flZPQ5nVsZFVNA2p04nzNIZtXPAb5HeHpt3IA03Bw A1YpEud71s5AEcNF0tl0HbXgoKgYD5B1wLf1p7XVDB9HPNZL4LK17kBSHtKMJwNO 9o6fM6idwmN8q+0McXleJD/cLQcZSYUAXmz7xhM7bim3Tgpkf+ZFA+O5ZkU1xFfG ZKuNqyeD5pD2tYTOR5AEIVrKdJ7z1s7lQEfhkjoXfUqmoHyUdVd87nbypGEU0GIo 7y7V4MqsPPCjmiGLGVu5/bO4nFVysV24+0Wz9xIVwL9hRWQoCrGy9ZDQq82g2Ys1 00y5nf+pEBUF71uBem1JLa+5YGzAu310BDEUPHB5ETdegEqdfsVCgMq7SXaPWr06 g+lTLzpDD6EBmr1XMSdmHoLtiLSjQEcLO2LpJoitJJiJVbWCti2ph+mpG7WFtGrG sHks5M8/r+DAPFt45Xex/owbpUR31gCng6XGRPxeOneq8DGfBLG0EcL4dThXuwC3 EYrnHMmilwo7Nu/j5F+JPAO5b3ooUM9FwAoQ4/et4zH7bk3YPi9vxErPbqgYCUfF 8TaqW/HJMEHjPg8X/YGA =TS6O -----END PGP SIGNATURE----- --xTBjgLLoQq6Jelli8WdJL0ajlEJiEQPHg-- From nobody Wed Apr 12 14:37:44 2017 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 8025212EB3F for ; Wed, 12 Apr 2017 14:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=unavailable 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 a3mrXdlUwTn6 for ; Wed, 12 Apr 2017 14:37:34 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1710A12EB5D for ; Wed, 12 Apr 2017 14:37:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 765D430044A for ; Wed, 12 Apr 2017 17:37:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id l-Hkn47aUZ3g for ; Wed, 12 Apr 2017 17:37:29 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0D09D300436; Wed, 12 Apr 2017 17:37:29 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_E2D4A665-3400-424F-A2DC-AD42621E3074" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 17:37:28 -0400 References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> To: IETF TLS , IETF LURK In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 12 Apr 2017 21:37:37 -0000 --Apple-Mail=_E2D4A665-3400-424F-A2DC-AD42621E3074 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Wed, Apr 12, 2017 at 12:31 PM, Sean Turner > wrote: All, At our IETF 98 session, there was support in the room to adopt = draft-rescorla-tls-subcerts [0]. We need to confirm this support on the = list so please let the list know whether you support adoption of the = draft and are willing to review/comment on the draft before 20170429. = If you object to its adoption, please let us know why. Clearly, the WG is going to need to work through the trade-offs between = short-lived certificates and sub-certs because both seem, to some, to be = addressing the same problem. Cheers, J&S [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts = I want to see a solution to this problem, but I think we should look at = RFC 3820, X.509 Proxy Certificate Profile. I know that this was = implemented, but I do not know if it is still in use. Russ --Apple-Mail=_E2D4A665-3400-424F-A2DC-AD42621E3074 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Wed, Apr 12, 2017 at 12:31 PM, Sean Turner <sean@sn3rd.com> wrote:
All,

At our IETF 98 session, there was support in the room to adopt draft-rescorla-tls-subcerts [0].  We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170429.  If you object to its adoption, please let us know why.

Clearly, the WG is going to need to work through the trade-offs between short-lived certificates and sub-certs because both seem, to some, to be addressing the same problem.

Cheers,

J&S

[0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts

I want to see a solution to this problem, but I think we should look at RFC 3820, X.509 Proxy Certificate Profile.  I know that this was implemented, but I do not know if it is still in use.

Russ

--Apple-Mail=_E2D4A665-3400-424F-A2DC-AD42621E3074-- From nobody Wed Apr 12 17:22:23 2017 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 1038612871F; Wed, 12 Apr 2017 17:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=q/rE21IS; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=VY+Syxc1 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 jChsyFZynkOR; Wed, 12 Apr 2017 17:22:20 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA92126C7B; Wed, 12 Apr 2017 17:22:20 -0700 (PDT) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3D0EYKH028236; Wed, 12 Apr 2017 17:22:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=lOvrvnTKGyvepKnEWFMn6TjSepF+HjitEYPf9kO/8KE=; b=q/rE21ISTLJr+MmPHMN5goh+mElNGrIiFgaiNnEeKeWfTyfHhFuZffzTl2qYjyfWXoGQ p2lAwPysspTzJ+mBat454hAOQrxqw3cC6sqFHPO50c4jxCcMRMPj6A3Nv1SrXbc9aLAw cYT1dz0eEi11KgphYG3bUOBXK6RBReLCENk= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 29sv7krgv6-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Apr 2017 17:22:17 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.12) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 12 Apr 2017 17:22:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lOvrvnTKGyvepKnEWFMn6TjSepF+HjitEYPf9kO/8KE=; b=VY+Syxc1YliOTF4sLh30+8VwZAaKHXghG0PgLRYGtyWGjFKsuJEbcmIGpDlJtun4Dai9YA1m9yeCA6+HkUU7aWumdZ08iBSzfM8dILbPXsdQyYbhbna0gSCUwixpty4KH48JxLecoq26mX/xFsZaH0S658vkOxn57WsUfjr0t98= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1453.namprd15.prod.outlook.com (10.173.234.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Thu, 13 Apr 2017 00:22:13 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1019.026; Thu, 13 Apr 2017 00:22:13 +0000 From: Subodh Iyengar To: Russ Housley , IETF TLS , IETF LURK Thread-Topic: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts Thread-Index: AQHSs8PkSB9pjvbMn0SPx3iNAt61ZqHCPw6AgAADYQCAACoCNw== Date: Thu, 13 Apr 2017 00:22:13 +0000 Message-ID: References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1453; 7:STzBVCR2/NflJhHtZ3BMfzi3pETX19vIk6PQBChBm3IYe4EI6UVIlaJookldf4RKISwdBACYMwWitKBzWbWnAXe8YAUK3SnWk0qVF4TGXRp/amESxq0hvJIzG0dnnuq01ZKUaZb+wobDIV3Hch5PhqLnQPdFYBNfsLUpooNh+XEoBwQXBzlMIKmOm6auC1hYl7YH4BTp9NflEy0/vxHJhskB8xMK3qEw+H6YVnThzopH7uWecQRDAMo7fxmSqicZeyk4q1Rlo5d2oURja0EDINwnlIYtOdQWJdO//95aPd8nyvhby6OUP5pMlQzd9ZRSVXNDge17ukE7QCB6xN9YGw==; 20:CTq60aiazXzqN2yqaFimhHbDHsHoqfBAk43QcxdoM6NdqjlzuUTzsUpvEvdDQCBLRbzgV3gStFdGZoxwHBmAIh5/VZrucmrdfsY3b/XZdUSKPVHQu/49ln1/6MYCwYle55ZVQNxMb0b/vGribysJ22/8moSGYCjJP4O8CnZbw4k= x-ms-office365-filtering-correlation-id: 1cd5a7ef-cd3b-4495-afac-08d482032232 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR15MB1453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:MWHPR15MB1453; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1453; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39850400002)(39410400002)(39400400002)(24454002)(377454003)(76176999)(50986999)(2950100002)(38730400002)(54356999)(3846002)(6436002)(229853002)(6116002)(7696004)(102836003)(606005)(77096006)(2900100001)(6506006)(2906002)(19627405001)(122556002)(99286003)(93886004)(6246003)(189998001)(8676002)(5660300001)(230783001)(8936002)(53546009)(7906003)(7736002)(66066001)(74316002)(33656002)(3660700001)(9686003)(3280700002)(6306002)(236005)(54896002)(55016002)(53936002)(25786009)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1453; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14551FA3148E159F49CD6ECCB6020MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2017 00:22:13.4240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1453 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_18:, , signatures=0 Archived-At: Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 13 Apr 2017 00:22:22 -0000 --_000_MWHPR15MB14551FA3148E159F49CD6ECCB6020MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for adoption @Russ there's some discussion about comparison with proxy certs in the curr= ent draft. Subodh ________________________________ From: TLS on behalf of Russ Housley Sent: Wednesday, April 12, 2017 2:37:28 PM To: IETF TLS; IETF LURK Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcer= ts On Wed, Apr 12, 2017 at 12:31 PM, Sean Turner > wrote: All, At our IETF 98 session, there was support in the room to adopt draft-rescor= la-tls-subcerts [0]. We need to confirm this support on the list so please= let the list know whether you support adoption of the draft and are willin= g to review/comment on the draft before 20170429. If you object to its ado= ption, please let us know why. Clearly, the WG is going to need to work through the trade-offs between sho= rt-lived certificates and sub-certs because both seem, to some, to be addre= ssing the same problem. Cheers, J&S [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts I want to see a solution to this problem, but I think we should look at RFC= 3820, X.509 Proxy Certificate Profile. I know that this was implemented, = but I do not know if it is still in use. Russ --_000_MWHPR15MB14551FA3148E159F49CD6ECCB6020MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1 for adoption

@Russ there's some discussion about comparison with proxy certs in the curr= ent draft. 

Subodh

From: TLS <tls-bounces@i= etf.org> on behalf of Russ Housley <housley@vigilsec.com>
Sent: Wednesday, April 12, 2017 2:37:28 PM
To: IETF TLS; IETF LURK
Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls= -subcerts
 
On Wed, Apr 12, 2017 at 12:31 PM, Sean Turner <sean@sn3= rd.com> wrote:
All,

At our IETF 98 session, there was support in the room to adopt draft-rescor= la-tls-subcerts [0].  We need to confirm this support on the list so p= lease let the list know whether you support adoption of the draft and are w= illing to review/comment on the draft before 20170429.  If you object to its adoption, please let us know w= hy.

Clearly, the WG is going to need to work through the trade-offs between sho= rt-lived certificates and sub-certs because both seem, to some, to be addre= ssing the same problem.

Cheers,

J&S

[0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-su= bcerts

I want to see a solution to this problem, but I think we sh= ould look at RFC 3820, X.509 Proxy Certificate Profile.  I know t= hat this was implemented, but I do not know if it is still in use.

Russ

--_000_MWHPR15MB14551FA3148E159F49CD6ECCB6020MWHPR15MB1455namp_-- From nobody Thu Apr 13 02:01:12 2017 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 20507131842 for ; Thu, 13 Apr 2017 02:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=gmail.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 AaRMBKSs081O for ; Thu, 13 Apr 2017 02:01:08 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 1468B13182A for ; Thu, 13 Apr 2017 01:54:27 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id 75so26265756lfs.2 for ; Thu, 13 Apr 2017 01:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ohJUUXGgF7ArIlkyEXDg9U/RTf0EDdQKGROtejDG6io=; b=FQZ4SVxdJ1BBuCI23BL1DOTQ0D1LBDm5vFcWfxyP/gTGIBeQLYepmx8SBJ1poKuCvj p7dvONQ6lCyjX1bTq3WmPrJSjccEA8ECANbuzLmG4ZJR1yyzobFw1e8mWlfghPS8N3ym 00lQOv4CC/lmMjuJBAVwRcCfGsnAw9qJykek0RPm6IW8nP25uDKLiQqmQU+AavQfd0AR aUo+qVcIqDCyNGvz/9KNQsw1u743hkjXISSaq6JxDMgZK9FINO0zYtCJDqY0A3JBsFiF Y/v72WJmoRKKV26GM5FLGPA237oot3otht7xGSqmpsHqIUBT9DOggNSy18FD5FyurK/d bkEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ohJUUXGgF7ArIlkyEXDg9U/RTf0EDdQKGROtejDG6io=; b=CMt+ntDj7osWWQtQ6Vc5We672NNJ4XfoNeMqJRroCy0hzerqz+wvclLN8fX1Y65qDt d1Eo/MKdAcUIToPFXRcCGRww85D9ldHQo6rxWk7c6xRL0IscClkmMX3oNqygKz0NRFFG 9yuTYBej0Vi+txTHC+rExGOgkMizt+5VvHhonRVV/RSzjsVrmmgY1JNNyNBmaZw6t677 stfOuDunMG8MgKzPIwXA4h824IhRrQtDCH/P0itvxSHAGcA5RPruF4OzeXPLnhNlN2bJ oWKH7vAGKGAbxLn0fkyC2/1L/TsNc+nkpyYhhV0qbH3d/tq7iLdwbHOsFxy1HysOtaLO c2Tg== X-Gm-Message-State: AN3rC/7+rPmWHcObetTMEzhptR+xvGLy/JR3adQQu8jaTEvrgZOfe4b5 +fHtUW9BgctlK6zdmcbtNXiwMk41RLjF X-Received: by 10.46.75.2 with SMTP id y2mr581069lja.103.1492073665393; Thu, 13 Apr 2017 01:54:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Thu, 13 Apr 2017 01:54:24 -0700 (PDT) Received: by 10.46.83.5 with HTTP; Thu, 13 Apr 2017 01:54:24 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 13 Apr 2017 18:54:24 +1000 Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary=f403045ea6e8ce117a054d08788f Archived-At: Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 13 Apr 2017 09:01:10 -0000 --f403045ea6e8ce117a054d08788f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have reviewed the changes. They look good. I have some reservations about section 7 (implementation status) given that I expect it to date badly, but it isn't really doing any actual harm either. On 11 Apr. 2017 11:09 pm, "Sean Turner" wrote: > All, > > draft-ietf-tls-rfc4492bis has been revised since it left the WG and we > agree with Yoav=E2=80=99s statement at the mic in Chicago that the WG sho= uld review > the changes before we ask Kathleen (our newly appointed AD) to continue > progressing the draft. Please review the differences from the -12 versio= n > that went through WGLC and the latest version [0] and let us know by > 20170426 whether there is anything that would stop progression of the dra= ft. > > Thanks, > > J&S > > [0] https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls- > rfc4492bis-12&url2=3Ddraft-ietf-tls-rfc4492bis-16 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f403045ea6e8ce117a054d08788f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed the changes. They look good.=C2=A0 I have= some reservations about section 7 (implementation status) given that I exp= ect it to date badly, but it isn't really doing any actual harm either.=

On 11 Apr. = 2017 11:09 pm, "Sean Turner" <sean@sn3rd.com> wrote:
All,

draft-ietf-tls-rfc4492bis has been revised since it left the WG and we agre= e with Yoav=E2=80=99s statement at the mic in Chicago that the WG should re= view the changes before we ask Kathleen (our newly appointed AD) to continu= e progressing the draft.=C2=A0 Please review the differences from the -12 v= ersion that went through WGLC and the latest version [0] and let us know by= 20170426 whether there is anything that would stop progression of the draf= t.

Thanks,

J&S

[0] https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-rfc449= 2bis-12&url2=3Ddraft-ietf-tls-rfc4492bis-16
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--f403045ea6e8ce117a054d08788f-- From nobody Thu Apr 13 07:23:22 2017 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 02D0F120724 for ; Thu, 13 Apr 2017 07:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] 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 tSXbgdAVICmn for ; Thu, 13 Apr 2017 07:23:20 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF764129481 for ; Thu, 13 Apr 2017 07:23:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4C6F43004AA for ; Thu, 13 Apr 2017 10:23:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4WE1H6FFzdiq for ; Thu, 13 Apr 2017 10:23:18 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id F0568300261; Thu, 13 Apr 2017 10:23:17 -0400 (EDT) From: Russ Housley Message-Id: <29A92F48-525F-4166-B8E7-1C1F57DBF259@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_115CADCC-ECF9-4045-9618-383C115EC152" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 10:23:17 -0400 In-Reply-To: Cc: IETF TLS , IETF LURK To: Subodh Iyengar References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 13 Apr 2017 14:23:21 -0000 --Apple-Mail=_115CADCC-ECF9-4045-9618-383C115EC152 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Subodh: >=20 > @Russ there's some discussion about comparison with proxy certs in the = current draft.=20 >=20 Yes, I saw the list of bullets in Section 5. I think that a = TLS-specific delegation is a good idea, but I do not agree with all of = the points into bullets. That said, we should not be having that = discussion as part of the decision to adopt or not. Russ --Apple-Mail=_115CADCC-ECF9-4045-9618-383C115EC152 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Subodh:


@Russ = there's some discussion about comparison with proxy certs in the current = draft. 


Yes, I saw the list of bullets in = Section 5.  I think that a TLS-specific delegation is a good idea, = but I do not agree with all of the points into bullets.  That said, = we should not be having that discussion as part of the decision to adopt = or not.

Russ

= --Apple-Mail=_115CADCC-ECF9-4045-9618-383C115EC152-- From nobody Thu Apr 13 21:29:51 2017 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 84D89128B91 for ; Thu, 13 Apr 2017 21:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.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 w-UWsbF6LXjH for ; Thu, 13 Apr 2017 21:29:48 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 AAA6912762F for ; Thu, 13 Apr 2017 21:29:48 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id 21so39327259pgg.1 for ; Thu, 13 Apr 2017 21:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=940iSsnd5+NtSD1Y/N+Z5CnF6P3otg1SiVPulmGihio=; b=AzWFsmXEC+6+kQErPFMQ2gP2eugoO5VlQXrxQz82bVrByZH4Qy5iwGIhK3KrOwA+N3 RMEAUZcfV58ttA+3ID62h7tM8vmRMdZI6tWLeo+C8a6e/XG91xG52b2F6jdIJKo96ZvM QJSVAXHih74O/BDgECVJOzW9bDUami7eukzU19rNAX/cs1AkFXExpnqo4npH3C+CXSIu n/RnOkjpETR8Fk2miiSGjYMa+c4+JU4lexZrOBFD2yLMkZHFzDW2oJETCZqV0WTHZKjY NmTuVdc1ef0QzL2vl1ayVAnpN4mRC4KdfC9/iCTFfI8mElaMBLT83s6Uzy57S7sSs7nl 6Jbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=940iSsnd5+NtSD1Y/N+Z5CnF6P3otg1SiVPulmGihio=; b=MNGOoXhlgv1dSTWrnyQKZvI8xbDODQn3sZoGyXFrISVxkHDlijVcLHuyLswg6ZnrAl k50v4o7xGN0a6MO2Rp4jpHr8Iz8KUJCMD/9SfFLXxcN6Zq3yuER0M0eRbPiJFxIyMg9e lnQFI/DHmUSoXop6frkO/+nqjaiawizoMVQE1rZUwENo9sGHbKhr9inlrWQx32YTs9zP LTYR517+4NcESlh3zXROFx9AbJUY6wBVEU0IbNd49tXSHWJDc9ZY1yzvHA894XJI+582 voltbhrMLYozeDB3x7WBJd1ja8AueJioNDUcwjDo+vGy3ymfSEPUpq8crwSf4fO71yoO u+1w== X-Gm-Message-State: AN3rC/55El1iUTsdUSho/HdrKHPsy4oKAkCja6AQntUAVVjSUiLQbdZS owN2Zl+OMee4JkLxFRS7SthzmBQSVJ+B X-Received: by 10.99.36.194 with SMTP id k185mr5089530pgk.201.1492144188045; Thu, 13 Apr 2017 21:29:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.7 with HTTP; Thu, 13 Apr 2017 21:29:27 -0700 (PDT) From: Joseph Salowey Date: Thu, 13 Apr 2017 21:29:27 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03146c485273054d18e49b Archived-At: Subject: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 14 Apr 2017 04:29:50 -0000 --94eb2c03146c485273054d18e49b Content-Type: text/plain; charset=UTF-8 Hey Folks, At the IETF 98 meeting in Chicago there was support in the room to adopt draft-sullivan-tls-exported-authenticator [0]. We are looking for feedback on adopting this draft form the list. Please respond if you support the draft and are willing to review it. If you object to its adoption, please let us know why. Please respond to the list by 20170501 Cheers, J&S [0] https://datatracker.ietf.org/doc/html/draft-sullivan- tls-exported-authenticator --94eb2c03146c485273054d18e49b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Folks,

At the IETF 98 meeting in Chicago there was support in the room= to adopt=C2=A0draft-sullivan-tls-exported-authenticator=C2=A0[0]. We are looking for feedback on adoptin= g this draft form the list. Please respond if you support the draft and are= willing to review it. If you object to its adoption, please let us know wh= y. Please respond to the list by 20170501

Cheers,=

J&S

--94eb2c03146c485273054d18e49b-- From nobody Fri Apr 14 01:23:45 2017 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 F3001127275; Fri, 14 Apr 2017 01:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 SASwinCAO2RF; Fri, 14 Apr 2017 01:23:34 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796D7124D6C; Fri, 14 Apr 2017 01:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1492158213; x=1523694213; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=m+WL7c4SobG7jRbPLlFibPsbZjSTl0tA+vMUX59Vzaw=; b=rbKml5FvdZS/cnZtGv5Lm1XvfIHGumYhK4w+QSD+YEfzuwTPruWKqNVB zO1pRrswMRbnUCQlq6bQnRTDI3terfko3H38I7nfaJPKKoSCLznokmXKv fAmV9zz1g1sdtKScJSjVxD1QwqSWUohGryTynSDc9+hYaT4N2YVE5hyUd 6pWOAg4dgjOz+IlNo0SSRs0CMO3ES+UxsU7i508ZDBtwKPVL+Up+9AuNP 9fh6hUY8qrJSTY+tfEe5VKS2kJX4k/PCu7gUCVin/CNM7Lx2+nw6OuX6f zczshXFx1nSApmYzM30QsVxG5Y+sXERDi2ZA2cNxFB01aQPJEaDXNjLCs A==; X-IronPort-AV: E=Sophos;i="5.37,197,1488798000"; d="scan'208";a="149942244" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Apr 2017 20:23:29 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 20:23:29 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::3ccc:9df5:6df4:210e]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::3ccc:9df5:6df4:210e%14]) with mapi id 15.00.1263.000; Fri, 14 Apr 2017 20:23:29 +1200 From: Peter Gutmann To: Russ Housley , IETF TLS , IETF LURK Thread-Topic: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts Thread-Index: AQHSs8PW+bNvvlEs1UyLQIXhszxKaaHBdeSAgAADYACAAw/UNQ== Date: Fri, 14 Apr 2017 08:23:28 +0000 Message-ID: <1492158199957.63303@cs.auckland.ac.nz> References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 14 Apr 2017 08:23:36 -0000 Russ Housley writes:=0A= =0A= >I want to see a solution to this problem, but I think we should look at RF= C=0A= >3820, X.509 Proxy Certificate Profile.=A0 I know that this was implemented= , but=0A= >I do not know if it is still in use.=0A= =0A= It's fairly heavily used in grid computing.=A0 It would probably be used ou= tside=0A= that environment as well if people knew it existed, meaning that I have on = a=0A= number of occasions encountered people who needed something like proxy cert= s=0A= but were kludging around it in various ugly ways because they didn't know t= hey=0A= existed.=0A= =0A= Peter.= From nobody Fri Apr 14 04:44:33 2017 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 4ABBF12EB72 for ; Fri, 14 Apr 2017 04:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 eDi36z2aHmBK for ; Fri, 14 Apr 2017 04:44:29 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5FE12EB71 for ; Fri, 14 Apr 2017 04:44:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id C98082343C; Fri, 14 Apr 2017 14:44:26 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id n5TOtw--Vqku; Fri, 14 Apr 2017 14:44:26 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 7EC73C4; Fri, 14 Apr 2017 14:44:26 +0300 (EEST) Date: Fri, 14 Apr 2017 14:44:25 +0300 From: Ilari Liusvaara To: Joseph Salowey Cc: "tls@ietf.org" Message-ID: <20170414114425.GA3649@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 14 Apr 2017 11:44:31 -0000 On Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph Salowey wrote: > Hey Folks, > > At the IETF 98 meeting in Chicago there was support in the room to adopt > draft-sullivan-tls-exported-authenticator [0]. We are looking for feedback > on adopting this draft form the list. Please respond if you support the > draft and are willing to review it. If you object to its adoption, please > let us know why. Please respond to the list by 20170501 > Looking at the draft and reviewing it: - Section 1: The section should also say a bit why not to use post-handshake authentication. Which is not available at all for server, won't work properly with multiplexed connections, etc... - Section 2: Probable typo: "encryped" (in last line of first paragraph on page 3). - Section 2: I think there should be "(for TLS 1.3)" after reference to the TLS 1.3 draft in definition of handshake context. Otherwise it will read oddly after draft reference gets replaced by reference to the RFC. - Section 2: I think the finished MAC key length should always follow the PRF hash. TLS 1.2 with EMS requires well-defined PRF hash anyway, and some cipher- suites have SHA-1 as HMAC hash. - Section 2 I think giving random number as example of request context is bad, and one should instead give some sequence number (with possible gaps) as example. These things do not have to be random, and generating sequence numbers in connection context is much easier than random numbers. - Section 2: The spec should be clear if message headers are included or not (the hashes seem injective either way). If message headers are included, perhaps wrap the context into synthethic hash message like with first CH when retrying handshake in TLS 1.3. One could even reuse the message type (#254). - Section 4: Nitpick: The framework is usually called SIGMA, not SIGMAC (reference). - Section 4: The last two security considerations look pretty hard to understand, and overly long. As I understand it, those paragraphs mean something like: ---------------------- Authenticators are independent and unidirectional, and as consequence: * It is difficult to formally prove an endpoint is jointly authoritative over multiple certificates instead of individually authoritative over each. * There is no feedback on if authenticator was processed, at what point of connection it was processed nor if it was accepted. Any such feedback needs to be implemented at application layer.if required. ---------------------- (As note, the TLS-built-in authentication fails most of the second part as well, for various reasons. - Section 4: Perhaps add consideration that this SHOULD be implemented inside TLS library (or at least as an library), even if it is possible to implement outside it. -Ilari From nobody Fri Apr 14 04:44:53 2017 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 C7EEB12EB88 for ; Fri, 14 Apr 2017 04:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 RqGNHB6VpAB8 for ; Fri, 14 Apr 2017 04:44:44 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B6712EB78 for ; Fri, 14 Apr 2017 04:44:44 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3EBbNUQ000567 for ; Fri, 14 Apr 2017 12:44:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=aopBnBiVhbTau3eQl/vDU7asI4/nEB1Dr7MVC08+K/U=; b=LM5uWENfG1CdoCJ+tKSFRZOSq1mAEKJrak+btzVcn96SLNfR/7XWbJwaHM69YLHjht9k mjimNhdY30h4UQuWRAaEA650SqfGHQ9+88RSdlNZNpwQUfy39OgdXA3gRFpzGFMoSTOq WTVOu82plEh8a/gCBcAMQsF2puvhk0hWYoYdLN9FOzv2K7y9Puz+sSrBaz4sCLiPHIX3 R+F1m0HOpvIwHcOecaWsi77auNg5pTIkDZkrixUadOXS4lZYrVoigi/79s7bJjMRBIPs Y4sYVP6oj2QUfFwiU72jdXSBW07g4G1Ed73ucemR8be/sXz6jEXPRFlOALoiEBJ+BwGY hQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 29ts9rs4cb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 14 Apr 2017 12:44:42 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3EBg7HP029817 for ; Fri, 14 Apr 2017 07:44:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 29pu6v0f78-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 14 Apr 2017 07:44:41 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 14 Apr 2017 06:44:40 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1178.000; Fri, 14 Apr 2017 06:44:40 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: Hugo makes good :) Thread-Index: AdK1FBeyyOQAtSlsQ6+Dh9+l5BsPGQ== Date: Fri, 14 Apr 2017 11:44:39 +0000 Message-ID: <991672838ff04eddbe43954a911014ef@ustx2ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.234] Content-Type: multipart/alternative; boundary="_000_991672838ff04eddbe43954a911014efustx2exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=1 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704140102 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=14 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704140102 Archived-At: Subject: [TLS] Hugo makes good :) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 14 Apr 2017 11:44:52 -0000 --_000_991672838ff04eddbe43954a911014efustx2exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I know it's a little off-topic for this list, but this is pretty amazing. https://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2017/hugo_m_krawczyk.ht= ml Wow. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_991672838ff04eddbe43954a911014efustx2exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I know it’s a little off-topic for this list, = but this is pretty amazing.

 

https://www.ibm.com/ibm/ideasfromibm/= us/ibm_fellows/2017/hugo_m_krawczyk.html

 

Wow. 

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_991672838ff04eddbe43954a911014efustx2exdag1mb1msgcorpak_-- From nobody Fri Apr 14 06:01:09 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2E12EC81; Fri, 14 Apr 2017 06:01:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149217486802.14945.5860839126420450278.idtracker@ietfa.amsl.com> Date: Fri, 14 Apr 2017 06:01:08 -0700 Archived-At: Subject: [TLS] The TLS WG has placed draft-sullivan-tls-exported-authenticator in state "Call For Adoption By WG Issued" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 14 Apr 2017 13:01:08 -0000 The TLS WG has placed draft-sullivan-tls-exported-authenticator in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-sullivan-tls-exported-authenticator/ From nobody Fri Apr 14 07:30:18 2017 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 D29E812F3D5 for ; Fri, 14 Apr 2017 07:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xwRnt_uRhXux for ; Fri, 14 Apr 2017 07:30:15 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 8EC8212F3CB for ; Fri, 14 Apr 2017 07:30:15 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id 72so35845545pge.2 for ; Fri, 14 Apr 2017 07:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RP9THEqrg5COeZrPM0FuD50/nvg6s67bXWcMk+B7LZo=; b=gRVzPCQtaWN/E7bP7MXYmgIwh6idcBm6x81RDBWm6ZqszFVieQygFHEc/Neg39RLU+ dPeVcONgV86oLZg1/WVGvtUSUfkgmfr9FZdAW86lFhJHL26SrmvvotX+CR4J548hedRP WQIEEMw1wREwkijcAmRYmekf5j0XQ/5z79zSJjXNRAX5MGiZP4b3drv2BqTGyp5u+cGg r2WWjs7/a0qhKQoL6C7Bk/lH5toKjBtnEkcfCcX51jzNWDODcZuHkf41/vlr8XklrHa8 NB+NpGEj9a9GJqBrzXV0iVh4yr12Y2LEbyOUE8LUhpjmUR7he0vs44Qq8TjWCpZBiyX0 opag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RP9THEqrg5COeZrPM0FuD50/nvg6s67bXWcMk+B7LZo=; b=S2KWrQwakuUUOZm5Mbboa1V4tehJTFa5+ZSp2HP2q4vJ5NvHaa3usmAw9wJdqFg4N9 DnYGk33L+V//VmmhkfXqXDoQ7/AsFtVu9HDvwmlpiI+mcvHZ0Ws8nc4b1Uq3VrxL1cQq zPJUL1IAgPkJicKWXJdPgS+YDK8OJD6e6Mg8tl9Dl8JZV0P9GwZnTdOopQ6zBAtJsac6 6oF8C2KYFLCidjXYrkFnudtorZGFKU1B2MpAadZMV/Ty7aPaS9TlVCZMZ2jOGd7/aOkd NepFYXPwB4qPjfAMVavz4bfEsNh7kz6LgvrCHZ2A72O/eixxd2WtKZx4VNnhUPDS5TyE MNfg== X-Gm-Message-State: AN3rC/70P9wGxXFYl5e+d61z4JgD6A5vhAnhj8XvwVDob0RKGGMq2+4L 7vLI+2oeK6k/TT5au4VHwEL83t1zIw== X-Received: by 10.98.29.86 with SMTP id d83mr7509700pfd.68.1492180215145; Fri, 14 Apr 2017 07:30:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.41 with HTTP; Fri, 14 Apr 2017 07:29:34 -0700 (PDT) In-Reply-To: <991672838ff04eddbe43954a911014ef@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <991672838ff04eddbe43954a911014ef@ustx2ex-dag1mb1.msg.corp.akamai.com> From: Kathleen Moriarty Date: Fri, 14 Apr 2017 10:29:34 -0400 Message-ID: To: "Salz, Rich" Cc: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Hugo makes good :) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 14 Apr 2017 14:30:17 -0000 Congratulations, Hugo! Thanks for sharing the news. On Fri, Apr 14, 2017 at 7:44 AM, Salz, Rich wrote: > I know it=E2=80=99s a little off-topic for this list, but this is pretty = amazing. > > > > https://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2017/hugo_m_krawczyk.= html > > > > Wow. > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Best regards, Kathleen From nobody Fri Apr 14 10:45:13 2017 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 DE09D1294D3 for ; Fri, 14 Apr 2017 10:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 aMbZcHE_ObYv for ; Fri, 14 Apr 2017 10:45:09 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0100.outbound.protection.outlook.com [104.47.40.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819041294F5 for ; Fri, 14 Apr 2017 10:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p1JNdmLvcSMPikIozSP+yCphZVE7RgJPAYK+1F6uSiM=; b=GyW3RV38V2pEALV8loMd8S6FVJsVamT06UZ6C1bXCZ6naI6Fd+gfQ+f37f8E18aXpjB+ITrFYGaLm2icGe4qPHo9LeCU1/3qfDvChivC9hAIYOh5Jd3o4rDpi35qPVPeIb+dS8HESFO5j/bYZQTUKLiwJZEDQtenGJtOPT/2Ysw= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0090.namprd21.prod.outlook.com (10.161.141.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.0; Fri, 14 Apr 2017 17:45:08 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.1047.008; Fri, 14 Apr 2017 17:45:08 +0000 From: Andrei Popov To: Joseph Salowey , "tls@ietf.org" Thread-Topic: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator Thread-Index: AQHStNfKNo8KeaT+0UG46Iwy0tFUzaHFI1gQ Date: Fri, 14 Apr 2017 17:45:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: salowey.net; dkim=none (message not signed) header.d=none;salowey.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0090; 7:ACuGX6Tyl83YJz7f92zO2vFYniUtFraemck2XnN7bw79yiFWE5rnIW38CjQ1IhGzU2FLyY24RIvlgOWAfpPOrSy334gleZ7Ou3HMPBG9kQSHOcY7vsOzKu8wYRpdxk+zrXiMtU/9rWYzRwAhqa0YMBoIqh2jSIyYMAcr+aVaIcKAh+u489D29+kZFwXgVOce+09NXGlzy8Xaf5dwxCnkI+dSHF1Ht9TJ0OLIDzIbU1zwst7A/chqId887TME2Cn8ZRY9rIPsi5I0UZRm+79Rt3YWgg+A+PZBM71pb2kZwCtzJ/CLPj4C+aUPARVDnbwzCWb/jKvBmNuAtGWqFt0OlH5676Jbs3mmGdfRZT8I7jU= x-ms-office365-filtering-correlation-id: 6fec3a2b-db01-428a-d684-08d4835dfe1e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR21MB0090; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:DM2PR21MB0090; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0090; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39840400002)(39860400002)(39850400002)(377454003)(81166006)(8676002)(74316002)(86362001)(10090500001)(230783001)(6506006)(6246003)(53936002)(53546009)(2501003)(8936002)(7906003)(86612001)(7736002)(25786009)(19609705001)(3660700001)(122556002)(5660300001)(2900100001)(54356999)(50986999)(3280700002)(2906002)(77096006)(7696004)(6116002)(790700001)(102836003)(33656002)(76176999)(38730400002)(5005710100001)(8990500004)(10290500002)(2950100002)(9686003)(54896002)(6306002)(99286003)(55016002)(236005)(229853002)(189998001)(6436002)(606005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0090; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR21MB0091EE2546F874444B537F2B8C050DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2017 17:45:08.2369 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0090 Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 14 Apr 2017 17:45:12 -0000 --_000_DM2PR21MB0091EE2546F874444B537F2B8C050DM2PR21MB0091namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIGJlZW4gcmV2aWV3aW5nIHRoaXMgZHJhZnQgYW5kIHN1cHBvcnQgaXRzIGFkb3B0aW9u Lg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvc2VwaCBTYWxvd2V5DQpTZW50OiBUaHVyc2RheSwgQXBy aWwgMTMsIDIwMTcgOToyOSBQTQ0KVG86IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogW1RMU10gQ2Fs bCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtc3VsbGl2YW4tdGxzLWV4cG9ydGVkLWF1dGhlbnRpY2F0 b3INCg0KSGV5IEZvbGtzLA0KDQpBdCB0aGUgSUVURiA5OCBtZWV0aW5nIGluIENoaWNhZ28gdGhl cmUgd2FzIHN1cHBvcnQgaW4gdGhlIHJvb20gdG8gYWRvcHQgZHJhZnQtc3VsbGl2YW4tdGxzLWV4 cG9ydGVkLWF1dGhlbnRpY2F0b3IgWzBdLiBXZSBhcmUgbG9va2luZyBmb3IgZmVlZGJhY2sgb24g YWRvcHRpbmcgdGhpcyBkcmFmdCBmb3JtIHRoZSBsaXN0LiBQbGVhc2UgcmVzcG9uZCBpZiB5b3Ug c3VwcG9ydCB0aGUgZHJhZnQgYW5kIGFyZSB3aWxsaW5nIHRvIHJldmlldyBpdC4gSWYgeW91IG9i amVjdCB0byBpdHMgYWRvcHRpb24sIHBsZWFzZSBsZXQgdXMga25vdyB3aHkuIFBsZWFzZSByZXNw b25kIHRvIHRoZSBsaXN0IGJ5IDIwMTcwNTAxDQoNCkNoZWVycywNCg0KSiZTDQoNClswXSBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXN1bGxpdmFuLXRscy1leHBv cnRlZC1hdXRoZW50aWNhdG9yPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZo dG1sJTJGZHJhZnQtc3VsbGl2YW4tdGxzLWV4cG9ydGVkLWF1dGhlbnRpY2F0b3ImZGF0YT0wMiU3 QzAxJTdDQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3QzNhZjU1Y2Y3NzZjNTRjZjY1NWIz MDhkNDgyZWVlYTU3JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNjI3NzQxMDAyODkzMjM4OCZzZGF0YT0yZ2xaSkgxUEZvMzU1JTJGOTRWa0FqMGdXNk1jalNh eUQlMkJWJTJGR2R0amNXTDBvJTNEJnJlc2VydmVkPTA+DQo= --_000_DM2PR21MB0091EE2546F874444B537F2B8C050DM2PR21MB0091namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J 4oCZdmUgYmVlbiByZXZpZXdpbmcgdGhpcyBkcmFmdCBhbmQgc3VwcG9ydCBpdHMgYWRvcHRpb24u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QW5kcmVpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUTFMgW21haWx0bzp0 bHMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+Sm9zZXBoIFNhbG93ZXk8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDEzLCAyMDE3IDk6MjkgUE08YnI+DQo8 Yj5Ubzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbVExTXSBDYWxsIGZv ciBhZG9wdGlvbiBvZiBkcmFmdC1zdWxsaXZhbi10bHMtZXhwb3J0ZWQtYXV0aGVudGljYXRvcjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dCI+SGV5IEZvbGtzLDxicj4NCjxicj4NCkF0IHRoZSBJRVRGIDk4IG1lZXRpbmcgaW4gQ2hpY2Fn byB0aGVyZSB3YXMgc3VwcG9ydCBpbiB0aGUgcm9vbSB0byBhZG9wdCZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5kcmFmdC1zdWxsaXZhbi10bHMtZXhwb3J0ZWQtYXV0aGVudGljYXRvcjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4mbmJzcDtbMF0uIFdlIGFyZSBsb29raW5n IGZvciBmZWVkYmFjayBvbg0KIGFkb3B0aW5nIHRoaXMgZHJhZnQgZm9ybSB0aGUgbGlzdC4gUGxl YXNlIHJlc3BvbmQgaWYgeW91IHN1cHBvcnQgdGhlIGRyYWZ0IGFuZCBhcmUgd2lsbGluZyB0byBy ZXZpZXcgaXQuIElmIHlvdSBvYmplY3QgdG8gaXRzIGFkb3B0aW9uLCBwbGVhc2UgbGV0IHVzIGtu b3cgd2h5LiBQbGVhc2UgcmVzcG9uZCB0byB0aGUgbGlzdCBieSAyMDE3MDUwMTxicj4NCjxicj4N CkNoZWVycyw8YnI+DQo8YnI+DQpKJmFtcDtTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlswXSZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtc3VsbGl2YW4tdGxz LWV4cG9ydGVkLWF1dGhlbnRpY2F0b3ImYW1wO2RhdGE9MDIlN0MwMSU3Q0FuZHJlaS5Qb3BvdiU0 MG1pY3Jvc29mdC5jb20lN0MzYWY1NWNmNzc2YzU0Y2Y2NTViMzA4ZDQ4MmVlZWE1NyU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyNzc0MTAwMjg5MzIzODgm YW1wO3NkYXRhPTJnbFpKSDFQRm8zNTUlMkY5NFZrQWowZ1c2TWNqU2F5RCUyQlYlMkZHZHRqY1dM MG8lM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXN1bGxpdmFuLXRscy1leHBvcnRlZC1hdXRoZW50aWNh dG9yPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_DM2PR21MB0091EE2546F874444B537F2B8C050DM2PR21MB0091namp_-- From nobody Fri Apr 14 11:23:51 2017 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 7A74F12951D for ; Fri, 14 Apr 2017 11:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 sZhVX0pL0hr1 for ; Fri, 14 Apr 2017 11:23:48 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8440B129529 for ; Fri, 14 Apr 2017 11:23:48 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AD5BC433421; Fri, 14 Apr 2017 18:23:47 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7FF2F43340B; Fri, 14 Apr 2017 18:23:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1492194227; bh=49M8L47PnDbHh/CStYHaltlyP87uiIblkagMAKhLGwE=; l=6887; h=To:References:From:Date:In-Reply-To:From; b=JPpCqFxsNn2Ym8XtJZdrXvVSgbQ1F3V916eUBHfvDYnyzab1Qj4TOF5NAn7Iqckcz PaKfkDtU/jYFCTjgblO5rqOoGCvjZT7+YhJ8EWa2bvabbcwthnVyQLEySvuZmV6tTZ PvsmmpJwdC+5QxX1MszIakEUTbOokkIUihm5rPek= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 50A8D1FCA7; Fri, 14 Apr 2017 18:23:47 +0000 (GMT) To: Joseph Salowey , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <905ceb46-5b7d-ec5e-f3b1-f112076ceabf@akamai.com> Date: Fri, 14 Apr 2017 13:23:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6391B66F59B030D64B9B3DB5" Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 14 Apr 2017 18:23:50 -0000 This is a multi-part message in MIME format. --------------6391B66F59B030D64B9B3DB5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit I've also been reviewing this draft and support its adoption. -Ben On 04/14/2017 12:45 PM, Andrei Popov wrote: > > I’ve been reviewing this draft and support its adoption. > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Joseph Salowey > *Sent:* Thursday, April 13, 2017 9:29 PM > *To:* tls@ietf.org > *Subject:* [TLS] Call for adoption of > draft-sullivan-tls-exported-authenticator > > > > Hey Folks, > > At the IETF 98 meeting in Chicago there was support in the room to > adopt draft-sullivan-tls-exported-authenticator [0]. We are looking > for feedback on adopting this draft form the list. Please respond if > you support the draft and are willing to review it. If you object to > its adoption, please let us know why. Please respond to the list by > 20170501 > > Cheers, > > J&S > > > > [0] https://datatracker.ietf.org/doc/html/draft-sullivan-tls-exported-authenticator > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------6391B66F59B030D64B9B3DB5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I've also been reviewing this draft and support its adoption.

-Ben

On 04/14/2017 12:45 PM, Andrei Popov wrote:

I’ve been reviewing this draft and support its adoption.

 

Cheers,

 

Andrei

 

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey
Sent: Thursday, April 13, 2017 9:29 PM
To: tls@ietf.org
Subject: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator

 

Hey Folks,

At the IETF 98 meeting in Chicago there was support in the room to adopt draft-sullivan-tls-exported-authenticator [0]. We are looking for feedback on adopting this draft form the list. Please respond if you support the draft and are willing to review it. If you object to its adoption, please let us know why. Please respond to the list by 20170501

Cheers,

J&S

 



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--------------6391B66F59B030D64B9B3DB5-- From nobody Fri Apr 14 12:48:13 2017 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 755F6129AA7 for ; Fri, 14 Apr 2017 12:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.724 X-Spam-Level: X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 bQn5i6uVlUWy for ; Fri, 14 Apr 2017 12:48:09 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 16738129533 for ; Fri, 14 Apr 2017 12:48:08 -0700 (PDT) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by linode64.ducksong.com (Postfix) with ESMTPSA id 44CE33A0A4 for ; Fri, 14 Apr 2017 15:48:08 -0400 (EDT) Received: by mail-qk0-f173.google.com with SMTP id d131so73551588qkc.3 for ; Fri, 14 Apr 2017 12:48:08 -0700 (PDT) X-Gm-Message-State: AN3rC/7Ye6FJLDSlhfinqVWvqhPOSJaPi4fygrjHBAI0FQNqi8CYL3fe WgiWU/VeDButG0Sthcjz7qpXdf9CTg== X-Received: by 10.233.239.18 with SMTP id d18mr7879173qkg.313.1492199288028; Fri, 14 Apr 2017 12:48:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.177.130 with HTTP; Fri, 14 Apr 2017 12:48:06 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Fri, 14 Apr 2017 15:48:06 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Joseph Salowey Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c04b5ee7f4392054d25b825 Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 14 Apr 2017 19:48:11 -0000 --94eb2c04b5ee7f4392054d25b825 Content-Type: text/plain; charset=UTF-8 I have read this draft and believe the final consensus version of this function will be of high value to the HTTP ecosystem in particular - I support TLS-WG adopting it. On Fri, Apr 14, 2017 at 12:29 AM, Joseph Salowey wrote: > Hey Folks, > > At the IETF 98 meeting in Chicago there was support in the room to adopt > draft-sullivan-tls-exported-authenticator [0]. We are looking for > feedback on adopting this draft form the list. Please respond if you > support the draft and are willing to review it. If you object to its > adoption, please let us know why. Please respond to the list by 20170501 > > Cheers, > > J&S > > [0] https://datatracker.ietf.org/doc/html/draft-sullivan-tls > -exported-authenticator > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c04b5ee7f4392054d25b825 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have read this draft and believe the final consensus ver= sion of this function will be of high value to the HTTP ecosystem in partic= ular - I support TLS-WG adopting it.
On Fri, Apr 14, 2017 at 12:29 AM, Joseph Salow= ey <joe@salowey.net> wrote:
=
Hey Folks,

At the IETF 98 meeting in Chicago there was support in the room= to adopt=C2=A0draft-sullivan-tls-exported-authenticator= =C2=A0[0]. We are looking fo= r feedback on adopting this draft form the list. Please respond if you supp= ort the draft and are willing to review it. If you object to its adoption, = please let us know why. Please respond to the list by 20170501

Cheers,

J&S


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--94eb2c04b5ee7f4392054d25b825-- From nobody Sat Apr 15 06:42:00 2017 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 84781120727 for ; Sat, 15 Apr 2017 06:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 oTV0TCFBYkng for ; Sat, 15 Apr 2017 06:41:56 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7F05712709D for ; Sat, 15 Apr 2017 06:41:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 777891FCA4 for ; Sat, 15 Apr 2017 16:41:53 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 4NEfDv41NISQ for ; Sat, 15 Apr 2017 16:41:53 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 32D5521C for ; Sat, 15 Apr 2017 16:41:53 +0300 (EEST) Date: Sat, 15 Apr 2017 16:41:52 +0300 From: Ilari Liusvaara To: "tls@ietf.org" Message-ID: <20170415134152.GA7893@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170414114425.GA3649@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170414114425.GA3649@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 15 Apr 2017 13:41:58 -0000 On Fri, Apr 14, 2017 at 02:44:25PM +0300, Ilari Liusvaara wrote: > On Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph Salowey wrote: > > Hey Folks, > > > > At the IETF 98 meeting in Chicago there was support in the room to adopt > > draft-sullivan-tls-exported-authenticator [0]. We are looking for feedback > > on adopting this draft form the list. Please respond if you support the > > draft and are willing to review it. If you object to its adoption, please > > let us know why. Please respond to the list by 20170501 > > > > Looking at the draft and reviewing it: Another edge-case I figured: How do certificate type extensions (#9, #19 and #20) work with exported authenticators? Where other extensions are either meaningless or are edditional info, certificate types actually change the format of the first certificate, which the library needs to understand in order to extract the SPKI for validating the following CertificateVerify. -Ilari From nobody Sun Apr 16 11:43:24 2017 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 26892127775 for ; Sun, 16 Apr 2017 11:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 7NcQjQnTc6ia for ; Sun, 16 Apr 2017 11:43:20 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 7C301124B0A for ; Sun, 16 Apr 2017 11:43:20 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l189so49407317ywb.0 for ; Sun, 16 Apr 2017 11:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=FpfzRQ7Ilr/wzIPjnMx4C7z5B5ORG0CZ8Hy4kZc99+M=; b=LgcB1Yu7yhMVv1IlJPe8Sts9+FUgWRYP+RgBWOBJV7tT0T2eHh9sDVfNW6/MlE0SB8 zlKwlpw83K6WTi/caoA7NLnNxhIhDu/zrsGo2Yzki8+kruj4rT8Kn7XhD9nQb+sHoDAS zEZnwNhh7FLQU9o3lYbW3oORw3LdcVHVRhCeaLO/DMMiA0G6kGPcUiTDx11ByvKMzjNI BfAQLSTXpwuH5ypXsTK02eeIzMWWc1fkJslZHfgEPRn1NLzrJleOkvsN4nOz4eNoBUI4 zQOvOH6Cos5ZW5QL9JqllVoE7QPFk6ldAz3bsRHvyHy/wPejBkxklhZmxjSQsYtLV7gj mh+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FpfzRQ7Ilr/wzIPjnMx4C7z5B5ORG0CZ8Hy4kZc99+M=; b=ZS3g8ghhT1ChDAUAjrhy+1xqHjaUk/3v7i7woREINKkCQPOSSby+pc98dVp8pb6L9c OsYT6KLQCEtvLHwFp81YuFkTlvYR7McKfLLAi3BWHFh5UuHilynS49w/eZbPR9RiuDNa ohIb5dVwdBErDkcY7kWkDzbA7bKTyp6N81YDRY3hwCkCuj4VNrDxceV62uxtV8julrmq khvd9q1jvpqI6qBqHKXJkzfQb1E0w29lgqLrPbdxGeotVLYpNrErvQh/3g7S4Jcyt7yK T/hAcU7/JyyMdgsZan0XGFAHcKsZfgyk8YYIZUzCWHjrrvkirhdkoGPzeZhA31JoXDjg g9dQ== X-Gm-Message-State: AN3rC/7p76ZXfO0PcTXWX2hLLGfLAyDxvgg/3kbgCivGNWq7/ugDLA4y D9qkN+X6L9nj1VGz9AfjQp+M2K76JB6eSZs= X-Received: by 10.129.51.131 with SMTP id z125mr14297668ywz.87.1492368199582; Sun, 16 Apr 2017 11:43:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Sun, 16 Apr 2017 11:42:39 -0700 (PDT) From: Eric Rescorla Date: Sun, 16 Apr 2017 11:42:39 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1142165c691e99054d4d0c19 Archived-At: Subject: [TLS] PR#950: Unpredictable certificate_request_context values. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 16 Apr 2017 18:43:22 -0000 --001a1142165c691e99054d4d0c19 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/950 Target merge date: Tuesday I have just posted PR#950, which recommends that servers generate unpredictable context values for CertificateRequest in post-handshake client authentication. This prevents attacks in which an attacker who has temporary access to the client's private key can forge valid CertificateVerify messages. Note that this is not an enormously large improvement because an attacker who has temporary access the private key can do a bunch of other stuff, like forging a complete handshake message, but I can imagine some artificial scenarios where it might be useful, for instance if the user's private key is an HSM and so the attacker has permanent control of the user's machine but can't get him to generate an arbitrary number of private key operations without detection. Unless I have missed something, this seems like harmless advice, so I tend to think we should add it. Comments welcome -Ekr --001a1142165c691e99054d4d0c19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
h= ttps://github.com/tlswg/tls13-spec/pull/950
Target merge date: Tues= day

I have just posted PR#950, which recommend= s that servers generate unpredictable
context values for CertificateReq= uest in post-handshake client authentication. This
prevents attac= ks in which an attacker who has temporary access to the client's
<= div>private key can forge valid CertificateVerify messages.

<= /div>
Note that this is not an enormously large improvement because an = attacker who
has temporary access the private key can do a bunch = of other stuff, like forging
a complete handshake message, but I = can imagine some artificial scenarios
where it might be useful, f= or instance if the user's private key is an HSM and
so the at= tacker has permanent control of the user's machine but can't get hi= m
to generate an arbitrary number of private key operations witho= ut detection.

Unless I have missed something= , this seems like harmless advice, so I tend
to think we should a= dd it. Comments welcome

-Ekr

<= div>

--001a1142165c691e99054d4d0c19-- From nobody Mon Apr 17 06:47:22 2017 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 EDD3612F258 for ; Mon, 17 Apr 2017 06:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham 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 IGrhQ7jbglAB for ; Mon, 17 Apr 2017 06:47:19 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 6202212ECA1 for ; Mon, 17 Apr 2017 06:47:19 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id 62so738135ybg.2 for ; Mon, 17 Apr 2017 06:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=bA+boNa9Nkh9b1gtiMwqwkUWRR5F//g6XjLUe3X+A54=; b=A70ZJOY/3zm/bCSgrMgmFEhqoz0OGwu9Gh2HAtVa4YSXRRMB68RFAbUcwUKf8LylPR 7ViUfwPuhtMBYwWyANqPARIkeC+HBLze+2i0QhZMuNc1/yXKTcDPPxXqhEbUVsznHw+/ rRglRCZBj/K2d7oPBoOKs29wYYYyqYR6khTTVtzhoyU2DxsvlQgu1LGAMm1dlgMKf269 7mVA3UxI7myFzye1Hxh5O+7y65GkcNXbzeI8HLMwbZtcM6Dy8lteYaWzBdZaw1bLBUAt 9I0CgcFRuNc1ATG/yQEIy7t9wgiWqKvRfzfrL/Wk2WNMZGcNObf6zktdmwVA0zCNIyTU IQNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bA+boNa9Nkh9b1gtiMwqwkUWRR5F//g6XjLUe3X+A54=; b=QTcZKtz/682uaJ8RZkUGBZC+KgLUS4n6JoxgR1uDNgrxxS5eYZk5mSjE7WeYsN2K0l Mc28L31Pau+Zx6hvUw9ejhZVdd0ODhfxN6vxxGp9JQtFN0UoWS1kxLDSrBrFkexVMS0D gNHdQAT35NFEo5eVGqXoH6YK3wY2f7sSqJ3sARVXlCGG320U5h2mGvTXl65B1oVQw9xp C1Rd62dpJBUrzWH7dEgDciBq5q7KMsf9mRDiz0hsfqfYA1dWd59iTjwEbnX+6OiNxekp MwKigwG5j/UoXpoZf41w7DYxpQKS4ftHo5DgVACoVzRUYM0fK3rfvuFLPYCXtLWccm4v r/xw== X-Gm-Message-State: AN3rC/7IO43MsEzhNQzhDrT015dMvGqa6KSaRs6ssANKto5+XD8wri2/ +2ueXtFaDDtH/AQmXbpV6GgV+AiJ6Eg23vw= X-Received: by 10.37.81.129 with SMTP id f123mr16185126ybb.161.1492436838555; Mon, 17 Apr 2017 06:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 17 Apr 2017 06:46:38 -0700 (PDT) From: Eric Rescorla Date: Mon, 17 Apr 2017 09:46:38 -0400 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113db1f49cbce3054d5d07b1 Archived-At: Subject: [TLS] PR#943: Anti-downgrade for TLS 1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 17 Apr 2017 13:47:21 -0000 --001a113db1f49cbce3054d5d07b1 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/948 Target merge date: Tuesday In Nikos's last call comments, he pointed out that we don't have any anti-downgrade for TLS 1.3/2. -> TLS 1.0. That's probably not optimal, so I've updated the text to use the same sentinel for TLS 1.0 as TLS 1.1. This won't let you detect downgrade from TLS 1.1 to TLS 1.0, but that seems like it's something we can live with as we want people to use 1.3 or failing that 1.2. -Ekr --001a113db1f49cbce3054d5d07b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
h= ttps://github.com/tlswg/tls13-spec/pull/948
Target merge date: Tues= day

In Nikos's last call comments, he pointed ou= t that we don't have any anti-downgrade
for TLS 1.3/2. -> = TLS 1.0. That's probably not optimal, so I've updated the text to u= se
the same sentinel for TLS 1.0 as TLS 1.1. This won't let y= ou detect downgrade from
TLS 1.1 to TLS 1.0, but that seems like = it's something we can live with as we want
people to use 1.3 = or failing that 1.2.

-Ekr



--001a113db1f49cbce3054d5d07b1-- From nobody Mon Apr 17 11:23:45 2017 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 AAE0612EAF1 for ; Mon, 17 Apr 2017 11:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7qScU-hZeZJn for ; Mon, 17 Apr 2017 11:23:42 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 1612A131761 for ; Mon, 17 Apr 2017 11:23:36 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id a140so11914394ita.0 for ; Mon, 17 Apr 2017 11:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=FpwrN5Vd9tI78IkpefuMLEcIUk4Rumb5kdk8uIw2sBw=; b=C87HehWvfyqTZbuHme1MJuAPW+Z8jylgHGjNDOBsLKWFq7QWefPmsqIt1U2luqDj0i RxXrxpP+gVdjmTRAut1i3LD2CxF4sYIenHCCd7i9ZyhiRAnytdLIIyU4EDy01NdcdYGc SoEJTrwkwuDbIgkuHDJmTiNkVD0MuUinFXk71bFrwsYdxoNGSduGhIKWIEswwsYkQn4d KuXn8/DqTfP988pmVD4lb15vHgJUMu9CJBPi+aBKQCsErXDXBfh0IK0WQQ05F4YG7af0 bVbUnv6l/xhhYXIdNiYZUZ+S5g+2tYQDt1Bia7ldUb1npT6huvUp9cdv4e5tqJb+Qo0r +aWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=FpwrN5Vd9tI78IkpefuMLEcIUk4Rumb5kdk8uIw2sBw=; b=Uaxs7ch329Eo2UB2W1wVAUfvGRE+NXJbzxu+UqyiaZ1cuUSFdae9CXJkgLBO6/2nvW kpG9Z5TW2NKIzxAT7Cs/Pba6iaAEGQujcE/CIW3pqbbv2CTfhVg/DprJ5OCSTEfRgmgH O78hte4YZPxkKR0KPMBRMY9PtxJlrR7YQ0KaV3Fsd1MZFxcPmsPn9rJnXuUce959SmoT 1GwrWLA9JWsVIbM1zuYqON0DMKjMDKYPa+vJN/EN1pgyyKBZYbzT1tah1E3YUGtL+Rmy 0fUZDMVrZtpgvmKeytG7tEgpzVsK2zsB5A7mgNtSWfQJGo7wvv3aZqUcsDwYc5vg6xOo OAAA== X-Gm-Message-State: AN3rC/7bOjKY4URvRjJ2UVc07kXUb5l8YnEPVSaX5WBUNZ1+EC2GHDqZ 6j5Yk7mGppr62Ew7QE8= X-Received: by 10.36.2.205 with SMTP id 196mr9813497itu.63.1492453415153; Mon, 17 Apr 2017 11:23:35 -0700 (PDT) Received: from stebila-imac.cas.mcmaster.ca (stebila-imac.cas.McMaster.CA. [130.113.68.195]) by smtp.gmail.com with ESMTPSA id f196sm6261571itc.2.2017.04.17.11.23.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 11:23:34 -0700 (PDT) From: Douglas Stebila Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Mon, 17 Apr 2017 14:23:32 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] AdditionalKeyShare Internet-Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 17 Apr 2017 18:23:44 -0000 Dear TLS mailing list, We have posted an Internet-Draft https://tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00 for using an additional key share in TLS 1.3. The intended use case is = to provide support for transitional key exchange mechanisms in which both a pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are = used. (Google's experiment with New Hope in 2016 had such an arrangement.) Our = draft replicates the functionality of the KeyShare extension in a new = extension called AdditionalKeyShare. Like KeyShare, the client's AdditionalKeyShare = contains a vector of KeyShareEntry structs. The server can respond with a single = matching KeyShareEntry in the AdditionalKeyShare extension of its ServerHello. = The resulting additional shared secret is included in the TLS key schedule = after the ECDH shared secret. While the motivation for our Internet-Draft is to facilitate the = transition to post-quantum algorithms, our Internet-Draft does not specify any = post-quantum algorithms. There are a couple of items for discussion related to this draft: - We only provide a mechanism for a single AdditionalKeyShare, thus = leading to the session establishing at most PSK + ECDHE + 1 additional shared = secret. Is there a value in even more shared secrets than that? Will someone = want to include more than one post-quantum algorithm? If so, our draft = could be adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but we = did not want to add that complexity unless there was desire for it. - TLS 1.3 allows the client to restrict the use of PSKs that they = provide in ClientHello through the "psk_key_exchange_modes" extension. The client = may, for instance, request that the PSK only be used in a PSK+(EC)DHE mode, = so as to ensure that the resumed session has forward secrecy. It is unclear = the best way to reconcile this with support for multiple key shares; we = outline some possibilities in Section 4 of our Internet-Draft, and we welcome = input. We have also created a pull request to TLS 1.3 draft 19 which includes a clarification on how additional secrets are to be included in the TLS = key schedule. https://github.com/jschanck/tls13-spec John and Douglas From nobody Mon Apr 17 12:14:43 2017 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 E2DC8131770 for ; Mon, 17 Apr 2017 12:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 ePV1pt4U2N8C for ; Mon, 17 Apr 2017 12:14:38 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 A22991315AE for ; Mon, 17 Apr 2017 12:14:38 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id z127so12425619pgb.1 for ; Mon, 17 Apr 2017 12:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wWvms78Q7qk6wBmdGsFD80GqtGPTyZqLPNGoQcwe9/4=; b=SE+sYkhsfhndB4CRGzOukgVDljZGL/72sgR0U6tPc5Wrs2vclcS4s40khZP5eVnNQ7 GQw+tRYDRRgMYjE/AexHHkl3Th/g45Z/yWbvYvIn2WpMruSLccmNtexcdA88ULzYZX6p vHg7vxdE2/yClk2D1MH7lqDUUcdY4gYN06mMY= 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; bh=wWvms78Q7qk6wBmdGsFD80GqtGPTyZqLPNGoQcwe9/4=; b=PE5lbdEEF3EvAvHIVve1QPNA9euBqIqg9FZZldXrfCVuqRrGSyYULSFJ98vA90rrhB nfupQhvPJlTRCKAoWKqIGtxPl228ptPGWTpsryNxklczulxYlg4TyHyJgVTCNYEpuJ7V dxzaJnwiboHCu6UOyjiTVglthMri9fNP2bsx339WLM2/5v7Ry3yu/WiWqjigRCUNf6Wk pVfd60h67apoXNgUBubcPq06k8ODpOSWHXuU2g2yG4XDh9710w6lRTaYm7spegObGXEZ zMTtB6oepq5ZtZGTjX/XUEs/qdJVaz3139fOvGoYwlsJrS9glHOnM+cBZtgtr3oSExxv C5aw== X-Gm-Message-State: AN3rC/7OGG6nr/V+MA0vv4QLkiitRuwiYpRxsHTCc5aGvzztJmHG+Flt YRUf4vXEZWe/eGJQOCls7trWhhkrzZfQKwY= X-Received: by 10.84.140.129 with SMTP id 1mr18153365plt.11.1492456478123; Mon, 17 Apr 2017 12:14:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Mon, 17 Apr 2017 19:14:26 +0000 Message-ID: To: Douglas Stebila , "" Content-Type: multipart/alternative; boundary=94eb2c11a09238ea9c054d619a76 Archived-At: Subject: Re: [TLS] AdditionalKeyShare Internet-Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 17 Apr 2017 19:14:41 -0000 --94eb2c11a09238ea9c054d619a76 Content-Type: text/plain; charset=UTF-8 This seems overly complicated. Why implement a parallel key share mechanism rather than merely defining a new NamedGroup value? Using your example of Google's recent New Hope experiment, I would imagine defining, say, NamedGroup.cecpq1. Let its key_shares be the concatenation of New Hope and X25519 public values, and let the resulting shared secret be some combination of the two resulting keys. This avoids changing the key schedule or protocol logic and slots in nicely into the existing arrangement. The AdditionalKeyShare proposal has more moving parts and combinatorial combinations to test and worry about. It also requires implementations answer silly questions like: - What happens the server selects two New Hopes with no X25519? X25519 and P-256 together? - What happens if the client offers New Hope in the normal key shares slot and X25519 in the additional one? - What happens if the client only offers New Hope and not X25519? - How does a client express that it's not willing to do New Hope without ECDH? What if the server sends a HelloRetryRequest for New Hope in the main slot and does not select X25519? - How can I plausibly expose this complex array of options to the consumer of my TLS library? David On Mon, Apr 17, 2017 at 2:23 PM Douglas Stebila wrote: > Dear TLS mailing list, > > We have posted an Internet-Draft > https://tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00 > for using an additional key share in TLS 1.3. The intended use case is to > provide support for transitional key exchange mechanisms in which both a > pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are used. > (Google's experiment with New Hope in 2016 had such an arrangement.) Our > draft > replicates the functionality of the KeyShare extension in a new extension > called > AdditionalKeyShare. Like KeyShare, the client's AdditionalKeyShare > contains a > vector of KeyShareEntry structs. The server can respond with a single > matching > KeyShareEntry in the AdditionalKeyShare extension of its ServerHello. The > resulting additional shared secret is included in the TLS key schedule > after the > ECDH shared secret. > > While the motivation for our Internet-Draft is to facilitate the > transition to > post-quantum algorithms, our Internet-Draft does not specify any > post-quantum > algorithms. > > There are a couple of items for discussion related to this draft: > > - We only provide a mechanism for a single AdditionalKeyShare, thus > leading to > the session establishing at most PSK + ECDHE + 1 additional shared > secret. Is > there a value in even more shared secrets than that? Will someone want > to include more than one post-quantum algorithm? If so, our draft could > be > adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but we > did not > want to add that complexity unless there was desire for it. > > - TLS 1.3 allows the client to restrict the use of PSKs that they provide > in > ClientHello through the "psk_key_exchange_modes" extension. The client > may, > for instance, request that the PSK only be used in a PSK+(EC)DHE mode, > so as > to ensure that the resumed session has forward secrecy. It is unclear > the > best way to reconcile this with support for multiple key shares; we > outline > some possibilities in Section 4 of our Internet-Draft, and we welcome > input. > > We have also created a pull request to TLS 1.3 draft 19 which includes a > clarification on how additional secrets are to be included in the TLS key > schedule. > https://github.com/jschanck/tls13-spec > > John and Douglas > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c11a09238ea9c054d619a76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems overly complicated. Why implement a parallel ke= y share mechanism rather than merely defining a new NamedGroup value?
<= br>
Using your example of Google's recent New Hope experiment= , I would imagine defining, say, NamedGroup.cecpq1. Let its key_shares be t= he concatenation of New Hope and X25519 public values, and let the resultin= g shared secret be some combination of the two resulting keys.
This avoids changing the key schedule or protocol logic and slo= ts in nicely into the existing arrangement. The AdditionalKeyShare proposal= has more moving parts and combinatorial combinations to test and worry abo= ut. It also requires implementations answer silly questions like:
- What happens the server selects two New Hopes with no X25519? X25519 and= P-256 together?
- What happens if the client offers New Hope in the nor= mal key shares slot and X25519 in the additional one?
- What happ= ens if the client only offers New Hope and not X25519?
- How does= a client express that it's not willing to do New Hope without ECDH? Wh= at if the server sends a HelloRetryRequest for New Hope in the main slot an= d does not select X25519?
- How can I plausibly e= xpose this complex array of options to the consumer of my TLS library?
<= /div>

=
David


On M= on, Apr 17, 2017 at 2:23 PM Douglas Stebila <dstebila@gmail.com> wrote:
Dear TLS mailing list,

We have posted an Internet-Draft
=C2=A0 =C2=A0 https://tools.ietf= .org/html/draft-schanck-tls-additional-keyshare-00
for using an additional key share in TLS 1.3.=C2=A0 The intended use case i= s to
provide support for transitional key exchange mechanisms in which both a pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are used. (Google's experiment with New Hope in 2016 had such an arrangement.) Ou= r draft
replicates the functionality of the KeyShare extension in a new extension c= alled
AdditionalKeyShare. Like KeyShare, the client's AdditionalKeyShare cont= ains a
vector of KeyShareEntry structs. The server can respond with a single match= ing
KeyShareEntry in the AdditionalKeyShare extension of its ServerHello. The resulting additional shared secret is included in the TLS key schedule afte= r the
ECDH shared secret.

While the motivation for our Internet-Draft is to facilitate the transition= to
post-quantum algorithms, our Internet-Draft does not specify any post-quant= um
algorithms.

There are a couple of items for discussion related to this draft:

- We only provide a mechanism for a single AdditionalKeyShare, thus leading= to
=C2=A0 the session establishing at most PSK + ECDHE + 1 additional shared s= ecret.=C2=A0 Is
=C2=A0 there a value in even more shared secrets than that?=C2=A0 Will some= one want
=C2=A0 to include more than one post-quantum algorithm?=C2=A0 If so, our dr= aft could be
=C2=A0 adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but = we did not
=C2=A0 want to add that complexity unless there was desire for it.

- TLS 1.3 allows the client to restrict the use of PSKs that they provide i= n
=C2=A0 ClientHello through the "psk_key_exchange_modes" extension= . The client may,
=C2=A0 for instance, request that the PSK only be used in a PSK+(EC)DHE mod= e, so as
=C2=A0 to ensure that the resumed session has forward secrecy.=C2=A0 It is = unclear the
=C2=A0 best way to reconcile this with support for multiple key shares; we = outline
=C2=A0 some possibilities in Section 4 of our Internet-Draft, and we welcom= e input.

We have also created a pull request to TLS 1.3 draft 19 which includes a clarification on how additional secrets are to be included in the TLS key schedule.
=C2=A0 =C2=A0 https://github.com/jschanck/tls13-spec

John and Douglas

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--94eb2c11a09238ea9c054d619a76-- From nobody Mon Apr 17 12:44:56 2017 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 2F3F81317BA for ; Mon, 17 Apr 2017 12:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3YMunvvOE5yN for ; Mon, 17 Apr 2017 12:44:51 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 2ADF21317B6 for ; Mon, 17 Apr 2017 12:44:51 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id r16so162068958ioi.2 for ; Mon, 17 Apr 2017 12:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5pHPR5HhTaofLoDqGGICAW8spTN/6cSOkKs1Llf8lKg=; b=qJ0q+RnX5oDwBdV/vHXpjlPgrWkW6rJxmKjpHIM37jt9NeQX03I+ggG8tWFb5f9hiN KTV2LV29wyyKzOaRe4GFydZ0OXqEkdY4RVOSGUjpdwzcDki47oRtNCel/X8agOA+YxDh Ov2uC3wW+d9UfzNeQcWCsK58epBNV8UbwCxrP5Ch/551OaT2qWU/1FBI+A2TNzJrNr9/ r0BO5mUTxcs0twFyYZjzDDAmGez94nym0sym4KMVKy1FoUpr5MkAFsNm+LfTUGPI4PUW b5yJiYXj6JunWNy2Ldu1zbpMbpenfzpy7jvr0GPP+6rxrCA4Cc64X8KPy33oMLURh9M5 tCKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5pHPR5HhTaofLoDqGGICAW8spTN/6cSOkKs1Llf8lKg=; b=EIBi3t8jVWlPTT7Vz7dPMb2WaJrbkRTbTvO8wlnkWC8Nog89iBQC+01z4JnTZzlZ1z 9937yfc8Ns2wzWeTtGT0ygxYM6BI76LEAs+J9TaLPWSpUqGJ7RyA6kOXxFroXvRypP7w ISY3/etfBl8zpWcLoRLUofGuZOkG/uBTMUadd1RI1kPqLn4cFoEjR5GbEv7eFUO43OBS nYXNF9xKcq20msnejQ92tc+nS8nBTF0GIWG89QGaheOrJMtqm3xyj1ampM2wC+QxjVUQ oWboOZhiypV7oCDLgaRfNuMWdZAOSleguj3Q/HrUoypNOgrfE98MB1kiLAxIFBMlB9Ov Tozg== X-Gm-Message-State: AN3rC/4sGnDJpdxyDTBB+MQlUjRjloHe6dF0wsaif3q52x3x3kT0QS8c u/7iGkOZ/qoFYQ== X-Received: by 10.36.19.193 with SMTP id 184mr11560344itz.93.1492458290323; Mon, 17 Apr 2017 12:44:50 -0700 (PDT) Received: from stebila-imac.cas.mcmaster.ca (stebila-imac.cas.McMaster.CA. [130.113.68.195]) by smtp.gmail.com with ESMTPSA id d12sm5333562iog.41.2017.04.17.12.44.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 12:44:49 -0700 (PDT) From: Douglas Stebila Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C9E4F14D-94AB-4EED-A4F0-1646251D6DD6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Apr 2017 15:44:47 -0400 In-Reply-To: Cc: "" To: David Benjamin References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] AdditionalKeyShare Internet-Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 17 Apr 2017 19:44:54 -0000 --Apple-Mail=_C9E4F14D-94AB-4EED-A4F0-1646251D6DD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi David, Thanks for the feedback. > This seems overly complicated. Why implement a parallel key share = mechanism rather than merely defining a new NamedGroup value? >=20 > Using your example of Google's recent New Hope experiment, I would = imagine defining, say, NamedGroup.cecpq1. Let its key_shares be the = concatenation of New Hope and X25519 public values, and let the = resulting shared secret be some combination of the two resulting keys. >=20 > This avoids changing the key schedule or protocol logic and slots in = nicely into the existing arrangement. The AdditionalKeyShare proposal = has more moving parts and combinatorial combinations to test and worry = about. Defining combined NamedGroups, like in the Google New Hope experiment, = also incurs a combinatorial explosion, this time in the number of = NamedGroups. Given that TLS 1.3 has taken the approach of splitting off = each component of a TLS 1.2 ciphersuite into its own negotiable = component to avoid combinatorial explosion in standardized values, = separately negotiating each parallel key share mechanism seemed to us to = follow the TLS 1.3 design approach. > It also requires implementations answer silly questions like: > - What happens the server selects two New Hopes with no X25519? X25519 = and P-256 together? In our draft, KeyShare and AdditionalKeyShare form disjoint pools of = NamedGroups from which one element can be selected. If the client = offers say P256 and X5519 in KeyShare and NewHope in its = AdditionalKeyShare, your first problem cannot happen. If the client = offers NewHope in both pools, then the situation you propose could = happen. This does not negatively impact compatibility or security, = although there is obviously no value in doing two NewHopes compared to a = single NewHope. I don't think we've put in a MUST NOT/SHOULD NOT here, = but we could add that. > - What happens if the client offers New Hope in the normal key shares = slot and X25519 in the additional one? > - What happens if the client only offers New Hope and not X25519? This is fine from the draft's perspective. If the client does so and = then interacts with a non-NewHope-compatible server that only speaks = X25519, the connection would fail because the KeyShare slot contains no = mutually compatible key shares. > - How does a client express that it's not willing to do New Hope = without ECDH? What if the server sends a HelloRetryRequest for New Hope = in the main slot and does not select X25519? The server must pick exactly one NamedGroup from the KeyShare pool, and = at most one NamedGroup from the AdditionalKeyShare pool. The client = could put ECDH in KeyShare and NewHope in AdditionalKeyShare to indicate = this desire; the server would then have to use ECDH from the KeyShare = slot and could optionally use NewHope from the AdditionalKeyShare slot. If the client wants "ECDH (KeyShare) and NewHope (AdditionalKeyShare)" = and the server says "retry with NewHope (KeyShare)", the client has the = option of retrying with "NewHope (KeyShare) and ECDH = (AdditionalKeyShare)". If the server rejects, then the client knows its = policy cannot be satisfied, and it should not continue. If the server = continues with NewHope but discards the AdditionalKeyShare (as it's = allowed to do in our draft), the client learns the server is unwilling = to satisfy its policy, and the client can drop the connection. > - How can I plausibly expose this complex array of options to the = consumer of my TLS library? Yes, there is a complex array of options: - which algorithm(s) the client views as "must have" - which algorithm(s) the client views as "would like to have" - which algorithm(s) should/should not happen at the same time If this functionality is encapsulated anywhere in TLS, then that = complexity needs to incorporated somewhere, either already in compound = NamedGroups or in configuration of the parallel key share mechanism. As = I mentioned above, we thought that combinatorial explosion of = NamedGroups was not the TLS 1.3 way. However, we are open to = considering that if there's a clear preference for it. Douglas >=20 >=20 > On Mon, Apr 17, 2017 at 2:23 PM Douglas Stebila > wrote: > Dear TLS mailing list, >=20 > We have posted an Internet-Draft > = https://tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00 = > for using an additional key share in TLS 1.3. The intended use case = is to > provide support for transitional key exchange mechanisms in which both = a > pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are = used. > (Google's experiment with New Hope in 2016 had such an arrangement.) = Our draft > replicates the functionality of the KeyShare extension in a new = extension called > AdditionalKeyShare. Like KeyShare, the client's AdditionalKeyShare = contains a > vector of KeyShareEntry structs. The server can respond with a single = matching > KeyShareEntry in the AdditionalKeyShare extension of its ServerHello. = The > resulting additional shared secret is included in the TLS key schedule = after the > ECDH shared secret. >=20 > While the motivation for our Internet-Draft is to facilitate the = transition to > post-quantum algorithms, our Internet-Draft does not specify any = post-quantum > algorithms. >=20 > There are a couple of items for discussion related to this draft: >=20 > - We only provide a mechanism for a single AdditionalKeyShare, thus = leading to > the session establishing at most PSK + ECDHE + 1 additional shared = secret. Is > there a value in even more shared secrets than that? Will someone = want > to include more than one post-quantum algorithm? If so, our draft = could be > adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but = we did not > want to add that complexity unless there was desire for it. >=20 > - TLS 1.3 allows the client to restrict the use of PSKs that they = provide in > ClientHello through the "psk_key_exchange_modes" extension. The = client may, > for instance, request that the PSK only be used in a PSK+(EC)DHE = mode, so as > to ensure that the resumed session has forward secrecy. It is = unclear the > best way to reconcile this with support for multiple key shares; we = outline > some possibilities in Section 4 of our Internet-Draft, and we = welcome input. >=20 > We have also created a pull request to TLS 1.3 draft 19 which includes = a > clarification on how additional secrets are to be included in the TLS = key > schedule. > https://github.com/jschanck/tls13-spec = >=20 > John and Douglas >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = --Apple-Mail=_C9E4F14D-94AB-4EED-A4F0-1646251D6DD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi David,

Thanks for the feedback.

This = seems overly complicated. Why implement a parallel key share mechanism = rather than merely defining a new NamedGroup value?

Using your example of Google's recent = New Hope experiment, I would imagine defining, say, NamedGroup.cecpq1. = Let its key_shares be the concatenation of New Hope and X25519 public = values, and let the resulting shared secret be some combination of the = two resulting keys.

This avoids changing the key schedule = or protocol logic and slots in nicely into the existing arrangement. The = AdditionalKeyShare proposal has more moving parts and combinatorial = combinations to test and worry about. =

Defining combined NamedGroups, like in the Google = New Hope experiment, also incurs a combinatorial explosion, this time in = the number of NamedGroups.  Given that TLS 1.3 has taken the = approach of splitting off each component of a TLS 1.2 ciphersuite into = its own negotiable component to avoid combinatorial explosion in = standardized values, separately negotiating each parallel key share = mechanism seemed to us to follow the TLS 1.3 design = approach.

It also requires = implementations answer silly questions like:
- What = happens the server selects two New Hopes with no X25519? X25519 and = P-256 together?

In our draft, KeyShare and AdditionalKeyShare form = disjoint pools of NamedGroups from which one element can be selected. =  If the client offers say P256 and X5519 in KeyShare and NewHope in = its AdditionalKeyShare, your first problem cannot happen.  If the = client offers NewHope in both pools, then the situation you propose = could happen.  This does not negatively impact compatibility or = security, although there is obviously no value in doing two NewHopes = compared to a single NewHope.  I don't think we've put in a MUST = NOT/SHOULD NOT here, but we could add that.

- = What happens if the client offers New Hope in the normal key shares slot = and X25519 in the additional = one?
- What = happens if the client only offers New Hope and not = X25519?
This is = fine from the draft's perspective.  If the client does so and then = interacts with a non-NewHope-compatible server that only speaks X25519, = the connection would fail because the KeyShare slot contains no mutually = compatible key shares.

- How does a client express that it's not = willing to do New Hope without ECDH?  What if the server sends a = HelloRetryRequest for New Hope in the main slot and does not select = X25519?

The server must pick exactly one NamedGroup from = the KeyShare pool, and at most one NamedGroup from the = AdditionalKeyShare pool.  The client could put ECDH in KeyShare and = NewHope in AdditionalKeyShare to indicate this desire; the server would = then have to use ECDH from the KeyShare slot and could optionally use = NewHope from the AdditionalKeyShare slot.

If = the client wants "ECDH (KeyShare) and NewHope (AdditionalKeyShare)" and = the server says "retry with NewHope (KeyShare)", the client has the = option of retrying with "NewHope (KeyShare) and ECDH = (AdditionalKeyShare)".  If the server rejects, then the client = knows its policy cannot be satisfied, and it should not continue. =  If the server continues with NewHope but discards the = AdditionalKeyShare (as it's allowed to do in our draft), the client = learns the server is unwilling to satisfy its policy, and the client can = drop the connection.

- = How can I plausibly expose this complex array of options to the consumer = of my TLS library?

Yes, there is a complex array of = options:
- which algorithm(s) the client views as "must = have"
- which algorithm(s) the client views as "would like to = have"
- which algorithm(s) should/should not happen at the = same time

If this functionality is = encapsulated anywhere in TLS, then that complexity needs to incorporated = somewhere, either already in compound NamedGroups or in configuration of = the parallel key share mechanism.  As I mentioned above, we thought = that combinatorial explosion of NamedGroups was not the TLS 1.3 way. =  However, we are open to considering that if there's a clear = preference for it.

Douglas



On = Mon, Apr 17, 2017 at 2:23 PM Douglas Stebila <dstebila@gmail.com> wrote:
Dear TLS mailing = list,

We have posted an Internet-Draft
    https://tools.ietf.org/html/draft-schanck-tls-additional-keysha= re-00
for using an additional key share in TLS 1.3.  The intended use = case is to
provide support for transitional key exchange mechanisms in which both = a
pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are = used.
(Google's experiment with New Hope in 2016 had such an arrangement.) Our = draft
replicates the functionality of the KeyShare extension in a new = extension called
AdditionalKeyShare. Like KeyShare, the client's AdditionalKeyShare = contains a
vector of KeyShareEntry structs. The server can respond with a single = matching
KeyShareEntry in the AdditionalKeyShare extension of its ServerHello. = The
resulting additional shared secret is included in the TLS key schedule = after the
ECDH shared secret.

While the motivation for our Internet-Draft is to facilitate the = transition to
post-quantum algorithms, our Internet-Draft does not specify any = post-quantum
algorithms.

There are a couple of items for discussion related to this draft:

- We only provide a mechanism for a single AdditionalKeyShare, thus = leading to
  the session establishing at most PSK + ECDHE + 1 additional = shared secret.  Is
  there a value in even more shared secrets than that?  Will = someone want
  to include more than one post-quantum algorithm?  If so, our = draft could be
  adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., = but we did not
  want to add that complexity unless there was desire for it.

- TLS 1.3 allows the client to restrict the use of PSKs that they = provide in
  ClientHello through the "psk_key_exchange_modes" extension. The = client may,
  for instance, request that the PSK only be used in a PSK+(EC)DHE = mode, so as
  to ensure that the resumed session has forward secrecy.  It = is unclear the
  best way to reconcile this with support for multiple key shares; = we outline
  some possibilities in Section 4 of our Internet-Draft, and we = welcome input.

We have also created a pull request to TLS 1.3 draft 19 which includes = a
clarification on how additional secrets are to be included in the TLS = key
schedule.
    https://github.com/jschanck/tls13-spec

John and Douglas

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_C9E4F14D-94AB-4EED-A4F0-1646251D6DD6-- From nobody Mon Apr 17 13:07:23 2017 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 053ED129458 for ; Mon, 17 Apr 2017 13:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 o3pe6nTkEGkr for ; Mon, 17 Apr 2017 13:07:20 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3186E1200FC for ; Mon, 17 Apr 2017 13:07:20 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7057943340D; Mon, 17 Apr 2017 20:07:19 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 5079843341E; Mon, 17 Apr 2017 20:07:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1492459639; bh=c5spxStAndkmtZSM+gi4HuHEeP43ysvCRshY+tRNCAs=; l=3787; h=To:References:From:Date:In-Reply-To:From; b=FKUzPOZ7WI2JVUVHCF1CJUHU7o5MHiS20X2FMVok8eobEvg0Rfl8o6lPfhKTZ7jzU MOENfWApAIVQlHvv6ScT6djlWLNW03M+OChwe0BNPgTl3eH9sZP7zpvLJFccUYNHyQ 37/bEvsiDgYpqmLpSM5vkUyowOXZNzbIpduc+53o= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id E78801FC8B; Mon, 17 Apr 2017 20:07:18 +0000 (GMT) To: Eric Rescorla , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: Date: Mon, 17 Apr 2017 15:07:18 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5046FED3FA02BFEB5FD1FF8D" Archived-At: Subject: Re: [TLS] PR#950: Unpredictable certificate_request_context values. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 17 Apr 2017 20:07:22 -0000 This is a multi-part message in MIME format. --------------5046FED3FA02BFEB5FD1FF8D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/16/2017 01:42 PM, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/950 > > > Target merge date: Tuesday > > I have just posted PR#950, which recommends that servers generate > unpredictable > context values for CertificateRequest in post-handshake client > authentication. This > prevents attacks in which an attacker who has temporary access to the > client's > private key can forge valid CertificateVerify messages. > > Note that this is not an enormously large improvement because an > attacker who > has temporary access the private key can do a bunch of other stuff, > like forging > a complete handshake message, but I can imagine some artificial scenarios > where it might be useful, for instance if the user's private key is an > HSM and > so the attacker has permanent control of the user's machine but can't > get him > to generate an arbitrary number of private key operations without > detection. > > Unless I have missed something, this seems like harmless advice, so I tend > to think we should add it. Comments welcome > Sounds like a good idea. -Ben --------------5046FED3FA02BFEB5FD1FF8D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/16/2017 01:42 PM, Eric Rescorla wrote:
https://github.com/tlswg/tls13-spec/pull/950
Target merge date: Tuesday

I have just posted PR#950, which recommends that servers generate unpredictable
context values for CertificateRequest in post-handshake client authentication. This
prevents attacks in which an attacker who has temporary access to the client's
private key can forge valid CertificateVerify messages.

Note that this is not an enormously large improvement because an attacker who
has temporary access the private key can do a bunch of other stuff, like forging
a complete handshake message, but I can imagine some artificial scenarios
where it might be useful, for instance if the user's private key is an HSM and
so the attacker has permanent control of the user's machine but can't get him
to generate an arbitrary number of private key operations without detection.

Unless I have missed something, this seems like harmless advice, so I tend
to think we should add it. Comments welcome


Sounds like a good idea.

-Ben
--------------5046FED3FA02BFEB5FD1FF8D-- From nobody Mon Apr 17 13:14:33 2017 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 8EC0F129463 for ; Mon, 17 Apr 2017 13:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 QVcBMSRbdQWQ for ; Mon, 17 Apr 2017 13:14:29 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id D14C812945D for ; Mon, 17 Apr 2017 13:14:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DE06E43342F; Mon, 17 Apr 2017 20:14:27 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C6E4643340C; Mon, 17 Apr 2017 20:14:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1492460067; bh=c18/SNa+E8KCvcf7xfvvkdR7MWRI83xWnW0Hfnukrw8=; l=8533; h=To:References:Cc:From:Date:In-Reply-To:From; b=Q0aFQB5Bg8snhTkvah0ncv17tC6P1tGxn9AwEoCZD4zxKs/I5vnKQvCbgVS+PiMS8 OXckJlLVHfMlTi9QgkqKIT128bRtv4Xyjzy3UMe73wLlXFK2Wr/geAsuwBya/zwKx0 UB89iqrZDb47VCaxovSxnyQmwObXqEX+1HlnfsJE= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 7BFAE1FC86; Mon, 17 Apr 2017 20:14:27 +0000 (GMT) To: Douglas Stebila , David Benjamin References: Cc: "" From: Benjamin Kaduk Message-ID: <436c8c50-6a32-8d4e-d666-b96684847c55@akamai.com> Date: Mon, 17 Apr 2017 15:14:27 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------74C0E74B8A4710CBEA3BE0F4" Archived-At: Subject: Re: [TLS] AdditionalKeyShare Internet-Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 17 Apr 2017 20:14:31 -0000 This is a multi-part message in MIME format. --------------74C0E74B8A4710CBEA3BE0F4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/17/2017 02:44 PM, Douglas Stebila wrote: > Hi David, > > Thanks for the feedback. > >> This seems overly complicated. Why implement a parallel key share >> mechanism rather than merely defining a new NamedGroup value? >> >> Using your example of Google's recent New Hope experiment, I would >> imagine defining, say, NamedGroup.cecpq1. Let its key_shares be the >> concatenation of New Hope and X25519 public values, and let the >> resulting shared secret be some combination of the two resulting keys. >> >> This avoids changing the key schedule or protocol logic and slots in >> nicely into the existing arrangement. The AdditionalKeyShare proposal >> has more moving parts and combinatorial combinations to test and >> worry about. > > Defining combined NamedGroups, like in the Google New Hope experiment, > also incurs a combinatorial explosion, this time in the number of > NamedGroups. Given that TLS 1.3 has taken the approach of splitting > off each component of a TLS 1.2 ciphersuite into its own negotiable > component to avoid combinatorial explosion in standardized values, > separately negotiating each parallel key share mechanism seemed to us > to follow the TLS 1.3 design approach. > You only get the combinatorial explosion if you let it happen. A lot of the possible combinations wouldn't make much sense, and would not need to be defined. TLS 1.3 also tries to limit the possible combinations in some aspects, presenting just a few good choices with clear trade-offs. >> It also requires implementations answer silly questions like: >> - What happens the server selects two New Hopes with no X25519? >> X25519 and P-256 together? > > In our draft, KeyShare and AdditionalKeyShare form disjoint pools of > NamedGroups from which one element can be selected. If the client > offers say P256 and X5519 in KeyShare and NewHope in its > AdditionalKeyShare, your first problem cannot happen. If the client > offers NewHope in both pools, then the situation you propose could > happen. This does not negatively impact compatibility or security, > although there is obviously no value in doing two NewHopes compared to > a single NewHope. I don't think we've put in a MUST NOT/SHOULD NOT > here, but we could add that. > That's pushing complexity from the spec into implementations; we have a lot of evidence to suggest that not all implementations will get it right. > > - How can I plausibly expose this complex array of options to the > consumer of my TLS library? > > Yes, there is a complex array of options: > - which algorithm(s) the client views as "must have" > - which algorithm(s) the client views as "would like to have" > - which algorithm(s) should/should not happen at the same time > > If this functionality is encapsulated anywhere in TLS, then that > complexity needs to incorporated somewhere, either already in compound > NamedGroups or in configuration of the parallel key share mechanism. > As I mentioned above, we thought that combinatorial explosion of > NamedGroups was not the TLS 1.3 way. However, we are open to > considering that if there's a clear preference for it. > I would rather leave the complexity in the NamedGroups registry. -Ben --------------74C0E74B8A4710CBEA3BE0F4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/17/2017 02:44 PM, Douglas Stebila wrote:
Hi David,

Thanks for the feedback.

This seems overly complicated. Why implement a parallel key share mechanism rather than merely defining a new NamedGroup value?

Using your example of Google's recent New Hope experiment, I would imagine defining, say, NamedGroup.cecpq1. Let its key_shares be the concatenation of New Hope and X25519 public values, and let the resulting shared secret be some combination of the two resulting keys.

This avoids changing the key schedule or protocol logic and slots in nicely into the existing arrangement. The AdditionalKeyShare proposal has more moving parts and combinatorial combinations to test and worry about.

Defining combined NamedGroups, like in the Google New Hope experiment, also incurs a combinatorial explosion, this time in the number of NamedGroups.  Given that TLS 1.3 has taken the approach of splitting off each component of a TLS 1.2 ciphersuite into its own negotiable component to avoid combinatorial explosion in standardized values, separately negotiating each parallel key share mechanism seemed to us to follow the TLS 1.3 design approach.


You only get the combinatorial explosion if you let it happen.  A lot of the possible combinations wouldn't make much sense, and would not need to be defined.  TLS 1.3 also tries to limit the possible combinations in some aspects, presenting just a few good choices with clear trade-offs.

It also requires implementations answer silly questions like:
- What happens the server selects two New Hopes with no X25519? X25519 and P-256 together?

In our draft, KeyShare and AdditionalKeyShare form disjoint pools of NamedGroups from which one element can be selected.  If the client offers say P256 and X5519 in KeyShare and NewHope in its AdditionalKeyShare, your first problem cannot happen.  If the client offers NewHope in both pools, then the situation you propose could happen.  This does not negatively impact compatibility or security, although there is obviously no value in doing two NewHopes compared to a single NewHope.  I don't think we've put in a MUST NOT/SHOULD NOT here, but we could add that.


That's pushing complexity from the spec into implementations; we have a lot of evidence to suggest that not all implementations will get it right.


- How can I plausibly expose this complex array of options to the consumer of my TLS library?

Yes, there is a complex array of options:
- which algorithm(s) the client views as "must have"
- which algorithm(s) the client views as "would like to have"
- which algorithm(s) should/should not happen at the same time

If this functionality is encapsulated anywhere in TLS, then that complexity needs to incorporated somewhere, either already in compound NamedGroups or in configuration of the parallel key share mechanism.  As I mentioned above, we thought that combinatorial explosion of NamedGroups was not the TLS 1.3 way.  However, we are open to considering that if there's a clear preference for it.


I would rather leave the complexity in the NamedGroups registry.

-Ben
--------------74C0E74B8A4710CBEA3BE0F4-- From nobody Mon Apr 17 13:31:36 2017 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 04CD312946A for ; Mon, 17 Apr 2017 13:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham 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 ziZbPIeKHHpE for ; Mon, 17 Apr 2017 13:31:32 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 0BA6612945D for ; Mon, 17 Apr 2017 13:31:32 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id m133so32655386ybb.1 for ; Mon, 17 Apr 2017 13:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EJIP5nOiy2FldfEvRcDk6Y2boNHy5My6b8HimRmEN3k=; b=R+s/dosJuxEB3vm9Mseh8FDTZdxbSjRG/WNYNBwedBeW/FGHebUt0Oi0MuUM+m24tV zOAZsZ+LAe1oCNPAqZ+GjL1W17esGqgLqiXiznogNzHRrBJ/EQ6qxHNgx7bG6YOLXhEn HzsKQ90UBL/pPYBBB4hBJ8LBdvLlGCm8MGVduVcetjM/qja+qfeX0NMMKY2MBNQfnC1k iwhD81an9tJebeIw/lr9QJdrYGckWoXfeslb40irgNy06piq5reh+gWOB1b31zDPWIlc I/CiUHAjVCwkTIdJkwttdmJ41zLN724QFqfB9s9QoZOWxgXS6ycwRD5Ln63G+DEgZstj Dvpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EJIP5nOiy2FldfEvRcDk6Y2boNHy5My6b8HimRmEN3k=; b=uaszfGCsqyEm92selm9ZVhPOOu+GfFcQbKs7ad4bOre9frJvPeHkPHflZk2go2UHZp scvbCT/pBDGhOpUdCdn0vXWDRppaT3zrhONhXqRTTqjnPt0QKhb/DkjxkygipoY19tEA ixQlUqnu1aGMocTm0Liv53HhXd07IgdR4fUKBPZZuVKsVk7cpnHP6hG7LTs0/O55AIms 2vkMMkVwOn6zzhhX+sO263whG5CY5yGkq/CRlC/Qg8EM/upqLnlG/31uhAuAnPMR5bpm cy+EX0JH2wKlOlJiHv+gimHujgMS/gwHzyx9+VqUrhz2k95dm2qoZv5tkMdp4mHJZk9V oTFA== X-Gm-Message-State: AN3rC/6v8TyVVG6nE0O3UpYC79mydONqTX9rzXX5QY8niqGHWd7beFb/ go/9rQvl0SgNZdlCpSDu+avv0VZJ+A== X-Received: by 10.37.78.195 with SMTP id c186mr16597584ybb.180.1492461091204; Mon, 17 Apr 2017 13:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 17 Apr 2017 13:30:50 -0700 (PDT) In-Reply-To: <436c8c50-6a32-8d4e-d666-b96684847c55@akamai.com> References: <436c8c50-6a32-8d4e-d666-b96684847c55@akamai.com> From: Eric Rescorla Date: Mon, 17 Apr 2017 16:30:50 -0400 Message-ID: To: Benjamin Kaduk Cc: Douglas Stebila , David Benjamin , "" Content-Type: multipart/alternative; boundary=001a113e88fa2ef8c6054d62ad38 Archived-At: Subject: Re: [TLS] AdditionalKeyShare Internet-Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 17 Apr 2017 20:31:34 -0000 --001a113e88fa2ef8c6054d62ad38 Content-Type: text/plain; charset=UTF-8 I agree with David here. ISTM that if we discover that this is turning a lot of problems, we can presumably add an extension like the one proposed here at some later point. -Ekr On Mon, Apr 17, 2017 at 4:14 PM, Benjamin Kaduk wrote: > On 04/17/2017 02:44 PM, Douglas Stebila wrote: > > Hi David, > > Thanks for the feedback. > > This seems overly complicated. Why implement a parallel key share > mechanism rather than merely defining a new NamedGroup value? > > Using your example of Google's recent New Hope experiment, I would imagine > defining, say, NamedGroup.cecpq1. Let its key_shares be the concatenation > of New Hope and X25519 public values, and let the resulting shared secret > be some combination of the two resulting keys. > > This avoids changing the key schedule or protocol logic and slots in > nicely into the existing arrangement. The AdditionalKeyShare proposal has > more moving parts and combinatorial combinations to test and worry about. > > > Defining combined NamedGroups, like in the Google New Hope experiment, > also incurs a combinatorial explosion, this time in the number of > NamedGroups. Given that TLS 1.3 has taken the approach of splitting off > each component of a TLS 1.2 ciphersuite into its own negotiable component > to avoid combinatorial explosion in standardized values, separately > negotiating each parallel key share mechanism seemed to us to follow the > TLS 1.3 design approach. > > > You only get the combinatorial explosion if you let it happen. A lot of > the possible combinations wouldn't make much sense, and would not need to > be defined. TLS 1.3 also tries to limit the possible combinations in some > aspects, presenting just a few good choices with clear trade-offs. > > It also requires implementations answer silly questions like: > - What happens the server selects two New Hopes with no X25519? X25519 and > P-256 together? > > > In our draft, KeyShare and AdditionalKeyShare form disjoint pools of > NamedGroups from which one element can be selected. If the client offers > say P256 and X5519 in KeyShare and NewHope in its AdditionalKeyShare, your > first problem cannot happen. If the client offers NewHope in both pools, > then the situation you propose could happen. This does not negatively > impact compatibility or security, although there is obviously no value in > doing two NewHopes compared to a single NewHope. I don't think we've put > in a MUST NOT/SHOULD NOT here, but we could add that. > > > That's pushing complexity from the spec into implementations; we have a > lot of evidence to suggest that not all implementations will get it right. > > > - How can I plausibly expose this complex array of options to the consumer > of my TLS library? > > Yes, there is a complex array of options: > - which algorithm(s) the client views as "must have" > - which algorithm(s) the client views as "would like to have" > - which algorithm(s) should/should not happen at the same time > > If this functionality is encapsulated anywhere in TLS, then that > complexity needs to incorporated somewhere, either already in compound > NamedGroups or in configuration of the parallel key share mechanism. As I > mentioned above, we thought that combinatorial explosion of NamedGroups was > not the TLS 1.3 way. However, we are open to considering that if there's a > clear preference for it. > > > I would rather leave the complexity in the NamedGroups registry. > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113e88fa2ef8c6054d62ad38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with David here. ISTM that if we discover that thi= s is turning a lot of problems,
we can presumably add an extension like= the one proposed here at some later point.

-= Ekr


On Mon, Apr 17, 2017 at 4:14 PM, Benjamin Kaduk <bkaduk= @akamai.com> wrote:
=20 =20 =20
On 04/17/2017 02:44 PM, Douglas Stebila wrote:
=20 Hi David,

Thanks for the feedback.

This seems overly complicated. Why implement a parallel key share mechanism rather than merely defining a new NamedGroup value?

Using your example of Google's recent New Hope experiment, I would imagine defining, say, NamedGroup.cecpq1. Let its key_shares be the concatenation of New Hope and X25519 public values, and let the resulting shared secret be some combination of the two resulting keys.

This avoids changing the key schedule or protocol logic and slots in nicely into the existing arrangement. The AdditionalKeyShare proposal has more moving parts and combinatorial combinations to test and worry about.

Defining combined NamedGroups, like in the Google New Hope experiment, also incurs a combinatorial explosion, this time in the number of NamedGroups.=C2=A0 Given that TLS 1.3 has taken the approach of splitting off each component of a TLS 1.2 ciphersuite into its own negotiable component to avoid combinatorial explosion in standardized values, separately negotiating each parallel key share mechanism seemed to us to follow the TLS 1.3 design approach.


 You only get the combinatorial explosion if you let it happen.=C2=A0 A lot of the possible combinations wouldn't make much sense, and woul= d not need to be defined.=C2=A0 TLS 1.3 also tries to limit the possible combinations in some aspects, presenting just a few good choices with clear trade-offs.

It also requires implementations answer silly questions like:
- What happens the server selects two New Hopes with no X25519? X25519 and P-256 together?

In our draft, KeyShare and AdditionalKeyShare form disjoint pools of NamedGroups from which one element can be selected.=C2=A0 If the client offers say P256 and X5519 in KeyShare and NewHope in its AdditionalKeyShare, your first problem cannot happen.=C2=A0 If the client offers NewHope in both pools, then the situation you propose could happen. =C2=A0This does not negatively impact compatibility or security, although there is obviously no value in doing two NewHopes compared to a single NewHope.=C2=A0 I don't = think we've put in a MUST NOT/SHOULD NOT here, but we could add that.


 That's pushing complexity from the spec into implementations; we have a lot of evidence to suggest that not all implementations will get it right.


- How can I plausibly expose this complex array of options to the consumer of my TLS library?

Yes, there is a complex array of options:
- which algorithm(s) the client views as "must have&q= uot;
- which algorithm(s) the client views as "would like = to have"
- which algorithm(s) should/should not happen at the same time

If this functionality is encapsulated anywhere in TLS, then that complexity needs to incorporated somewhere, either already in compound NamedGroups or in configuration of the parallel key share mechanism.=C2=A0 As I mentioned above, we thought that combinatorial explosion of NamedGroups was not the TLS 1.3 way.=C2=A0 However, we are op= en to considering that if there's a clear preference for it.=


I would rather leave the complexity in the NamedGroups registry.

-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a113e88fa2ef8c6054d62ad38-- From nobody Tue Apr 18 06:49:26 2017 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 D12EB12EC7B for ; Tue, 18 Apr 2017 06:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 B2oDH_tkbf-Y for ; Tue, 18 Apr 2017 06:49:19 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 4E7E812EC29 for ; Tue, 18 Apr 2017 06:49:15 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id k13so69670440ywk.1 for ; Tue, 18 Apr 2017 06:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Y2nvxl2aZqSOx1K7pussggf1rULVjLHQyvHBU9FlWKQ=; b=bJy3sEaFf94rux/kDuGBHh4ezRHBvvGaNAgVaeohpqaCRnoNK9DAKQgIZjMbunh0FP MbSA4P9pKkeGAvEGVmdMySLKTn5rntS2DJMdDzyOPImBABN1q7XN8uyl+2fU3QOqIapR R0AL4Bx4a/sclVcQBKd+aDbvDQ5SrUahUHydouuiYXyEPfiOYGTfO0p7WlyNaNKKJlGN 7pcmB+PqjE7v34+rjQDMV7kp9hEq7rdi0YAnker7TAaSR4YTnA1gIRSciVVfpDLXFFWO oGzd4+/o1mhchzrcZDWsX/RJtD2grM6WXFN7okn8foybn7eyGnIpnzz4BuuCzWYigJIH 23BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Y2nvxl2aZqSOx1K7pussggf1rULVjLHQyvHBU9FlWKQ=; b=uf5XYHMXexbd1kfK7VZpNftsYJIM19x/oSPc+eiXimGyBVuikqR7xja0W3OywZmxYj i1d0xZteRtTtpcYjzO7+Y2fmMib95IbZP5iX/UE4Vd/PvYiBqGlQmZoK0fhcv3x+4nwI kfPZL5FsK6WowoNLwE4tYQ3VdE/oLbahZjXa8/O+D+xNFQeSMkd0FoxBs4j6++ZLIARK qy0T98S1XuRJKQEodo6AL6qAWJfSqh6WpgPy/SszM3KDzDyVMIi3RwaTZb99ZZsJL8KN gr6KNkr6Dw5s60W7XHXw9te2VI8tOcfblp5Brl5p7Jet29vj7lIM/xisFF03YO0duZmF hQEw== X-Gm-Message-State: AN3rC/7tAgwHVUun4gnwrl5ZdN0FQfVRotPI1VVGJAGQu2BK/94HYhC6 LaPc8FAqxoPQP4rdw+Zp2CUy46RKRPwlYOw= X-Received: by 10.129.167.3 with SMTP id e3mr8495539ywh.327.1492523354428; Tue, 18 Apr 2017 06:49:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 18 Apr 2017 06:48:33 -0700 (PDT) From: Eric Rescorla Date: Tue, 18 Apr 2017 09:48:33 -0400 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1461f25c34b3054d712c71 Archived-At: Subject: [TLS] PR#962:CertificateRequest in post-handhake phase X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 13:49:25 -0000 --94eb2c1461f25c34b3054d712c71 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/962 Target merge date: Thursday In reviewing the specification, I noticed that we seem to have banned the use of CertificateRequest with PSK both in the main handshake and in the post-handshake phase. I don't believe that this was intentional and it makes it very hard to use client auth with resumption. Accordingly I have filed the above PR to remove that restriction (while retaining it for the main handshake). As I understand it, several of the analyses we have already assumed this case and covered it, so no additional work is needed there. Comments/Objections welcome. -Ekr --94eb2c1461f25c34b3054d712c71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Target m= erge date: Thursday

In reviewing the specification= , I noticed that we seem to have banned the use of CertificateRequest with = PSK both in the main handshake and in the post-handshake phase. I don't= believe that this was intentional and it makes it very hard to use client = auth with resumption. Accordingly I have filed the above PR to remove that = restriction (while retaining it for the main handshake). As I understand it= , several of the analyses we have already assumed this case and covered it,= so no additional work is needed there.

Comments/O= bjections welcome.
-Ekr



--94eb2c1461f25c34b3054d712c71-- From nobody Tue Apr 18 08:29:39 2017 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 1530312EC7C for ; Tue, 18 Apr 2017 08:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Hu7Ybm5D94IM for ; Tue, 18 Apr 2017 08:29:35 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 7D9AB12EC69 for ; Tue, 18 Apr 2017 08:29:32 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id f133so133296715qke.2 for ; Tue, 18 Apr 2017 08:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rbrDptPk35wNgqUHDXEl4kV7d3f1QTZlJWTodkrkBoc=; b=jGTzqdu8/uyUYVC4lLdHMzn1TExmdaCTxr6ki/ehXKVKlfYRFC2w9UwmwfXzX1wrbu XNVtVBLuHO4D9U9huXaD7iW7AX/uLBMbG1qPYM9Jz+AA6wTVID7FFAqxfDY3LKb5MLg/ lkD0ZdhefyO3qx3ECkBEcVbeIjhCYwcGeg+aD2dgKY8TAL+lXI0J7oRNuQcA57kUXJuX W5QbKdl+yi6/PMSYoZ/yunQBaktYkaDBHqT7gAS2tEmpJ0udmAT6AtmpVuNzf8P0h5sr uwTJQjqtORP4omUdcdHy4wdVWunuKymaOMo8DERLAHeRuqtX0XhnGbPhsR91EVSkpEEF GhLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rbrDptPk35wNgqUHDXEl4kV7d3f1QTZlJWTodkrkBoc=; b=nM46s7MBS2AFIatwRyXz/vb7FKtse3wNl5+eljujZlhwLRgPNOityTmkrCP4mwL8Lf Y7keizaXlGJ30anUgYpZjUcSSSw794zJKbhKTTQbGC8Cmgrgz77cKt6Z1wG20TukOrad 3SBKS3/byT6VcHdwh1VbRZ/doH+yypXK7lyKKL9Z+5TjjN5NDIYJoAcDWAZChMWseCJj xSOwTAqVoG1XIVZx8ARkFO6PlqFz4pOLeP/n+NhqVogcVildKWh9NKK5bQUnta8xT3ue vQwIT1TYHD7Ogt6laTtGQMPkLeKWqHy8dz7QynNqdqBG12sxILq0CJuOtCuUw8zK1VNQ xpJw== X-Gm-Message-State: AN3rC/4mRufYcuN9WYNTIq6ohheNUTSvodTUdLx7moGnw7kzUg61Cg+k plluTjaOlGyVNio0hXLcwklni8bvd/3lI+g= X-Received: by 10.55.43.219 with SMTP id r88mr15038389qkr.143.1492529371476; Tue, 18 Apr 2017 08:29:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.76.81 with HTTP; Tue, 18 Apr 2017 08:29:31 -0700 (PDT) In-Reply-To: References: From: Victor Vasiliev Date: Tue, 18 Apr 2017 11:29:31 -0400 Message-ID: To: Joseph Salowey Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11493ed80175d1054d72931e Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 15:29:37 -0000 --001a11493ed80175d1054d72931e Content-Type: text/plain; charset=UTF-8 I've read the draft, and I support its adoption. I believe that the mechanism is sound for its stated use. I have some minor concerns about the wording in the draft, though. First, the draft describes the authenticators as sent "out-of-band", while my understanding is that they are always intended to be sent in-band as application data. If they were truly sent out-of-band, there would be some questions about the security analysis, because that would imply those could be sent unprotected. Hence, I suggest the draft to adapt the premise that exported authenticators MUST be sent as application data within the same connection. This might simplify your security proofs too. The second issue I have is with the question of when does authentication succeed. In TLS, by the time any party can send application data, normally (with exception of server-to-client data in client auth case) both parties know that the other side has authenticated them. Here, a new identity is introduced while application data can be already in flight, and it's not clear to me when the sender of the exported authenticator can act assuming the peer has accepted its new identity. My current understanding is that this issue is deferred to the application layer, but it would be nice to discuss those considerations explicitly. The last question I have is how does this interact with the state of TLS connection. Does accepting a new identity mean that the entire connection now has that identity too? Does this mean that the session tickets issued after the library receives the authenticator are valid for the new identity? Does it make the tickets sent previously on that connection valid for the new identity? Also, what is the distinction between "jointly authoritative for A and B" and "individually authoritative for A and individually authoritative for B"? -- Victor. On Fri, Apr 14, 2017 at 12:29 AM, Joseph Salowey wrote: > Hey Folks, > > At the IETF 98 meeting in Chicago there was support in the room to adopt > draft-sullivan-tls-exported-authenticator [0]. We are looking for > feedback on adopting this draft form the list. Please respond if you > support the draft and are willing to review it. If you object to its > adoption, please let us know why. Please respond to the list by 20170501 > > Cheers, > > J&S > > [0] https://datatracker.ietf.org/doc/html/draft-sullivan-tls > -exported-authenticator > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11493ed80175d1054d72931e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've read the draft, and I support its adoption.= =C2=A0 I believe that the mechanism
is sound for its stated use.<= /div>

I have some minor concerns about the wording in th= e draft, though.=C2=A0 First, the
draft describes the authenticat= ors as sent "out-of-band", while my
understanding is th= at they are always intended to be sent in-band as
application dat= a.=C2=A0 If they were truly sent out-of-band, there would be some
questions about the security analysis, because that would imply those coul= d be
sent unprotected.=C2=A0 Hence, I suggest the draft to adapt = the premise that
exported authenticators MUST be sent as applicat= ion data within the same
connection.=C2=A0 This might simplify yo= ur security proofs too.

The second issue I have is= with the question of when does authentication
succeed.=C2=A0 In = TLS, by the time any party can send application data, normally
(w= ith exception of server-to-client data in client auth case) both parties kn= ow
that the other side has authenticated them.=C2=A0 Here, a new = identity is introduced
while application data can be already in f= light, and it's not clear to me when
the sender of the export= ed authenticator can act assuming the peer has accepted
its new i= dentity.=C2=A0 My current understanding is that this issue is deferred to
the application layer, but it would be nice to discuss those consi= derations
explicitly.

The last question = I have is how does this interact with the state of TLS
connection= .=C2=A0 Does accepting a new identity mean that the entire connection now
has that identity too?=C2=A0 Does this mean that the session ticke= ts issued after
the library receives the authenticator are valid = for the new identity?=C2=A0 Does it
make the tickets sent previou= sly on that connection valid for the new identity?

Also, what is the distinction between "jointly authoritative for A an= d B" and
"individually authoritative for A and individu= ally authoritative for B"?

=C2=A0 -- Victor.<= /div>

On Fri= , Apr 14, 2017 at 12:29 AM, Joseph Salowey <joe@salowey.net> w= rote:
Hey Folks,

At the IETF 98 meeting = in Chicago there was support in the room to adopt=C2=A0draft-sulliv= an-tls-exported-authenticator=C2=A0[0]. We are looking for feedback on adopting this draft = form the list. Please respond if you support the draft and are willing to r= eview it. If you object to its adoption, please let us know why. Please res= pond to the list by 20170501

Cheers,

J&S


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a11493ed80175d1054d72931e-- From nobody Tue Apr 18 09:33:34 2017 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 75F5B129444 for ; Tue, 18 Apr 2017 09:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 t56HH-w_hcV2 for ; Tue, 18 Apr 2017 09:33:31 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2E85E128E19 for ; Tue, 18 Apr 2017 09:33:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 39B9B23375; Tue, 18 Apr 2017 19:33:29 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id c838Rqi4uweR; Tue, 18 Apr 2017 19:33:28 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id D184F2313; Tue, 18 Apr 2017 19:33:28 +0300 (EEST) Date: Tue, 18 Apr 2017 19:33:27 +0300 From: Ilari Liusvaara To: Victor Vasiliev Cc: Joseph Salowey , "tls@ietf.org" Message-ID: <20170418163327.GA12513@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 16:33:33 -0000 On Tue, Apr 18, 2017 at 11:29:31AM -0400, Victor Vasiliev wrote: > I've read the draft, and I support its adoption. I believe that the > mechanism > is sound for its stated use. > > The second issue I have is with the question of when does authentication > succeed. In TLS, by the time any party can send application data, normally > (with exception of server-to-client data in client auth case) both parties > know that the other side has authenticated them. I don't think that is actually true for client authentication (even in- handshake). > Here, a new identity is introduced while application data can be already > in flight, and it's not clear to me when the sender of the exported > authenticator can act assuming the peer has accepted its new identity. > My current understanding is that this issue is deferred to the application > layer, but it would be nice to discuss those considerations explicitly. IMO, the application layer is the only layer that actually knows the relevant state. > The last question I have is how does this interact with the state of TLS > connection. Does accepting a new identity mean that the entire connection > now has that identity too? Does this mean that the session tickets issued > after the library receives the authenticator are valid for the new > identity? Does it make the tickets sent previously on that connection valid > for the new identity? I believe this is up to the application. (And even in case of TLS authentication, I think some of these are "implementation-dependent". > Also, what is the distinction between "jointly authoritative for A and B" > and "individually authoritative for A and individually authoritative for > B"? Pretty much the whole paragraph mentioning that reads like some mumbo- jumbo to me (not a good sign). -Ilari From nobody Tue Apr 18 11:13:42 2017 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 81E6C12EB0F for ; Tue, 18 Apr 2017 11:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 k0knKI62nx1b for ; Tue, 18 Apr 2017 11:13:39 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361FA12EBB5 for ; Tue, 18 Apr 2017 11:13:37 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id C7F5330002924; Tue, 18 Apr 2017 11:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LX5r21exwr/JbS dZKrm7eEZdm0k=; b=F8MTUHO3SfnVK694fkDEytvwKnVRM/X9NYhsUKH/0h/thy soacYPpp+BrOCIc2ohwbSiET4VXzQuG9k75lPMIu99tg4FCpCkHFGmtryhMY6Mu/ uxaBN7nmRv+t6WIRu0Yy9lwRLEHqC0e7RWhmCg776wP9+8Es+lnEXLpbGgwAQ= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 709BC30002925; Tue, 18 Apr 2017 11:13:36 -0700 (PDT) Date: Tue, 18 Apr 2017 13:13:33 -0500 From: Nico Williams To: Joseph Salowey Cc: "tls@ietf.org" Message-ID: <20170418181332.GA2856@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 18:13:40 -0000 On Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph Salowey wrote: > At the IETF 98 meeting in Chicago there was support in the room to adopt > draft-sullivan-tls-exported-authenticator [0]. We are looking for feedback > on adopting this draft form the list. Please respond if you support the > draft and are willing to review it. If you object to its adoption, please > let us know why. Please respond to the list by 20170501 I support adoption. From nobody Tue Apr 18 12:41:42 2017 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 B49D812EBCD for ; Tue, 18 Apr 2017 12:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 OwDvRNeOp05a for ; Tue, 18 Apr 2017 12:41:38 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 707031293D9 for ; Tue, 18 Apr 2017 12:41:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id DD6362381E; Tue, 18 Apr 2017 22:41:35 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id Ai-G9NSvkhiF; Tue, 18 Apr 2017 22:41:35 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 45738285; Tue, 18 Apr 2017 22:41:35 +0300 (EEST) Date: Tue, 18 Apr 2017 22:41:34 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170418194134.GA13232@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] PR#962:CertificateRequest in post-handhake phase X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 19:41:41 -0000 On Tue, Apr 18, 2017 at 09:48:33AM -0400, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/962 > Target merge date: Thursday > > In reviewing the specification, I noticed that we seem to have banned the > use of CertificateRequest with PSK both in the main handshake and in the > post-handshake phase. I don't believe that this was intentional and it > makes it very hard to use client auth with resumption. Accordingly I have > filed the above PR to remove that restriction (while retaining it for the > main handshake). As I understand it, several of the analyses we have > already assumed this case and covered it, so no additional work is needed > there. On topic of PSKs, I noticed that TLS 1.3 makes it very easy to mount dictionary attacks against PSK, regardless of DHE-PSK (especially to recover the client PSK). I assumed that the document already documents this, but I couldn't find any remark that using low-entropy PSKs is very bad idea. IIRC, the TLS 1.0-1.2 PSK RFC does discuss dictionary attacks a bit. -Ilari From nobody Tue Apr 18 12:52:38 2017 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 5736D1293D9 for ; Tue, 18 Apr 2017 12:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 xh9XE4L1rOkj for ; Tue, 18 Apr 2017 12:52:34 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 5F135127A91 for ; Tue, 18 Apr 2017 12:52:34 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u70so1536383ywe.2 for ; Tue, 18 Apr 2017 12:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1ziAHpim2MIAjLnLua81pzlck+mgxiESaSJnoqPu3qo=; b=bzLtiptXSJlXPqx/ET4sMQYtJAPYgms5ukZVU/6TEn08slRsusT+0+97avPNDR1QN3 zQP9W9QeOHipJHkbhh2PtutfRBH0UcsBdhO82BOmKK4IaPE24ZwRs9JuWfAEmBizQFw4 XvFJT+gqJPXhQcNxQxD3W00IFc5A71lu4FZ2uKyjx5AIkpy9GThKEY5Q6fspe/bzOvR+ fzf+muDLM5EofTW7WHGUprBcZvx86C34XODferluzJyKcQn4xqcxczrQhhhF0oHcWByo Vf/fcOYbPke3x1kdj9ORy2P3kjGO+C+/fC9Dw3mO1SSpwED/BKBntDXCyh/9XzvGJ6oM BDKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1ziAHpim2MIAjLnLua81pzlck+mgxiESaSJnoqPu3qo=; b=szHaiCjdTKTp39xt/dKkft2fvWiObgGUzOER8i5FxEAoAdq6NLY41FTh/ZdxOyRxDr X0tNE8SR2q0ePnkrRylHoiwDho8/e7EHfJ2wAoO2GoqAGnTi07m/cOLRfmoGpZOtpcUp M1q9ItDKdjoTmE/cIH067bgZPNfL47pNdU/fAxk0D0yABAn/a0OSVyOeXBMKhIKHCaPw Pr+h1wqzw0/qae9c+7jmabkSXXj1i1vcSNLl1oVjskhyNGsSz9TCxDmdbfHv/w8doO4Z zppiiGVt+4GaQtip8aMi8xMPwQs4rdkeuEULdElFG8n8JMmM0EjNdyQoxPrlg4QHVRze tMoA== X-Gm-Message-State: AN3rC/4/Zq98mzDja3DNAlpqfx7i6+s1c4B0eRr6VJeZeBxldgxcj7HK +kcWShk5UszgHq0VOsI5TGAQsPKemsraB1s= X-Received: by 10.13.203.73 with SMTP id n70mr21274311ywd.71.1492545153701; Tue, 18 Apr 2017 12:52:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 18 Apr 2017 12:51:53 -0700 (PDT) In-Reply-To: <20170418194134.GA13232@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170418194134.GA13232@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 18 Apr 2017 15:51:53 -0400 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114fd3d6b2f841054d763f3c Archived-At: Subject: Re: [TLS] PR#962:CertificateRequest in post-handhake phase X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 19:52:36 -0000 --001a114fd3d6b2f841054d763f3c Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 3:41 PM, Ilari Liusvaara wrote: > On Tue, Apr 18, 2017 at 09:48:33AM -0400, Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/pull/962 > > Target merge date: Thursday > > > > In reviewing the specification, I noticed that we seem to have banned the > > use of CertificateRequest with PSK both in the main handshake and in the > > post-handshake phase. I don't believe that this was intentional and it > > makes it very hard to use client auth with resumption. Accordingly I have > > filed the above PR to remove that restriction (while retaining it for the > > main handshake). As I understand it, several of the analyses we have > > already assumed this case and covered it, so no additional work is needed > > there. > > On topic of PSKs, I noticed that TLS 1.3 makes it very easy to mount > dictionary attacks against PSK, regardless of DHE-PSK (especially to > recover the client PSK). I assumed that the document already documents > this, but I couldn't find any remark that using low-entropy PSKs is very > bad idea. > Good point. As far as I can tell... 1. You can search the binder. 2. Because we forbid PSK with server authentication, you can also impersonate the server and then mount a dictionary attack (even w/o the binder). I agree that this should be documented. I filed https://github.com/tlswg/tls13-spec/issues/965 so we don't forget this. I'll take a PR if you have one. IIRC, the TLS 1.0-1.2 PSK RFC does discuss dictionary attacks a bit. Yes, it does. Someone could crib from that.... -Ekr > > -Ilari > --001a114fd3d6b2f841054d763f3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 18, 2017 at 3:41 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Tue, Apr 18, 2017 at 09:48:33AM -0400= , Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/pull/962
> Target merge date: Thursday
>
> In reviewing the specification, I noticed that we seem to have banned = the
> use of CertificateRequest with PSK both in the main handshake and in t= he
> post-handshake phase. I don't believe that this was intentional an= d it
> makes it very hard to use client auth with resumption. Accordingly I h= ave
> filed the above PR to remove that restriction (while retaining it for = the
> main handshake). As I understand it, several of the analyses we have > already assumed this case and covered it, so no additional work is nee= ded
> there.

On topic of PSKs, I noticed that TLS 1.3 makes it very easy to mount=
dictionary attacks against PSK, regardless of DHE-PSK (especially to
recover the client PSK). I assumed that the document already documents
this, but I couldn't find any remark that using low-entropy PSKs is ver= y
bad idea.


<= div>impersonate the server and then mount a dictionary attack (even w/o the=

I'll take a PR if you have one.



IIRC, the TLS 1.0-1.2 PSK RFC does discuss dictionary attacks a bit.

Yes, it does. Someone could crib from that....

-Ekr



-Ilari

--001a114fd3d6b2f841054d763f3c-- From nobody Tue Apr 18 13:44:10 2017 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 D41FA128CDC for ; Tue, 18 Apr 2017 13:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 yysJzdw4-HBb for ; Tue, 18 Apr 2017 13:44:05 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id AD4BF1200FC for ; Tue, 18 Apr 2017 13:44:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 639ED1FCE9; Tue, 18 Apr 2017 23:44:03 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id RUPXmmjwqb-Y; Tue, 18 Apr 2017 23:44:03 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 11A5EC4; Tue, 18 Apr 2017 23:44:03 +0300 (EEST) Date: Tue, 18 Apr 2017 23:44:02 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170418204401.GB13232@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170418194134.GA13232@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] PR#962:CertificateRequest in post-handhake phase X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 20:44:08 -0000 On Tue, Apr 18, 2017 at 03:51:53PM -0400, Eric Rescorla wrote: > On Tue, Apr 18, 2017 at 3:41 PM, Ilari Liusvaara > wrote: > > > > On topic of PSKs, I noticed that TLS 1.3 makes it very easy to mount > > dictionary attacks against PSK, regardless of DHE-PSK (especially to > > recover the client PSK). I assumed that the document already documents > > this, but I couldn't find any remark that using low-entropy PSKs is very > > bad idea. > > > > Good point. As far as I can tell... > > 1. You can search the binder. > 2. Because we forbid PSK with server authentication, you can also > impersonate the server and then mount a dictionary attack (even w/o the > binder). AFAICT, if I wanted to extract low-entropy client PSK, I wouldn't even bother with 2, since 1 seems so much more efficient (all passive too!).. Also, wonder if there are efficient ways of probing server PSKs (I didn't compe up with one, even in pure-PSK, due to binders making such probing nontrivial). -Ilari From nobody Tue Apr 18 13:47:13 2017 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 1625A128796 for ; Tue, 18 Apr 2017 13:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 3T2U8-t4WD7y for ; Tue, 18 Apr 2017 13:47:01 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 6090812944A for ; Tue, 18 Apr 2017 13:47:01 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id j9so2144693ywj.3 for ; Tue, 18 Apr 2017 13:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qD1Mo4/voMT07YRgjBe7kSfNXUuYwYDCkLP1ToAAkZs=; b=Smqz2Js3Io1UVd6UnmU1iz2s19w5Va79prAUwFMUIq3T5NoWbAOoChw7kDOfJUv8Vs jBZcs0mRWl8Rftn+oM3p1dzhmlIFLtXtH8ln0+6MhYrbGvIntDEaXMDW1BHwAaKS0+Ra /UogaI9tui+BBIwn1X67hEe7wVaenA0nFHWzL7efR8P8zYjfSAotpdX75dh+Yz2ED2WJ wXbmF+I4PHbKa3WFeuc2ryZpmUEALmicEiaCiuACFpUESbX8vPYu5wEAfP/OtZ+SayD0 M/X+V5iwSHjpwl/3oJBm695OQjeGf/L1FY6Q/hdXwIuLXsrBQHHcQXhdDr6jOIE0rmCt jp7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qD1Mo4/voMT07YRgjBe7kSfNXUuYwYDCkLP1ToAAkZs=; b=kCkes1mMVCvsP/lXN2yIyYrs66rkvuq7/llinwVvXF9eAkwFtCBanKUODzRRkviUZi xtcgGpiLNWJuTNKFmxLME+eooR3lT58EkAnomjiktX0rBaePhSI+PlzmLemVfqLGe88X CJprCCfilx85O9kBUq6bk50y6/aQwoQ7qaFav2SB39PD7D3DJC4y7xb7uEkvnyNwE6zz EEuuCXTcNM9OfPSbr/1kWRVV6gBE5CS1+CLi1asu/9V9p2vV91QYYKjzxBEQNY5c/wp8 rt2Wgb4cVTxFVNpaVZaK0ygRtIFW6XH1Pjt3g8Y0DwO/s/Ii4o633MwHNvHifDsjf7A9 5BcA== X-Gm-Message-State: AN3rC/5ORFhnE9B0B3QEDqVWTEJzbna005X05dfh5czlyCvAblD0WMUT Lc4+eicTqMvOV8oI874EGXsd+zKLtQ== X-Received: by 10.129.182.65 with SMTP id h1mr21915135ywk.337.1492548420708; Tue, 18 Apr 2017 13:47:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 18 Apr 2017 13:46:20 -0700 (PDT) In-Reply-To: <20170418204401.GB13232@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170418194134.GA13232@LK-Perkele-V2.elisa-laajakaista.fi> <20170418204401.GB13232@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 18 Apr 2017 16:46:20 -0400 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1bde9c6d41c6054d77021f Archived-At: Subject: Re: [TLS] PR#962:CertificateRequest in post-handhake phase X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 20:47:08 -0000 --94eb2c1bde9c6d41c6054d77021f Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 4:44 PM, Ilari Liusvaara wrote: > On Tue, Apr 18, 2017 at 03:51:53PM -0400, Eric Rescorla wrote: > > On Tue, Apr 18, 2017 at 3:41 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > > On topic of PSKs, I noticed that TLS 1.3 makes it very easy to mount > > > dictionary attacks against PSK, regardless of DHE-PSK (especially to > > > recover the client PSK). I assumed that the document already documents > > > this, but I couldn't find any remark that using low-entropy PSKs is > very > > > bad idea. > > > > > > > Good point. As far as I can tell... > > > > 1. You can search the binder. > > 2. Because we forbid PSK with server authentication, you can also > > impersonate the server and then mount a dictionary attack (even w/o the > > binder). > > AFAICT, if I wanted to extract low-entropy client PSK, I wouldn't even > bother with 2, since 1 seems so much more efficient (all passive too!).. > I agree. I just meant that if we were to dispense with the binder it would still be trivial. -Ekr > > > Also, wonder if there are efficient ways of probing server PSKs (I > didn't compe up with one, even in pure-PSK, due to binders making > such probing nontrivial). > > > -Ilari > --94eb2c1bde9c6d41c6054d77021f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 18, 2017 at 4:44 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Tue, Apr 18, 2017 at 03:51:53PM -0400, Eric Rescorla wrote: > On Tue, Apr 18, 2017 at 3:41 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> >
> > On topic of PSKs, I noticed that TLS 1.3 = makes it very easy to mount
> > dictionary attacks against PSK, regardless of DHE-PSK (especially= to
> > recover the client PSK). I assumed that the document already docu= ments
> > this, but I couldn't find any remark that using low-entropy P= SKs is very
> > bad idea.
> >
>
> Good point. As far as I can tell...
>
> 1. You can search the binder.
> 2. Because we forbid PSK with server authentication, you can also
> impersonate the server and then mount a dictionary attack (even w/o th= e
> binder).

AFAICT, if I wanted to extract low-entropy client PSK, I wouldn'= t even
bother with 2, since 1 seems so much more efficient (all passive too!)..

I agree. I just meant that if we were to = dispense with the binder it would
still be trivial.
-Ekr
=C2=A0


Also, wonder if there are efficient ways of probing server PSKs (I
didn't compe up with one, even in pure-PSK, due to binders making
such probing nontrivial).


-Ilari

--94eb2c1bde9c6d41c6054d77021f-- From nobody Tue Apr 18 14:56:45 2017 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 2283612EC7A for ; Tue, 18 Apr 2017 14:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GA1TGC-p-iur for ; Tue, 18 Apr 2017 14:56:40 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 BD7D5129485 for ; Tue, 18 Apr 2017 14:56:39 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id q26so3926696uaa.0 for ; Tue, 18 Apr 2017 14:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fHhqVtkW6JbwNT8VzMu3lxhfe6JMBdyjSJF6YFb9VmE=; b=hKM4KQqGKRIg2hNIKrqNgPY9075oOkw7aKBsC9vgjodhEaPvps/a2Dw3ej24dHnGSA zejgcu8xLHWdwWqQwGqmcqlviU7F427AquWSJdp6Mhwx338uvsoJOBrvED0twidpBdAe JI2ZGjsmHRUL35T1xLcOhoWmPAo5qRr1zovt8DEQk8Ky/G0YREQ7IAOlyE3OG173q/Qq R6Cz+urL9Ej1YQbZ3R1PqHCh8wAC5st4KOTrXJtWpaa3e4+02l/0TUeH3S8cH6lVedyk aOmhOzd6Ue6C7xTPyrE60eJ6pqCV0MAteyPsRl8oMPSl/sNd++0t+1CanQmEtGjv8wIq bQDg== 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=fHhqVtkW6JbwNT8VzMu3lxhfe6JMBdyjSJF6YFb9VmE=; b=g85eXdI6TS38k8PYAoorTicwXVKUXGMiVrHUfMw4oLLHdbwn4IqbOBAWYUjPwsUYaq iliKF0PjjFbrfQb+H3fNTNLZPMjswujewK6fB5fiV+LhkwvJVz9QUmoBlKTSZqIUFpO5 jQXuXZmfhigosBR44oOWmCLM+a+QaU9Cj6jKvd8yoDiGtk/LYSF6VnoNlScx9o3FAXoN dfHwp9K6gwCjQBR2b85ELV5oylZV4EKNnL61ur476YJy8ZhHGVQDP0fQSDqWeSfyPz80 eDuYK5c/Jm7P0g3HU9P61caBQugvTcbyWUcimX28xgwFfDa+waUXw/RqOq5TmydNuFu2 B97w== X-Gm-Message-State: AN3rC/6QFW4DI/LA3lsRo8M5OS+ICAEMM3K/4oUGfGGuhND0bBkQ2kj+ WsW+A13wfiWZmIoXe1ADp2iQGsLC9g== X-Received: by 10.176.78.129 with SMTP id l1mr14200458uah.24.1492552598774; Tue, 18 Apr 2017 14:56:38 -0700 (PDT) MIME-Version: 1.0 References: <20170414114425.GA3649@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170414114425.GA3649@LK-Perkele-V2.elisa-laajakaista.fi> From: Nick Sullivan Date: Tue, 18 Apr 2017 21:56:28 +0000 Message-ID: To: Ilari Liusvaara , Joseph Salowey Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f403043ed4a875687d054d77fb72 Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 21:56:42 -0000 --f403043ed4a875687d054d77fb72 Content-Type: text/plain; charset=UTF-8 Thanks for the review. Comments/questions inline. I put together a pull request with your suggested changes here if you would like to review: https://github.com/grittygrease/tls-exported-authenticator/pull/11 On Fri, Apr 14, 2017 at 4:44 AM Ilari Liusvaara wrote: > On Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph Salowey wrote: > > Hey Folks, > > > > At the IETF 98 meeting in Chicago there was support in the room to adopt > > draft-sullivan-tls-exported-authenticator [0]. We are looking for > feedback > > on adopting this draft form the list. Please respond if you support the > > draft and are willing to review it. If you object to its adoption, please > > let us know why. Please respond to the list by 20170501 > > > > Looking at the draft and reviewing it: > > - Section 1: > > The section should also say a bit why not to use post-handshake > authentication. Which is not available at all for server, won't > work properly with multiplexed connections, etc... > Can do. > > - Section 2: > > Probable typo: "encryped" (in last line of first paragraph on page 3). > Fixed. > > - Section 2: > > I think there should be "(for TLS 1.3)" after reference to the TLS 1.3 > draft in definition of handshake context. Otherwise it will read oddly > after draft reference gets replaced by reference to the RFC. > Good catch. > > - Section 2: > > I think the finished MAC key length should always follow the PRF hash. > TLS 1.2 with EMS requires well-defined PRF hash anyway, and some cipher- > suites have SHA-1 as HMAC hash. > This was noted before. It's tracked as issue #7 ( https://github.com/grittygrease/tls-exported-authenticator/issues/7) > > - Section 2 > > I think giving random number as example of request context is bad, > and one should instead give some sequence number (with possible gaps) > as example. > > These things do not have to be random, and generating sequence > numbers in connection context is much easier than random numbers. > Ok. > > - Section 2: > > The spec should be clear if message headers are included or not (the > hashes seem injective either way). > > If message headers are included, perhaps wrap the context into > synthethic hash message like with first CH when retrying handshake in > TLS 1.3. One could even reuse the message type (#254). > The text uses a plain Hash, not a Transcript-Hash, so there should be no confusion about including message headers. What is the motivation for incorporating message headers? > > - Section 4: > > Nitpick: The framework is usually called SIGMA, not SIGMAC (reference). > The reference here is to the 2016 paper which describes the SIGMA Compiler, which I've seen referenced as SIGMAC, vs. the original SIGMA paper. > > - Section 4: > > The last two security considerations look pretty hard to understand, > and overly long. > > As I understand it, those paragraphs mean something like: > > ---------------------- > Authenticators are independent and unidirectional, and as consequence: > > * It is difficult to formally prove an endpoint is jointly > authoritative over multiple certificates instead of individually > authoritative over each. > > * There is no feedback on if authenticator was processed, at what > point of connection it was processed nor if it was accepted. Any > such feedback needs to be implemented at application layer.if > required. > ---------------------- > > (As note, the TLS-built-in authentication fails most of the second > part as well, for various reasons. > Yes, it was hard to read. Thanks for the summary, I've re-written it to be more clear in the PR. > > > - Section 4: > > Perhaps add consideration that this SHOULD be implemented inside TLS > library (or at least as an library), even if it is possible to implement > outside it. > Updated text. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f403043ed4a875687d054d77fb72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the review.

Comments/questions inline. I= put together a pull request with your suggested changes here if you would = like to review:
https://github.com/grittygrease/tls-exported-authent= icator/pull/11

= On Fri, Apr 14, 2017 at 4:44 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph = Salowey wrote:
> Hey Folks,
>
> At the IETF 98 meeting in Chicago there was support in the room to ado= pt
> draft-sullivan-tls-exported-authenticator [0]. We are looking for feed= back
> on adopting this draft form the list. Please respond if you support th= e
> draft and are willing to review it. If you object to its adoption, ple= ase
> let us know why. Please respond to the list by 20170501
>

Looking at the draft and reviewing it:

- Section 1:

The section should also say a bit why not to use post-handshake
authentication. Which is not available at all for server, won't
work properly with multiplexed connections, etc...
Can= do.

- Section 2:

Probable typo: "encryped" (in last line of first paragraph on pag= e 3).
Fixed.

- Section 2:

I think there should be "(for TLS 1.3)" after reference to the TL= S 1.3
draft in definition of handshake context. Otherwise it will read oddly
after draft reference gets replaced by reference to the RFC.
Good catch.

- Section 2:

I think the finished MAC key length should always follow the PRF hash.
TLS 1.2 with EMS requires well-defined PRF hash anyway, and some cipher- suites have SHA-1 as HMAC hash.
This was noted before.= It's tracked as issue #7 (https://github.com/grittygrease/tls-exp= orted-authenticator/issues/7)
=C2=A0

- Section 2

I think giving random number as example of request context is bad,
and one should instead give some sequence number (with possible gaps)
as example.

These things do not have to be random, and generating sequence
numbers in connection context is much easier than random numbers.
Ok.
=C2=A0

- Section 2:

The spec should be clear if message headers are included or not (the
hashes seem injective either way).

If message headers are included, perhaps wrap the context into
synthethic hash message like with first CH when retrying handshake in
TLS 1.3. One could even reuse the message type (#254).
The text uses a plain Hash, not a Transcript-Hash, so there should be no c= onfusion about including message headers. What is the motivation for incorp= orating message headers?
=C2=A0

- Section 4:

Nitpick: The framework is usually called SIGMA, not SIGMAC (reference).
=

The reference here is to the 2016 paper wh= ich describes the SIGMA Compiler, which I've seen referenced as SIGMAC,= vs. the original SIGMA paper.

- Section 4:

The last two security considerations look pretty hard to understand,
and overly long.

As I understand it, those paragraphs mean something like:

----------------------
Authenticators are independent and unidirectional, and as consequence:

=C2=A0* It is difficult to formally prove an endpoint is jointly
=C2=A0 =C2=A0authoritative over multiple certificates instead of individual= ly
=C2=A0 =C2=A0authoritative over each.

=C2=A0* There is no feedback on if authenticator was processed, at what
=C2=A0 =C2=A0point of connection it was processed nor if it was accepted. A= ny
=C2=A0 =C2=A0such feedback needs to be implemented at application layer.if<= br> =C2=A0 =C2=A0required.
----------------------

(As note, the TLS-built-in authentication fails most of the second
part as well, for various reasons.

Yes,= it was hard to read. Thanks for the summary, I've re-written it to be = more clear in the PR.


- Section 4:

Perhaps add consideration that this SHOULD be implemented inside TLS
library (or at least as an library), even if it is possible to implement outside it.

=C2=A0Updated text.


-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--f403043ed4a875687d054d77fb72-- From nobody Tue Apr 18 15:18:18 2017 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 AC1631314A7 for ; Tue, 18 Apr 2017 15:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9nbM8c67E9bm for ; Tue, 18 Apr 2017 15:18:15 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 D4E7E1314A1 for ; Tue, 18 Apr 2017 15:18:14 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id h2so4163210uaa.1 for ; Tue, 18 Apr 2017 15:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CCIbS49hAj2H/bR8VlxlUF8VKeHcHa9LWtIGaVAXC/Q=; b=oNFXPuTiIZlQmT0nePQeR94aTyiVp8075xpRCO0wnIWVRPRLYdWOjFNNbMCoR8sYAN MIbDC1GOjtfJTLDxHHys8QO091Xz52VESBJwD6geeye6InnLtzBKOi+BXzDzIVnALs0u Z/tRxSmuwkJ8IpQK/8xaZ5XcLOjHvt4euNr2JX8+do60/wfNv0IoTdfJLzswtI5J2FLO P4eFuPjwrcKS4y47lHftQ/sQauYSXspJ98NRN1Hx+DVu8GidenljWNxLkcO6o9/+hcMe A0pvBrC2ic2KOFUAwTXp4gyu+AQ4j/26lIGDs++NwpA4cHsOBrqA1ZjekzXoK+qkgJbQ B3MQ== 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; bh=CCIbS49hAj2H/bR8VlxlUF8VKeHcHa9LWtIGaVAXC/Q=; b=E1iIVHiPC0T4VsxFrHRjym8FucTv+CMryYkL10oRG69UiBq0Mo0mUgYHwRd/NNftKw YdbnSvoxblphIMdudtwAldXQGy65uZUQ+FMEKjFLnnsPXvjd1GiQ99/PIf00IqvSb228 6MRJ+AEMxTyu0ALwhNmMixQRZ63TM3oyy38MHqc3XExj2LfSHDVMVKV/CNaEp0b38NA7 wBD6OILqQKTiCLqlnVsitnqK0qHXMzzT81G6hs2RRchjxdhRC9rH39g+XCO5nc2E4Kwc Qv3l3bGKLLDTZslIOFimMTMjW6FGYa2C4/MtYGCLgI4pduTA/AwhJNv1veYYyfjzhbKk c07w== X-Gm-Message-State: AN3rC/5mGcRovDBL/EdwOIYAIVpeDI7hCjnkGYkjzkn6+5u3fzvA9VOG dUmw2eW43Mv5qGZ+UwKykeTfuvrReQ== X-Received: by 10.159.37.248 with SMTP id 111mr13163843uaf.146.1492553894049; Tue, 18 Apr 2017 15:18:14 -0700 (PDT) MIME-Version: 1.0 References: <20170414114425.GA3649@LK-Perkele-V2.elisa-laajakaista.fi> <20170415134152.GA7893@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170415134152.GA7893@LK-Perkele-V2.elisa-laajakaista.fi> From: Nick Sullivan Date: Tue, 18 Apr 2017 22:18:03 +0000 Message-ID: To: Ilari Liusvaara , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113d1b98a9ba51054d7848b7 Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 22:18:17 -0000 --001a113d1b98a9ba51054d7848b7 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 15, 2017 at 6:42 AM Ilari Liusvaara wrote: > On Fri, Apr 14, 2017 at 02:44:25PM +0300, Ilari Liusvaara wrote: > > On Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph Salowey wrote: > > > Hey Folks, > > > > > > At the IETF 98 meeting in Chicago there was support in the room to > adopt > > > draft-sullivan-tls-exported-authenticator [0]. We are looking for > feedback > > > on adopting this draft form the list. Please respond if you support the > > > draft and are willing to review it. If you object to its adoption, > please > > > let us know why. Please respond to the list by 20170501 > > > > > > > Looking at the draft and reviewing it: > > Another edge-case I figured: > > How do certificate type extensions (#9, #19 and #20) work with exported > authenticators? > > Where other extensions are either meaningless or are edditional info, > certificate types actually change the format of the first certificate, > which the library needs to understand in order to extract the SPKI for > validating the following CertificateVerify. > I think it would be fair to only support server-generated exported authenticators with the certificate_type negotiated by the TLS handshake. If the client sent a list of server_certificate_types in its client hello, then only authenticators of that type can be used (with the chosen type included an extension to the certificate message). Similarly, if the server's EE message contains a single client_certificate_type, that would be the only type supported by client-generated exported authenticators. I can add text to this effect ( https://github.com/grittygrease/tls-exported-authenticator/issues/12). > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113d1b98a9ba51054d7848b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


O= n Sat, Apr 15, 2017 at 6:42 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Fri, Apr 14, 2017 at 02:44:25PM +0300, Ilari Li= usvaara wrote:
> On Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph Salowey wrote:
> > Hey Folks,
> >
> > At the IETF 98 meeting in Chicago there was support in the room t= o adopt
> > draft-sullivan-tls-exported-authenticator [0]. We are looking for= feedback
> > on adopting this draft form the list. Please respond if you suppo= rt the
> > draft and are willing to review it. If you object to its adoption= , please
> > let us know why. Please respond to the list by 20170501
> >
>
> Looking at the draft and reviewing it:

Another edge-case I figured:

How do certificate type extensions (#9, #19 and #20) work with exported
authenticators?

Where other extensions are either meaningless or are edditional info,
certificate types actually change the format of the first certificate,
which the library needs to understand in order to extract the SPKI for
validating the following CertificateVerify.

=
I think it would be fair to only support server-generated exported aut= henticators with the certificate_type negotiated by the TLS handshake. If t= he client sent a list of server_certificate_types in its client hello, then= only authenticators of that type can be used (with the chosen type include= d an extension to the certificate message). Similarly, if the server's = EE message contains a single client_certificate_type, that would be the onl= y type supported by client-generated exported authenticators. I can add tex= t to this effect (https://github.com/grittygrease/tls-exported-authen= ticator/issues/12).



-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113d1b98a9ba51054d7848b7-- From nobody Tue Apr 18 15:23:06 2017 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 D44D61314C0 for ; Tue, 18 Apr 2017 15:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AEPaqzl6KJHY for ; Tue, 18 Apr 2017 15:22:54 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 C8111128BA2 for ; Tue, 18 Apr 2017 15:22:53 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id q26so4239180uaa.0 for ; Tue, 18 Apr 2017 15:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J/BWI76Zi4ORdM2ArBfD11U4Ld1nGC+ZSPUphS+9Dxc=; b=KK0jaoTShydolsv9PxeOBdnAIAo0XPe+LFdNyWmm3cFUJtof5BEl6iS7vcW1fNQ8P7 lZO2/vghXTKWVf0odrxGsInYr/yZp5DasMTj+AIUe+pZJjunZ6wCu29dWZ37vZCJiKZY 5BdkN7DJOAT2/Zo0kEBNMYU+1XrVUS5Eh9vtuJOJaogcFcrB+kfpFhpdPmyjzauH3/ct xep72WsASq3UTG0aqy1EN96ET6Qe3utO/sUUgd05VNPTqRLlKOTMCOm/q9modwUdQQTR Qp2Ax2u+nSDU5F0KFfseyNLISRg1pJ5LN1/EeMIzhhTRA3eQLMPhiCNIU5Dw6S8PmH3/ 1OnA== 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=J/BWI76Zi4ORdM2ArBfD11U4Ld1nGC+ZSPUphS+9Dxc=; b=BrbOXRUY/vCZcCMY8OY1IHZPLXt1ACVba/inIMuashmiq0IZMFDAGkLan/OgmR1UKy 5agx6p4Kf+4Ud5N67L47iWYdHnPPMBG/mpmh6ZBAsHUSVACWNsuI5MyzZtEt9y3ZewBZ P/F+DNwbZEw9yayWW1UR4z0dIPd7kuKUSvH6WqT4fyp13Z+cLzDyia9DjoY5ySowA+5c lYKDPwMLuke13lfngn2LhM6/9KDgEWEMZADKGxEEVerC6b9vI+OJOwA6v+q8GFTNYex/ 6zq6uG0it5J84c1UHBB13xiLBMAamWwZzjI1lv6extWvKDvCjCuLbP1GvOax0XABOH65 qvAA== X-Gm-Message-State: AN3rC/6l8wZoF3fMjqs4hf6Z2rO+ztwAJMqErIaJvj438Ml1OOCiXsge gBhfUuugUBSE9x319PDyQDrpH1LfWg== X-Received: by 10.176.5.194 with SMTP id e60mr11268573uae.71.1492554172969; Tue, 18 Apr 2017 15:22:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Tue, 18 Apr 2017 22:22:42 +0000 Message-ID: To: Victor Vasiliev , Joseph Salowey Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c12333449b965054d7859d8 Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 22:22:58 -0000 --94eb2c12333449b965054d7859d8 Content-Type: text/plain; charset=UTF-8 Thanks for the review. I'm open to adding text indicating that the exported authenticator SHOULD be sent using an application protected by the TLS stream in question, but I don't want to remove the possibility of sending the data over a secure secondary channel, depending on the application. Nick On Tue, Apr 18, 2017 at 8:29 AM Victor Vasiliev wrote: > I've read the draft, and I support its adoption. I believe that the > mechanism > is sound for its stated use. > > I have some minor concerns about the wording in the draft, though. First, > the > draft describes the authenticators as sent "out-of-band", while my > understanding is that they are always intended to be sent in-band as > application data. If they were truly sent out-of-band, there would be some > questions about the security analysis, because that would imply those > could be > sent unprotected. Hence, I suggest the draft to adapt the premise that > exported authenticators MUST be sent as application data within the same > connection. This might simplify your security proofs too. > > The second issue I have is with the question of when does authentication > succeed. In TLS, by the time any party can send application data, normally > (with exception of server-to-client data in client auth case) both parties > know > that the other side has authenticated them. Here, a new identity is > introduced > while application data can be already in flight, and it's not clear to me > when > the sender of the exported authenticator can act assuming the peer has > accepted > its new identity. My current understanding is that this issue is deferred > to > the application layer, but it would be nice to discuss those considerations > explicitly. > > The last question I have is how does this interact with the state of TLS > connection. Does accepting a new identity mean that the entire connection > now > has that identity too? Does this mean that the session tickets issued > after > the library receives the authenticator are valid for the new identity? > Does it > make the tickets sent previously on that connection valid for the new > identity? > > Also, what is the distinction between "jointly authoritative for A and B" > and > "individually authoritative for A and individually authoritative for B"? > > -- Victor. > On Fri, Apr 14, 2017 at 12:29 AM, Joseph Salowey wrote: > >> Hey Folks, >> >> At the IETF 98 meeting in Chicago there was support in the room to adopt >> draft-sullivan-tls-exported-authenticator [0]. We are looking for >> feedback on adopting this draft form the list. Please respond if you >> support the draft and are willing to review it. If you object to its >> adoption, please let us know why. Please respond to the list by 20170501 >> >> Cheers, >> >> J&S >> >> [0] >> https://datatracker.ietf.org/doc/html/draft-sullivan-tls-exported-authenticator >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c12333449b965054d7859d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the review. I'm open to adding text in= dicating that the exported authenticator SHOULD be sent using an applicatio= n protected by the TLS stream in question, but I don't want to remove t= he possibility of sending the data over a secure secondary channel, dependi= ng on the application.

Nick

On Tue, Apr 18, 2017 at 8:29 AM Victor Vasiliev = <vasilvv@google.com> wrote:=
I've rea= d the draft, and I support its adoption.=C2=A0 I believe that the mechanism=
is sound for its stated use.

I have som= e minor concerns about the wording in the draft, though.=C2=A0 First, the
draft describes the authenticators as sent "out-of-band"= , while my
understanding is that they are always intended to be s= ent in-band as
application data.=C2=A0 If they were truly sent ou= t-of-band, there would be some
questions about the security analy= sis, because that would imply those could be
sent unprotected.=C2= =A0 Hence, I suggest the draft to adapt the premise that
exported= authenticators MUST be sent as application data within the same
= connection.=C2=A0 This might simplify your security proofs too.
<= br>
The second issue I have is with the question of when does aut= hentication
succeed.=C2=A0 In TLS, by the time any party can send= application data, normally
(with exception of server-to-client d= ata in client auth case) both parties know
that the other side ha= s authenticated them.=C2=A0 Here, a new identity is introduced
wh= ile application data can be already in flight, and it's not clear to me= when
the sender of the exported authenticator can act assuming t= he peer has accepted
its new identity.=C2=A0 My current understan= ding is that this issue is deferred to
the application layer, but= it would be nice to discuss those considerations
explicitly.

The last question I have is how does this interact wi= th the state of TLS
connection.=C2=A0 Does accepting a new identi= ty mean that the entire connection now
has that identity too?=C2= =A0 Does this mean that the session tickets issued after
the libr= ary receives the authenticator are valid for the new identity?=C2=A0 Does i= t
make the tickets sent previously on that connection valid for t= he new identity?

Also, what is the distinction bet= ween "jointly authoritative for A and B" and
"indi= vidually authoritative for A and individually authoritative for B"?

=C2=A0 -- Victor.
=
On Fri, Apr 14, 2017 = at 12:29 AM, Joseph Salowey <joe@salowey.net> wrote:
=
Hey Folks= ,

At the IETF 98 meeting in Chicago there was sup= port in the room to adopt=C2=A0draft-sullivan-= tls-exported-authenticator=C2=A0[0]. We are looking for feedback on adopting this draft form the= list. Please respond if you support the draft and are willing to review it= . If you object to its adoption, please let us know why. Please respond to = the list by 20170501

Cheers,

J&S


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--94eb2c12333449b965054d7859d8-- From nobody Tue Apr 18 22:48:01 2017 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 7E29C131513 for ; Tue, 18 Apr 2017 22:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 ulkOi-Dr9Plh for ; Tue, 18 Apr 2017 22:47:56 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id A00F013151D for ; Tue, 18 Apr 2017 22:47:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 95C8C24110; Wed, 19 Apr 2017 08:47:53 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id FpalrVUYqk-Z; Wed, 19 Apr 2017 08:47:53 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 3D7FFC4; Wed, 19 Apr 2017 08:47:53 +0300 (EEST) Date: Wed, 19 Apr 2017 08:47:52 +0300 From: Ilari Liusvaara To: Nick Sullivan Cc: "tls@ietf.org" Message-ID: <20170419054752.GA13952@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170414114425.GA3649@LK-Perkele-V2.elisa-laajakaista.fi> <20170415134152.GA7893@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 19 Apr 2017 05:47:59 -0000 On Tue, Apr 18, 2017 at 10:18:03PM +0000, Nick Sullivan wrote: > On Sat, Apr 15, 2017 at 6:42 AM Ilari Liusvaara > wrote: > > > > How do certificate type extensions (#9, #19 and #20) work with exported > > authenticators? > > > > Where other extensions are either meaningless or are edditional info, > > certificate types actually change the format of the first certificate, > > which the library needs to understand in order to extract the SPKI for > > validating the following CertificateVerify. > > > > I think it would be fair to only support server-generated exported > authenticators with the certificate_type negotiated by the TLS handshake. > If the client sent a list of server_certificate_types in its client hello, > then only authenticators of that type can be used (with the chosen type > included an extension to the certificate message). Similarly, if the > server's EE message contains a single client_certificate_type, that would > be the only type supported by client-generated exported authenticators. I > can add text to this effect ( > https://github.com/grittygrease/tls-exported-authenticator/issues/12). There are two bad problems with this: - The certificate types in TLS 1.3 are a bad hack just for bare minimum support for RPK. Using the thing for client post-handshake auth is completely unworkable. And adding new certificate types is pretty much only workable in special applications[1]. - Relying on TLS capability negotiation is fundamentally problematic. There capabilties may not match. And things get downright unworkable when things like signature algorithms are considered. [1] The recent ITS stuff might be one of these applications. Basically, you can only handle one certificate per type, any more and one gets issues. And one certificate per type impiles that one does not need post-handshake authentication. -Ilari From nobody Wed Apr 19 06:42:20 2017 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 588EC1293F4; Wed, 19 Apr 2017 06:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DNOeFdvYWeV2; Wed, 19 Apr 2017 06:42:04 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 D057B12954C; Wed, 19 Apr 2017 06:42:03 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id 88so12666450lfr.0; Wed, 19 Apr 2017 06:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7yv8aaNDLSr+ih/U2r052EByrm4enzqNNr6+b73PgU8=; b=q8wHsZFt4cohSrurEWJLJOQe2flZhRHZdavVvGpqggavQXyw5bQc/vHRSqFwSjKniw QXqXoH1zqns25Ipsp8C9HUoIIwFsqzYaqsDti1e9PgcSEWhATsshJe+3gMam8YlC5UCd Uemh2NjIyU67Ex578/okGz0kQu+eKxY7lAelEZoB+1rlnM/WPdXlliRZK3agd6sDthc8 g+xd2z9EfBnf1lL/yOm7HH4kfmDiWd1oXucFTi/w64WkPJsRR7NyCOyIg+40z2XIRhwn QImOEDqeg62yAE0zAA6dXYeLK+vsZy3TNDNETMMWE90oiljr0CbaJNND1Ju88kDIS3OY Hchg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7yv8aaNDLSr+ih/U2r052EByrm4enzqNNr6+b73PgU8=; b=gyL5BEJSesbVkHdklXEb7nZzWezTuxKotcResDLOMWBqp0Me2eg25wAUAPujEp1mBZ ic2eXG0LQzJnWR9V08cHmLAHNvQ6k/ZZ+Bn1M0ukvAKRN4DKiPvA+jw6EpoXxIibxED8 ZyWiWZDljEYg12sPtypCQ8D0nv5pceAfOOPbBe7uTQMIgfjEDTvwqfQEL4FbgLn03XaE P+OHgJuiIckkjDDtidVHev3cvvQzCHIOoUjrYRMJ8iMLnKm/6SaJZ4AGo/L8kPTR0UfJ HXoapbhTUQ/0jNsrY1Ws3ma5oXKgD89rW3h8jCMqz/hwy7ZKdk6WF2uU2YBRnBvG29uM QWYA== X-Gm-Message-State: AN3rC/7g5J7f2/7JEiCCoIrA0KSUCsDiT0OH80Ip5ztzPBN4Ya+Dr3gi cyL6gIt3DEpsagH1f0mI9BdvxUCFvA== X-Received: by 10.25.228.209 with SMTP id x78mr961889lfi.145.1492609322132; Wed, 19 Apr 2017 06:42:02 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Wed, 19 Apr 2017 06:42:01 -0700 (PDT) In-Reply-To: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> From: Daniel Migault Date: Wed, 19 Apr 2017 09:42:01 -0400 X-Google-Sender-Auth: R9pU2mFpUq-mKW8j4_hASBo4QUY Message-ID: To: Sean Turner Cc: "" , LURK BoF Content-Type: multipart/alternative; boundary=94eb2c0db33a6f2e0d054d853036 Archived-At: Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 19 Apr 2017 13:42:12 -0000 --94eb2c0db33a6f2e0d054d853036 Content-Type: text/plain; charset=UTF-8 Hi, I am in favor of adoption of the draft. This is an important issue we need to address. Yours, Daniel On Wed, Apr 12, 2017 at 3:31 PM, Sean Turner wrote: > All, > > At our IETF 98 session, there was support in the room to adopt > draft-rescorla-tls-subcerts [0]. We need to confirm this support on the > list so please let the list know whether you support adoption of the draft > and are willing to review/comment on the draft before 20170429. If you > object to its adoption, please let us know why. > > Clearly, the WG is going to need to work through the trade-offs between > short-lived certificates and sub-certs because both seem, to some, to be > addressing the same problem. > > Cheers, > > J&S > > [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts > _______________________________________________ > Lurk mailing list > Lurk@ietf.org > https://www.ietf.org/mailman/listinfo/lurk > --94eb2c0db33a6f2e0d054d853036 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am in favor of adoption= of the draft. This is an important issue we need to address.

Yours,
Daniel

On Wed, Apr 12, 2017 at 3:31 PM, Sean Turner <sean@sn3rd.com= > wrote:
All,

At our IETF 98 session, there was support in the room to adopt draft-rescor= la-tls-subcerts [0].=C2=A0 We need to confirm this support on the list so p= lease let the list know whether you support adoption of the draft and are w= illing to review/comment on the draft before 20170429.=C2=A0 If you object = to its adoption, please let us know why.

Clearly, the WG is going to need to work through the trade-offs between sho= rt-lived certificates and sub-certs because both seem, to some, to be addre= ssing the same problem.

Cheers,

J&S

[0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts
_______________________________________________
Lurk mailing list
Lurk@ietf.org
https://www.ietf.org/mailman/listinfo/lurk

--94eb2c0db33a6f2e0d054d853036-- From nobody Wed Apr 19 10:07:48 2017 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 C8FE7129B44 for ; Wed, 19 Apr 2017 10:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 YFkYf4j34kUh for ; Wed, 19 Apr 2017 10:07:44 -0700 (PDT) Received: from mail.objectiveintegration.uk (objectiveintegration.uk [134.213.135.47]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE4F128ACA for ; Wed, 19 Apr 2017 10:07:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.objectiveintegration.uk (Postfix) with ESMTP id 3C1A31A02E48; Wed, 19 Apr 2017 17:07:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at objectiveintegration.uk Received: from mail.objectiveintegration.uk ([127.0.0.1]) by localhost (mail.objectiveintegration.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWShtguycXon; Wed, 19 Apr 2017 17:07:18 +0000 (UTC) Received: from [192.168.110.3] (host86-136-73-40.range86-136.btcentralplus.com [86.136.73.40]) (Authenticated sender: mark.dunn@objectiveintegration.uk) by mail.objectiveintegration.uk (Postfix) with ESMTPSA id 7E83B1A01A96; Wed, 19 Apr 2017 17:07:18 +0000 (UTC) To: Eric Rescorla References: <16998c3d-4de6-7c88-d8a3-6d6193326500@objectiveintegration.uk> Cc: "tls@ietf.org" From: Mark Dunn Message-ID: Date: Wed, 19 Apr 2017 18:07:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] [xLS 1.3: cookie] - DTLS queries X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 19 Apr 2017 17:07:47 -0000 On 29/03/17 15:29, Eric Rescorla wrote: > Hi Mark, > > Thanks for your note. Some comments below... > > > On Wed, Mar 29, 2017 at 8:10 AM, Mark Dunn > > wrote: > > I am trying to implement cookie and finding it a little > underspecified. > > I am using the TLS 1.3 specified in github and > draft-rescorla-tls-dtls13-01 > > > 1a) Should a client expect to respond to a cookie during > session resumption? > > > Yes, it has to be ready to. As you say, it kills 0-RTT, but that's how > HRR always behaves. > I understand an HRR cookie should cause an extra round trip, but in this case because of "DTLS servers SHOULD perform a cookie exchange whenever a new handshake is being performed" And "Early data is not permitted after HelloRetryRequest." This results in 2-RTT as the default case, is this what you intended? > > 1b) If (1a) is false then do you agree that the "cookie" > extension MUST be accompanied by the "key_share" extension? > > > If I understand you correctly, then I think this is wrong. You only > send key_share to correct > the client's key_share, so if the client sent a key_share but you send > cookie to force > a round-trip, then you don't send key_share, just cookie. > OK, does this mean a change to DTLS 1.3 figure 4? from Client Server ClientHello +----------+ + key_share* | Flight 1 | + pre_shared_key* --------> +----------+ +----------+ <-------- HelloRetryRequest | Flight 2 | + cookie +----------+ to Client Server ClientHello +----------+ + key_share* | Flight 1 | + pre_shared_key* --------> +----------+ +----------+ <-------- HelloRetryRequest | Flight 2 | + cookie +----------+ * + key_share* * > > > > > 2) I understand this is too late for TLS(only DTLS SHOULD use > cookies) but is there a better solution than a cookie? > > > This seems like it would be a big restructure of the handshake, and > given the > relatively modest use of client auth in many contexts, I don't think > it would probably > be worth it. > > Best, > -Ekr > Many infrastructure devices: smart router, smart switch, virtual switch and most of the IoT require a publish / subscribe / notify pattern or an exception pattern. Do these not qualify? The following use case is a publish / subscribe / notify excerpt from my notes, from which I have further questions. This use case shows that while DTLS 1.3 is provably secure, it has been optimised to be very asymmetric in the way it delivers this security. * *(Sorry it is not the exact format you have used in the spec.) I have used "Accelerometer" and "Brake" in place of "Alice" and "Bob" :) Unlike people, *things* generally do not browse the web. It is likely that they will be commissioned, configured and left mostly to perform their primary function. Example: The *controller* configures communication between two *things*; an *accelerometer* and a *brake* to control wheel spin. The *controller* initiates a three way handshake with the *accelerometer* ClientHello ----- > +key_share… < ----- ServerHello +key_share…, { reference to the *accelerometer’s* certificate CertificateVerify, Finished } ClientResponse ----- > { reference to the*controller's *certificate, CertificateVerify, Finished } , [data:command] < ----- [data:ack] This establishes an ephemeral Diffie Hellman *shared key* which is used to encrypt the communication. The controller already knows the accelerometer and has cached its certificate, so does not require the *certificate chain* , but does require the CertificateVerify *signature* to authenticate the *accelerometer*. The *controller* then commands the *accelerometer* to *authorise* access for the *brake* to monitor it. Similarly, the*controller *communicates with the *brake* to command it to monitor the *accelerometer*. This process may provide both *things* with each other’s *certificates*. The *brake *initiates a three way handshake with the *accelerometer *to request a subscription to a value* * ClientHello ----- > +key_share… < ----- ServerHello +key_share…, { reference to the *accelerometer's *certificate, CertificateVerify, Finished } ClientResponse ----- > { reference to the *brake's* certificate, CertificateVerify, Finished }, [data:request:subscribe] < ----- [ Ack, NewSessionTicket, data:response:ack ] The *brake* makes a request, encrypted with the *shared key,* to monitor the *accelerometer* for sudden acceleration. They agree a *pre-shared key* to use on the next session. A session in this case is ended when either thing loses its ephemeral memory. When the *accelerometer* needs to inform the *brake* of high acceleration (wheel spin) The accelerometer uses the *shared key* to encrypt the Notification < ----- [data:notify:value] * *** *Subsequent Communications **(0-RTT or Zero Round Trip Time)* If either of the *things* loses their ephemeral memory, then they need to use the *pre-shared key *they agreed on earlier. This time the client is the *accelerometer.* ClientHello ----- > +pre_shared_key, +key_share, +early_data… (data:notify:value) < ----- ServerHello +pre_shared_key, +key_share…, {finished…} [data:ack] ClientResponse ----- > (endOfEarlyData) {finished} < ----- [Ack, NewSessionTicket] *Renegotiation* If the car is switched off then the next time it is switched on then full authentication is required once again (without the need for a certificate chain) *Further Questions *3) Is it true that the certificate or certificate chain are not required to be passed in the handshake, it is the client's ability to check the CertificateVerify signature against the certificate. This certificate may have been obtained by other means. If this is the case, could we have an explicit method to ask for either the certificate or the certificate chain rather than providing an expensive certificate chain by default. (I looked at raw certificates, but they do not seem to provide a path to root of trust) 4) Does the DDOS threat disappear if only certificate references or certificates are provided, removing the amplification threat and thus the need for a cookie? 5) I understand for pre_shared_key that we require a If we provide a CertificateVerify, why do we need a Finished as well? 6) In "Subsequent Communications" It was the old server, but now the new client that uses the pre_shared_key, what are your thoughts? 7) In TLS 1.3, i think it is implicit that a session corresponds to a TCP connection or similar, what are your recommendations for what constitutes a session in DTLS 1.3? I am still slogging through how to create a cookie, which is an exceptional version of Transcript-hash (TLS section 4.4.1), which I still haven't figured out.... From nobody Wed Apr 19 11:43:03 2017 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 B4569129BEE for ; Wed, 19 Apr 2017 11:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 K7jnSNka7a7L for ; Wed, 19 Apr 2017 11:43:00 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6185129C06 for ; Wed, 19 Apr 2017 11:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3903; q=dns/txt; s=iport; t=1492627379; x=1493836979; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ffW8e2ZSES8UwfUM876JO7nLf3id4zXuSDjZ+agLSJk=; b=Zx2W4UBcJ9rgok2sdbqw03I9/TTwGGvpGtzNap+rzWkeb/hI4fzBiblw 8pOm+1ZbppSjDjV6sAYxnv97Tr5ZDeLwU25sglqmLS1Q1EG6L7phL8Pgf /4Apcgskqv81WtoU13Spl2oiK555vF9AHIeKISzlNr8aHRkZowPff5yKv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAABCrvdY/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjXWRY3CQFoRcgg8hC4V4AoQEPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQE4NBcEAgEIDgMBAwEBHwkHJwsUAwYIAgQBEgiKCQgOrF+LIwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgjGEIoFdgmU0ghWCLIV7BZ0vAYcQi2KRVY9?= =?us-ascii?q?phCcBHzhLOmMVRIRmHIFjdYdegQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,222,1488844800"; d="scan'208";a="414731970" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2017 18:42:58 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3JIgwt9008223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Apr 2017 18:42:58 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Apr 2017 14:42:58 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Wed, 19 Apr 2017 14:42:58 -0400 From: "Scott Fluhrer (sfluhrer)" To: Douglas Stebila , "" Thread-Topic: [TLS] AdditionalKeyShare Internet-Draft Thread-Index: AQHSt6fE4KdrTyvutkKvp1tES2rNtqHNAAOw Date: Wed, 19 Apr 2017 18:42:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] AdditionalKeyShare Internet-Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 19 Apr 2017 18:43:02 -0000 > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Douglas Stebila > Sent: Monday, April 17, 2017 2:24 PM > To: > Subject: [TLS] AdditionalKeyShare Internet-Draft >=20 > Dear TLS mailing list, >=20 > We have posted an Internet-Draft > https://tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00 > for using an additional key share in TLS 1.3. The intended use case is t= o > provide support for transitional key exchange mechanisms in which both a > pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are used. > (Google's experiment with New Hope in 2016 had such an arrangement.) Our > draft replicates the functionality of the KeyShare extension in a new > extension called AdditionalKeyShare. Like KeyShare, the client's > AdditionalKeyShare contains a vector of KeyShareEntry structs. The server > can respond with a single matching KeyShareEntry in the AdditionalKeyShar= e > extension of its ServerHello. The resulting additional shared secret is i= ncluded > in the TLS key schedule after the ECDH shared secret. >=20 > While the motivation for our Internet-Draft is to facilitate the transiti= on to > post-quantum algorithms, our Internet-Draft does not specify any post- > quantum algorithms. We have a draft with similar goals; draft-whyte-qsh-tls13 . It also tries = to achieve Quantum-safeness through multiple key exchange mechanisms; howev= er in terms of protocol, it works somewhat differently. You have the 'norm= al' key exchange (as exists in the protocol), and a second one on the side.= We allows the client to define a hybrid group (which consists of several = key exchanges done in parallel). One of our goals was to stay within the e= xisting TLS architecture as much as possible (and thus limiting the changes= needed to the TLS state machine and parsing logic); things such as modifyi= ng the key derivation mechanism (such as you do) were considered to be too = large. It may be worth your while to go through our draft,,, >=20 > There are a couple of items for discussion related to this draft: >=20 > - We only provide a mechanism for a single AdditionalKeyShare, thus leadi= ng > to > the session establishing at most PSK + ECDHE + 1 additional shared secr= et. Is > there a value in even more shared secrets than that? Will someone want > to include more than one post-quantum algorithm? If so, our draft coul= d be > adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but we > did not > want to add that complexity unless there was desire for it. Our draft allows for that naturally. As for the need, well, I expect that some will want it. We don't have any = postquantum key exchanges that are both practical and really well trusted (= at least, to the same extent that (EC)DH is); I would expect that some peop= le will want to spread their risk and do (for example) x25519 + Frodo + SID= H. >=20 > - TLS 1.3 allows the client to restrict the use of PSKs that they provide= in > ClientHello through the "psk_key_exchange_modes" extension. The client > may, > for instance, request that the PSK only be used in a PSK+(EC)DHE mode, = so > as > to ensure that the resumed session has forward secrecy. It is unclear = the > best way to reconcile this with support for multiple key shares; we out= line > some possibilities in Section 4 of our Internet-Draft, and we welcome i= nput. >=20 > We have also created a pull request to TLS 1.3 draft 19 which includes a > clarification on how additional secrets are to be included in the TLS key > schedule. > https://github.com/jschanck/tls13-spec >=20 > John and Douglas >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 19 23:23:06 2017 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 6807D12EB11 for ; Wed, 19 Apr 2017 23:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.901 X-Spam-Level: X-Spam-Status: No, score=-4.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 x1QqNEtUDXJh for ; Wed, 19 Apr 2017 23:23:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 ACB4E12EB16 for ; Wed, 19 Apr 2017 23:22:58 -0700 (PDT) Received: from [192.168.91.191] ([195.149.223.176]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MWkep-1cUruH1a83-00XslX; Thu, 20 Apr 2017 08:22:54 +0200 To: Mark Dunn , Eric Rescorla References: <16998c3d-4de6-7c88-d8a3-6d6193326500@objectiveintegration.uk> Cc: "tls@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <3ad253be-6298-6adc-ed08-4ce113763840@gmx.net> Date: Thu, 20 Apr 2017 08:22:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="woMLdwKFoBfJw0d5jigPhbV92INTtWtMk" X-Provags-ID: V03:K0:4jDS/EM62WgGfNORizQfaZMQ/mTtipo1mUdohSmcGgJw2I354QH raZTFKOqK6LIwpI6YWL+AnxUt3Rp0P4TZTthFKXee2tIuz3/BHcMqmBF/gtXgVPdDEaC/2n sbi9M3WfRUQXMeiNCFStnQGsdPjawFHxr0P9migrND9k4BR5NZBKFWcfdxdYwT4m5/SiBSm LaqCvzjDT5RGanI1tBGmw== X-UI-Out-Filterresults: notjunk:1;V01:K0:+v3ns9ILy0Q=:4jBUSDNsuLvQihhMxOwL1L kNlj2w5lE/hr4GTT8JqYGOXOorXmTihK5K56LyMWA5NrWwhXIrUzDbQhr8RfuawWLZKm2xAK6 hJ60kx5SHRsKet7574izRMDt+xNjnh1Yu8gCMVl519GSdS8+vyEY1Px31OjwVPEbOrkUtP6RG BVuRC0H5Fnt538OspklwQK3XVm+iG2KIl8ViLNGAePXg+UjazX/zyxknI0KnNkgXhGkUQNjt5 Fl+W0JcU4boLmsAuxXUdOafArxrd1KzHSHQ1UYDxZKomkcdyJowqM2DHyBqTBTkdltV2en/gU obYZcgpospumGUy+OrnkjOqSZCrwLOqExaqehiieu12+8kUmbQ9KEkuOuZZRpQbS9/+ZSL5pM EYfeteG0UMjjxojHtDN0noK4k0ojbdojOnGJFffdn7eQqO938iQ32oFrJF6W2YoaQdUb6v2TH WHoiN6jV175W83Qd21743fPbGpfNLXD0es9HXZZ7k9FvzD82ZitQ4wPhq2AMR4SC4IrD5Bjkz cJdEhlrPVyIzNy45VKKCKwoFd6FkRZ4jq7t/pFYC7GfNeh+FVdIB+Ty7csScplV4aPkKt9ObV gStYbA09jQHiL/JWCwnZi0NFX9ScjA63cDufs7gGcXjS2XX176gSmOcVDxXOLdvQdkrAO1pvm 59LqV6YJ8OfT8VGcZsbSxgD26XbgSi9gSWYRt1Wdcl2m2k1GwRTql3vyw7Cx88S5ashfV+u8e /i3PqSs2AxLWKgtnCRETtdnskZPyUiSdW8j/zsjaIosLrKj9zGNP/bVjPEU= Archived-At: Subject: Re: [TLS] [xLS 1.3: cookie] - DTLS queries X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 20 Apr 2017 06:23:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --woMLdwKFoBfJw0d5jigPhbV92INTtWtMk Content-Type: multipart/mixed; boundary="WD2qArf5t8SpKldJEbowW8A2jfnJdqlku"; protected-headers="v1" From: Hannes Tschofenig To: Mark Dunn , Eric Rescorla Cc: "tls@ietf.org" Message-ID: <3ad253be-6298-6adc-ed08-4ce113763840@gmx.net> Subject: Re: [TLS] [xLS 1.3: cookie] - DTLS queries References: <16998c3d-4de6-7c88-d8a3-6d6193326500@objectiveintegration.uk> In-Reply-To: --WD2qArf5t8SpKldJEbowW8A2jfnJdqlku Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mark, thanks for your review. A few remarks below. On 04/19/2017 07:07 PM, Mark Dunn wrote: >=20 >=20 > On 29/03/17 15:29, Eric Rescorla wrote: >> Hi Mark, >> >> Thanks for your note. Some comments below... >> >> >> On Wed, Mar 29, 2017 at 8:10 AM, Mark Dunn >> > > wrote: >> >> I am trying to implement cookie and finding it a little >> underspecified. >> >> I am using the TLS 1.3 specified in github and >> draft-rescorla-tls-dtls13-01 >> >> >> 1a) Should a client expect to respond to a cookie during >> session resumption? >> >> >> Yes, it has to be ready to. As you say, it kills 0-RTT, but that's how= >> HRR always behaves. >> > I understand an HRR cookie should cause an extra round trip, but in thi= s > case because of > "DTLS servers SHOULD perform a cookie exchange whenever a new > handshake is being performed" > And > "Early data is not permitted after HelloRetryRequest." > This results in 2-RTT as the default case, is this what you intended? This is a very good observation. I added an issue to the tracker about this question: https://github.com/tlswg/tls13-spec/issues/972 It would be good to have a justification for this restriction and it would be worthwhile to re-consider it in the DTLS specification since the use of HRRs will be common with connection-less transport protocols. >=20 >> >> 1b) If (1a) is false then do you agree that the "cookie" >> extension MUST be accompanied by the "key_share" extension? >> >> >> If I understand you correctly, then I think this is wrong. You only >> send key_share to correct >> the client's key_share, so if the client sent a key_share but you send= >> cookie to force >> a round-trip, then you don't send key_share, just cookie. >> > OK, does this mean a change to DTLS 1.3 figure 4? > from >=20 > Client Server >=20 > ClientHello +----------= + > + key_share* | Flight 1 = | > + pre_shared_key* --------> +----------= + >=20 > +----------= + > <-------- HelloRetryRequest | Flight 2 = | > + cookie +----------= + >=20 >=20 > to >=20 > Client Server >=20 > ClientHello +----------= + > + key_share* | Flight 1 = | > + pre_shared_key* --------> +----------= + >=20 > +----------= + > <-------- HelloRetryRequest | Flight 2 = | > + cookie +----------= + >=20 > * + key_share* * >> >> Since question 1a was answered with yes I believe this question is obsolete. Right? >> >> >> 2) I understand this is too late for TLS(only DTLS SHOULD use >> cookies) but is there a better solution than a cookie? >> Cookies are well-established concepts for keeping servers stateless. >> >> This seems like it would be a big restructure of the handshake, and >> given the >> relatively modest use of client auth in many contexts, I don't think >> it would probably >> be worth it. >> >> Best, >> -Ekr >> > Many infrastructure devices: smart router, smart switch, virtual switch= > and most of the IoT require a > publish / subscribe / notify pattern or an exception pattern. Do these > not qualify? The application layer interaction has to be implemented on top of TLS/DTL= S. >=20 >=20 > The following use case is a publish / subscribe / notify excerpt from m= y > notes, from which I have further questions. > This use case shows that while DTLS 1.3 is provably secure, it has been= > optimised to be very asymmetric in the way it delivers this security. *= > *(Sorry it is not the exact format you have used in the spec.) > I have used "Accelerometer" and "Brake" in place of "Alice" and "Bob" := ) >=20 > Unlike people, *things* generally do not browse the web. It is likely > that they will be commissioned, configured and left mostly to perform > their primary function. >=20 > Example: The *controller* configures communication between two *things*= ; > an *accelerometer* and a *brake* to control wheel spin. >=20 > The *controller* initiates a three way handshake with the *acceleromete= r* >=20 It depends on what environment you are in and where the controller actually is. However, it is quite likely that the IoT device starts the exchange with the controller since the controller does not know what the IP address is, when it is reachable, and whether it is even awake. > ClientHello ----- > >=20 > +key_share=E2=80=A6 >=20 > < ----- ServerHello >=20 > +key_share=E2=80=A6, >=20 > { >=20 > reference to the *accelerometer=E2=80=99s* certificate >=20 > CertificateVerify, >=20 > Finished >=20 > } >=20 > ClientResponse ----- > >=20 > { >=20 > reference to the*controller's *certificate, >=20 > CertificateVerify, >=20 > Finished >=20 > } , >=20 > [data:command] >=20 > < ----- [data:ack] >=20 > This establishes an ephemeral Diffie Hellman *shared key* which is used= > to encrypt the communication. The controller already knows the > accelerometer and has cached its certificate, so does not require the > *certificate chain* , but does require the CertificateVerify *signature= * > to authenticate the *accelerometer*. The *controller* then commands the= > *accelerometer* to *authorise* access for the *brake* to monitor it. > Similarly, the*controller *communicates with the *brake* to command it > to monitor the *accelerometer*. This process may provide both *things* > with each other=E2=80=99s *certificates*. To reduce the amount of data being exchange other specifications have been defined, such as the TLS cached info and the client certificate URI. I believe they would provide what you are asking for (in terms of reference to the controllers certificate). Additionally, note that there will be an application layer protocol on top of the DTLS/TLS exchange to deal with application layer specific authorization requests and their command. >=20 > The *brake *initiates a three way handshake with the *accelerometer *to= > request a subscription to a value* > * >=20 > ClientHello ----- > >=20 > +key_share=E2=80=A6 >=20 > < ----- ServerHello >=20 > +key_share=E2=80=A6, >=20 > { >=20 > reference to the *accelerometer's *certificate, >=20 > CertificateVerify, >=20 > Finished >=20 > } >=20 > ClientResponse ----- > >=20 > { >=20 > reference to the *brake's* certificate, >=20 > CertificateVerify, >=20 > Finished >=20 > }, >=20 > [data:request:subscribe] >=20 > < ----- [ >=20 > Ack, >=20 > NewSessionTicket, >=20 > data:response:ack >=20 > ] >=20 > The *brake* makes a request, encrypted with the *shared key,* to monito= r > the *accelerometer* for sudden acceleration. >=20 > They agree a *pre-shared key* to use on the next session. A session in > this case is ended when either thing loses its ephemeral memory. >=20 > When the *accelerometer* needs to inform the *brake* of high > acceleration (wheel spin) >=20 > The accelerometer uses the *shared key* to encrypt the Notification >=20 I believe you are tying to illustrate the use of a PSK here. This is also supported in TLS in two ways: * First, there is a session key established at the end of the handshake.= * Second, even if you started with a public key based authentication you can later use PSKs with the use of the tickets. Does this address your use case? > < ----- [data:notify:value] >=20 >=20 > * > *** >=20 > *Subsequent Communications **(0-RTT or Zero Round Trip Time)* >=20 > If either of the *things* loses their ephemeral memory, then they need > to use the *pre-shared key *they agreed on earlier. This time the clien= t > is the *accelerometer.* It depends on where you store your PSKs you might loose them as well and only your long-term key is still available. >=20 > ClientHello ----- > >=20 > +pre_shared_key, >=20 > +key_share, >=20 > +early_data=E2=80=A6 >=20 > (data:notify:value) >=20 > < ----- ServerHello >=20 > +pre_shared_key, >=20 > +key_share=E2=80=A6, >=20 > {finished=E2=80=A6} >=20 > [data:ack] >=20 > ClientResponse ----- > >=20 > (endOfEarlyData) >=20 > {finished} >=20 > < ----- [Ack, NewSessionTicket] >=20 >=20 > *Renegotiation* >=20 > If the car is switched off then the next time it is switched on then > full authentication is required once again (without the need for a > certificate chain) I have not seen the need for post-handshake authentication in IoT scenarios. Could you elaborate? >=20 > *Further Questions >=20 > *3) Is it true that the certificate or certificate chain are not > required to be passed in the handshake, it is the client's ability to > check the CertificateVerify signature against the certificate. This > certificate may have been obtained by other means. If this is the case,= > could we have an explicit method to ask for either the certificate or > the certificate chain rather than providing an expensive certificate > chain by default. (I looked at raw certificates, but they do not seem t= o > provide a path to root of trust) Yes, there is the TLS Cached Info and the client certificate URL extensio= n. >=20 > 4) Does the DDOS threat disappear if only certificate references or > certificates are provided, removing the amplification threat and thus > the need for a cookie? The problem with DDoS is two-fold: - First, there is the amplification attack problem. - Second, there is the resource exhaustion problem. With certificate-based authentication you at least have the second problem. The first problem is reduced if you do not send long messages but a single (small) ClientHello will still lead to 5-6 messages being sent by the server. >=20 > 5) I understand for pre_shared_key that we require a If we provide a > CertificateVerify, why do we need a Finished as well? The CertificateVerify demonstrates that the sender has a private key corresponding to the certificate sent. The Finished message demonstrates that it was able to derive the keys (key confirmation). >=20 > 6) In "Subsequent Communications" It was the old server, but now the ne= w > client that uses the pre_shared_key, what are your thoughts? Not sure I fully understand that scenario. >=20 > 7) In TLS 1.3, i think it is implicit that a session corresponds to a > TCP connection or similar, what are your recommendations for what > constitutes a session in DTLS 1.3? In DTLS 1.3 the session concept is indeed a bit loose and defined as "An association between a client and a server resulting from a handshake.= " Ciao Hannes >=20 >=20 > I am still slogging through how to create a cookie, which is an > exceptional version of Transcript-hash (TLS section 4.4.1), which I > still haven't figured out.... >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --WD2qArf5t8SpKldJEbowW8A2jfnJdqlku-- --woMLdwKFoBfJw0d5jigPhbV92INTtWtMk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY+FO8AAoJEGhJURNOOiAtYn8H/R1RQtwd5lyU+HavszmqPVoE 46Hq4/vl+dt88OSJ30W8pDNlc7wNCOotAId1QFTCLwGYvnn4hB5iToGXbe6LKvqk 1SYFuUkQsXqTZ27MT8v04MtUoyKqn/339h5S3lgUsFiMvSIQ0LFzYgG7T1Fg9BwK bioNRQKhgKHZWJ8qgDXjOpM5U79L3U1F8INLWDfWbxdlAzZDdA+Va1S0gqr018iz VB0fmiFanvmczbskrhBV9UP2KI6U8ST5Lv5Ygt8QoqIHcD4nJB5Fi7sUDIB8NyXM /OmX9sU/excsdqWjwv5QJ7sIPaaRm/1UFE/wRf1uoBjlW+ekl7mwU2rhYShQU+A= =eN+K -----END PGP SIGNATURE----- --woMLdwKFoBfJw0d5jigPhbV92INTtWtMk-- From nobody Wed Apr 19 23:49:02 2017 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 1D2C912EB1D for ; Wed, 19 Apr 2017 23:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 S56W6kBNs55P for ; Wed, 19 Apr 2017 23:48:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 C29CE1200C1 for ; Wed, 19 Apr 2017 23:48:58 -0700 (PDT) Received: from [192.168.91.191] ([195.149.223.176]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MFctN-1cpI3y1TBV-00Ectg; Thu, 20 Apr 2017 08:48:51 +0200 To: "Kaduk, Ben" , "tls@ietf.org" References: <886102B6-C2CE-4257-BEB9-11F72000DE50@akamai.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Thu, 20 Apr 2017 08:48:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <886102B6-C2CE-4257-BEB9-11F72000DE50@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="taGLq38V2L9HqcmXST4aG3Wdc28lsB8BK" X-Provags-ID: V03:K0:bvMuaw+2wB72RjcXkGJx9GoNOIP71ygPngSo8yPEf5o/XjrnWGA yVjNcyvWxeMdtIUXOFtSCkGygwjxl93ZTiWWeisT0tZ90MHXMfX5wEoMbQKXi88k40JePSk q9E1cHugbMgeOMCidRFwojEKub7Oed+hT+SSGOFLZAQ03X170zN3+a/ftUJYyU6eSTXbZvL HlWzdeXaYosCBlCILlcXA== X-UI-Out-Filterresults: notjunk:1;V01:K0:uEiil+Pkuzc=:NcwAtU+cjp7nhLDjRCGm+/ EhJMLTNzvpOMfZLFgrvqEA81PPsCddhRCjBcPXK/hERb1gMAqhBkfVy770hKHgr7Tv9Vsz+3A MUnCJX8hnSLzUNZGJEKV0avhTrdvGPSRQNz0XYsIbDcNqR14Jz4UtOG12OqT67gCIuxBi7c68 nTpSqRR18i+LWldYOuvbmTAqqOk448bqOe43ovTjgz/pakE3QnjdjoAoilIfzQT5KgIHGjKd1 vCqwIwt813Rsyb/NuGTWgzNFlO/FF+jB2NpNFf+0F0PpFJfaVqcggt+EpJAa0G8xajFZFJzc/ xHo3DEdKy4+TY3pii8N9UeZDqlAnQkjPD8WeyOT3qJYl1thdTeOmglW4auy/2jIBCOnm/sPSn Ec+MUmTFe5OOoFJIBhRVKBZRpVaZuUgSsfUj46/hHAPdUjCVZsi6DVmjaNALhBGFaRLAHVuH0 sb4IsukOfv1NXtd+f3tupOU9+9QXWaHnNI+UwLtZol8kpefBmMrO+QdEJtavzSbDXqQcY1jQO OIvFiIwPMpNQh5XZTojJwsNPBR8LypgmY2VWWEW5aZnNg1EjNwl2AOZ1idGHNGaTzIt8/b2e8 Zzr0/Bew8YmX8OQ7AuAUovYTq7huDzBV252jhXF0GtF6jmHPVVG4vLl7cJE9Tb7hASEVYsoZZ AUXR8zEN5mLMuHdQLkEUHTwsTzgxgbPwDcn6VWKI2Fsl061btwF8VepTKPtw63vdlHk69xBXu 2OIxoxZaWhqE29Km+1HEkaWVgMjr/W913aG7kOO3OnFJp0TkLtQTsKvmHhs= Archived-At: Subject: Re: [TLS] review comments on draft-rescorla-tls-dtls13-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 20 Apr 2017 06:49:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --taGLq38V2L9HqcmXST4aG3Wdc28lsB8BK Content-Type: multipart/mixed; boundary="20IGUImMXLTKmfUhB2VDq22hatqowDrCq"; protected-headers="v1" From: Hannes Tschofenig To: "Kaduk, Ben" , "tls@ietf.org" Message-ID: Subject: Re: [TLS] review comments on draft-rescorla-tls-dtls13-01 References: <886102B6-C2CE-4257-BEB9-11F72000DE50@akamai.com> In-Reply-To: <886102B6-C2CE-4257-BEB9-11F72000DE50@akamai.com> --20IGUImMXLTKmfUhB2VDq22hatqowDrCq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ben, thanks for the review. On 03/29/2017 04:25 AM, Kaduk, Ben wrote: > A few things I noticed while reading the draft to prepare for today=E2=80= =99s > session: >=20 > We talk in a couple places about datagram protocols being > =E2=80=9Cvulnerable=E2=80=9D or =E2=80=9Csusceptible=E2=80=9D to DoS at= tacks, which leads me to at > least partially read that as meaning that the protocol=E2=80=99s own se= rvice > will be disrupted; as we know, this is not the whole story, as the > reflection/amplification part can facilitate DoS attacks targeted at > other services/networks. So perhaps some rewording is in order. I created an issue https://github.com/ekr/dtls13-spec/issues/18 to take this into account. Note, however, that the DDoS attacks from last year had nothing to do with this protocol design issue. If you control a large number of endpoints then you can flood networks and servers with messages. >=20 > We should catch up to the ClientHello1 being included in the > transcript hash as the synthetic message_hash message, so the full > transcript of it need not be stored in the HelloRetryRequest. >=20 Yes, the most recent version of the TLS spec talks about this issue and we need to take it into account. > On page 20, second paragraph, please be clear that it is the > message_seq vs. the record sequence_number that must match > next_receive_seq. Yes, one has to read carefully in order not to miss this fine distinction. We will try to improve the text. >=20 > I also made a note of the different key update behavior of this draft > vs. draft-ietf-tls-tls13-19, with the epoch change and lockstep > rekeying between peers. That was in the presentation as well, but I > haven=E2=80=99t had my thoughts settle into which flavor I prefer, yet,= > though the explicit KeyUpdate does have some advantages. In practice, I believe the KeyUpdate message will not be used too often. We nevertheless have to figure out whether the loss of functionality (which I believe is minimal) is worth using a separate message. By moving to the implicit rekeying feature (in comparison to the explicit KeyUpdate message) we loose the ability to give the other party the option to decide whether they also want to update their keys. I personally don't see this as a big issue. Ciao Hannes >=20 > -Ben >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --20IGUImMXLTKmfUhB2VDq22hatqowDrCq-- --taGLq38V2L9HqcmXST4aG3Wdc28lsB8BK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY+FnQAAoJEGhJURNOOiAtwo8H/1oWtrYCU5BdgEsliPHQ5DtS Zsepj7gqvcyRnVcvYc+mP6zCUXDN0yY8pIkn6akaEtEsY6jI+B0B1EjwQN7H4XmT PVWuCb6/YaJtD+iyY7RCFXNY5lvJhlJNIKaOfmDWUNbMYAT8LPdlTuHnFoUfchpL GNai+3ovr3sJzjo6hPdP+ZuY1a1aR8kh+XvT45FocbLMK09oGL7tsJeDGPLxr5BU AwWJkOD/2TeozQoskBehT6njuaMbYbOzqsYp6/yw4wMgYGW7jL+eAZuHZkIk0xyB oqhadiUBT+tI+OLVKuLGQCsFILVOOzbXgM+Ds6v7CppwScr+1zBWkpYltrolPp0= =yiqX -----END PGP SIGNATURE----- --taGLq38V2L9HqcmXST4aG3Wdc28lsB8BK-- From nobody Thu Apr 20 07:34:59 2017 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 751BF13147D for ; Thu, 20 Apr 2017 07:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 U0e5uySTrlDg for ; Thu, 20 Apr 2017 07:34:54 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 654F5131484 for ; Thu, 20 Apr 2017 07:34:51 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9D163496C0C; Thu, 20 Apr 2017 14:34:50 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 7CF22496C03; Thu, 20 Apr 2017 14:34:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1492698890; bh=dLYXOle8Z0QGZg25q+megTFPZXWNCaPmSPuXIoZ4RBw=; l=3233; h=To:References:Cc:From:Date:In-Reply-To:From; b=0GsA4M+XkJbqEya1YdHdUOeMsA27/UUw53MlG3Sm+AsZOXYx1yfc00twpnEDdBWl4 Mnf7UsmhgikUqObyvB3jis29/jB/JC3+rp7v2sIB6agWkCxjn/KOE/wt0jQlHGAY2Q fSrMR8KXLWHYpeqkZU5uSV9aizwzkkuwMvS62tWM= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 1600D1E0C4; Thu, 20 Apr 2017 14:34:49 +0000 (GMT) To: Hannes Tschofenig , Mark Dunn References: <16998c3d-4de6-7c88-d8a3-6d6193326500@objectiveintegration.uk> <3ad253be-6298-6adc-ed08-4ce113763840@gmx.net> Cc: "tls@ietf.org" From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <652e33d7-cb5a-2ce1-f7cc-34c57128d660@akamai.com> Date: Thu, 20 Apr 2017 09:34:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3ad253be-6298-6adc-ed08-4ce113763840@gmx.net> Content-Type: multipart/alternative; boundary="------------12360A95C6006E4DFA5C9BB2" Archived-At: Subject: Re: [TLS] [xLS 1.3: cookie] - DTLS queries X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 20 Apr 2017 14:34:57 -0000 This is a multi-part message in MIME format. --------------12360A95C6006E4DFA5C9BB2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/20/2017 01:22 AM, Hannes Tschofenig wrote: > > On 04/19/2017 07:07 PM, Mark Dunn wrote: >> >> I understand an HRR cookie should cause an extra round trip, but in this >> case because of >> "DTLS servers SHOULD perform a cookie exchange whenever a new >> handshake is being performed" >> And >> "Early data is not permitted after HelloRetryRequest." >> This results in 2-RTT as the default case, is this what you intended? > This is a very good observation. I added an issue to the tracker about > this question: > https://github.com/tlswg/tls13-spec/issues/972 > > It would be good to have a justification for this restriction and it > would be worthwhile to re-consider it in the DTLS specification since > the use of HRRs will be common with connection-less transport protocols. Note that we currently document sending HRR as a way for a server to reject early data without having to do trial decryption to determine the end of early data (since the outer content-type is meaningful for the ClientHello2). I expect there will be some situations where servers do not want to implement trial decryption, so removing this functionality without replacement seems ill-advised. -Ben --------------12360A95C6006E4DFA5C9BB2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/20/2017 01:22 AM, Hannes Tschofenig wrote:

On 04/19/2017 07:07 PM, Mark Dunn wrote:


I understand an HRR cookie should cause an extra round trip, but in this
case because of
        "DTLS servers SHOULD perform a cookie exchange whenever a new
handshake is being performed"
And
        "Early data is not permitted after HelloRetryRequest."
This results in 2-RTT as the default case, is this what you intended?

This is a very good observation. I added an issue to the tracker about
this question:
https://github.com/tlswg/tls13-spec/issues/972

It would be good to have a justification for this restriction and it
would be worthwhile to re-consider it in the DTLS specification since
the use of HRRs will be common with connection-less transport protocols.

Note that we currently document sending HRR as a way for a server to reject early data without having to do trial decryption to determine the end of early data (since the outer content-type is meaningful for the ClientHello2).  I expect there will be some situations where servers do not want to implement trial decryption, so removing this functionality without replacement seems ill-advised.

-Ben
--------------12360A95C6006E4DFA5C9BB2-- From nobody Thu Apr 20 10:08:27 2017 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 37AA6129B3C for ; Thu, 20 Apr 2017 10:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.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 UH4bcT8yKhAZ for ; Thu, 20 Apr 2017 10:08:24 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 80610129B17 for ; Thu, 20 Apr 2017 10:08:23 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id o21so39859878wrb.2 for ; Thu, 20 Apr 2017 10:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jdOPp0895a6tL+5quFj+Pj2srYJVvyBfDdgm+4DX1Fk=; b=I42/s1coHfHiM+Ic0tfOSS3V6VnYIbTSa6k8D2InI+q20nHYfFqCbQ+XaBkt6yg9Fx TjqDAv4Mof7hqC5ENnqntwsFKjk3fB2LI/Z665qDjda2XwWbDH+L0FIBqIVxDY6sJuIr 9ouqbNCgtz17D6q27ZOHyRFKl5w4CIQhJwN1A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jdOPp0895a6tL+5quFj+Pj2srYJVvyBfDdgm+4DX1Fk=; b=sQ+GCYl/ck34gMK18P348dp91IrKN+vPeSzk6Ag5tdq1ysSMZsspJjbOjq2IHcBUhN sWQWVfxyYiWGfcdTyLaQ/kU0Iy44r0uyM7xmm/4oAfebRv6Uid2V1zUYSj8PM6wZ5ww2 6Q1GtUKkbwOcq9bTYwrV/X4UpnxGyVxmJr21BKpQA3qMMwfNgKMYv6lAgC83gcU8VeUU JakTDDFs4oGKdc47S201BhjpHwP1U9tMp8HzhSKbxHjOf0uJ3lpcWmQ+18fs8I8Fa98U FfbTRINeDEV8wU8zm0O9+ZWPxst1uEJ8dgRmVG9oiHFcQdG3Ojtn0R0QsTkx/z4hCk+n zF6Q== X-Gm-Message-State: AN3rC/5eSt+Ju2HEtw9smCTMcbpjyqUGCc82mEaZfFRk+hCPUfBnFV7p l0raKG1VPo4yirvXxc45jSJUtD19d+JgBs8= X-Received: by 10.223.164.6 with SMTP id d6mr8187378wra.144.1492708101836; Thu, 20 Apr 2017 10:08:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.130 with HTTP; Thu, 20 Apr 2017 10:08:00 -0700 (PDT) In-Reply-To: References: From: William Whyte Date: Thu, 20 Apr 2017 13:08:00 -0400 Message-ID: To: "Scott Fluhrer (sfluhrer)" Cc: Douglas Stebila , "" Content-Type: multipart/alternative; boundary=f403045f138829fc25054d9c30af Archived-At: Subject: Re: [TLS] AdditionalKeyShare Internet-Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 20 Apr 2017 17:08:26 -0000 --f403045f138829fc25054d9c30af Content-Type: text/plain; charset=UTF-8 Link to that draft: https://tools.ietf.org/html/draft-whyte-qsh-tls13-02 Cheers, William On Wed, Apr 19, 2017 at 2:42 PM, Scott Fluhrer (sfluhrer) < sfluhrer@cisco.com> wrote: > > > -----Original Message----- > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Douglas Stebila > > Sent: Monday, April 17, 2017 2:24 PM > > To: > > Subject: [TLS] AdditionalKeyShare Internet-Draft > > > > Dear TLS mailing list, > > > > We have posted an Internet-Draft > > https://tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00 > > for using an additional key share in TLS 1.3. The intended use case is > to > > provide support for transitional key exchange mechanisms in which both a > > pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are used. > > (Google's experiment with New Hope in 2016 had such an arrangement.) Our > > draft replicates the functionality of the KeyShare extension in a new > > extension called AdditionalKeyShare. Like KeyShare, the client's > > AdditionalKeyShare contains a vector of KeyShareEntry structs. The server > > can respond with a single matching KeyShareEntry in the > AdditionalKeyShare > > extension of its ServerHello. The resulting additional shared secret is > included > > in the TLS key schedule after the ECDH shared secret. > > > > While the motivation for our Internet-Draft is to facilitate the > transition to > > post-quantum algorithms, our Internet-Draft does not specify any post- > > quantum algorithms. > > We have a draft with similar goals; draft-whyte-qsh-tls13 . It also tries > to achieve Quantum-safeness through multiple key exchange mechanisms; > however in terms of protocol, it works somewhat differently. You have the > 'normal' key exchange (as exists in the protocol), and a second one on the > side. We allows the client to define a hybrid group (which consists of > several key exchanges done in parallel). One of our goals was to stay > within the existing TLS architecture as much as possible (and thus limiting > the changes needed to the TLS state machine and parsing logic); things such > as modifying the key derivation mechanism (such as you do) were considered > to be too large. > > It may be worth your while to go through our draft,,, > > > > > There are a couple of items for discussion related to this draft: > > > > - We only provide a mechanism for a single AdditionalKeyShare, thus > leading > > to > > the session establishing at most PSK + ECDHE + 1 additional shared > secret. Is > > there a value in even more shared secrets than that? Will someone want > > to include more than one post-quantum algorithm? If so, our draft > could be > > adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but we > > did not > > want to add that complexity unless there was desire for it. > > Our draft allows for that naturally. > > As for the need, well, I expect that some will want it. We don't have any > postquantum key exchanges that are both practical and really well trusted > (at least, to the same extent that (EC)DH is); I would expect that some > people will want to spread their risk and do (for example) x25519 + Frodo + > SIDH. > > > > > - TLS 1.3 allows the client to restrict the use of PSKs that they > provide in > > ClientHello through the "psk_key_exchange_modes" extension. The client > > may, > > for instance, request that the PSK only be used in a PSK+(EC)DHE mode, > so > > as > > to ensure that the resumed session has forward secrecy. It is unclear > the > > best way to reconcile this with support for multiple key shares; we > outline > > some possibilities in Section 4 of our Internet-Draft, and we welcome > input. > > > > We have also created a pull request to TLS 1.3 draft 19 which includes a > > clarification on how additional secrets are to be included in the TLS key > > schedule. > > https://github.com/jschanck/tls13-spec > > > > John and Douglas > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f403045f138829fc25054d9c30af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Link to that draft:=C2=A0https://tools.ietf.org/html/draft-whyte-qsh= -tls13-02

Cheers,

William

On Wed,= Apr 19, 2017 at 2:42 PM, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:

> -----Original Message-----
> From: TLS [mailto:tls-bounces@= ietf.org] On Behalf Of Douglas Stebila
> Sent: Monday, April 17, 2017 2:24 PM
> To: <tls@ietf.org>
> Subject: [TLS] AdditionalKeyShare Internet-Draft
>
> Dear TLS mailing list,
>
> We have posted an Internet-Draft
>=C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00<= br> > for using an additional key share in TLS 1.3.=C2=A0 The intended use c= ase is to
> provide support for transitional key exchange mechanisms in which both= a
> pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are us= ed.
> (Google's experiment with New Hope in 2016 had such an arrangement= .) Our
> draft replicates the functionality of the KeyShare extension in a new<= br> > extension called AdditionalKeyShare. Like KeyShare, the client's > AdditionalKeyShare contains a vector of KeyShareEntry structs. The ser= ver
> can respond with a single matching KeyShareEntry in the AdditionalKeyS= hare
> extension of its ServerHello. The resulting additional shared secret i= s included
> in the TLS key schedule after the ECDH shared secret.
>
> While the motivation for our Internet-Draft is to facilitate the trans= ition to
> post-quantum algorithms, our Internet-Draft does not specify any post-=
> quantum algorithms.

We have a draft with similar goals; draft-whyte-qsh-tls13 .=C2=A0 It= also tries to achieve Quantum-safeness through multiple key exchange mecha= nisms; however in terms of protocol, it works somewhat differently.=C2=A0 Y= ou have the 'normal' key exchange (as exists in the protocol), and = a second one on the side.=C2=A0 We allows the client to define a hybrid gro= up (which consists of several key exchanges done in parallel).=C2=A0 One of= our goals was to stay within the existing TLS architecture as much as poss= ible (and thus limiting the changes needed to the TLS state machine and par= sing logic); things such as modifying the key derivation mechanism (such as= you do) were considered to be too large.

It may be worth your while to go through our draft,,,

>
> There are a couple of items for discussion related to this draft:
>
> - We only provide a mechanism for a single AdditionalKeyShare, thus le= ading
> to
>=C2=A0 =C2=A0the session establishing at most PSK + ECDHE + 1 additiona= l shared secret.=C2=A0 Is
>=C2=A0 =C2=A0there a value in even more shared secrets than that? Will = someone want
>=C2=A0 =C2=A0to include more than one post-quantum algorithm?=C2=A0 If = so, our draft could be
>=C2=A0 =C2=A0adapted to have AdditionalKeyShare1, AdditionalKeyShare2, = etc., but we
> did not
>=C2=A0 =C2=A0want to add that complexity unless there was desire for it= .

Our draft allows for that naturally.

As for the need, well, I expect that some will want it.=C2=A0 We don't = have any postquantum key exchanges that are both practical and really well = trusted (at least, to the same extent that (EC)DH is); I would expect that = some people will want to spread their risk and do (for example) x25519 + Fr= odo + SIDH.

>
> - TLS 1.3 allows the client to restrict the use of PSKs that they prov= ide in
>=C2=A0 =C2=A0ClientHello through the "psk_key_exchange_modes"= extension. The client
> may,
>=C2=A0 =C2=A0for instance, request that the PSK only be used in a PSK+(= EC)DHE mode, so
> as
>=C2=A0 =C2=A0to ensure that the resumed session has forward secrecy.=C2= =A0 It is unclear the
>=C2=A0 =C2=A0best way to reconcile this with support for multiple key s= hares; we outline
>=C2=A0 =C2=A0some possibilities in Section 4 of our Internet-Draft, and= we welcome input.
>
> We have also created a pull request to TLS 1.3 draft 19 which includes= a
> clarification on how additional secrets are to be included in the TLS = key
> schedule.
>=C2=A0 =C2=A0 =C2=A0https://github.com/jschanck/tls13= -spec
>
> John and Douglas
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--f403045f138829fc25054d9c30af-- From nobody Thu Apr 20 10:34:02 2017 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 B61BA129464 for ; Thu, 20 Apr 2017 10:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.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 UUKpSzFhLFH2 for ; Thu, 20 Apr 2017 10:33:58 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 BB87D1201FA for ; Thu, 20 Apr 2017 10:33:57 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id w50so16976396wrc.0 for ; Thu, 20 Apr 2017 10:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HQxHXe9qDJTlzNQ2vfZ3lzJbmmrbFJ73g54XQyBlcEA=; b=fePWZGeyyeuSHZBsLtkICNewgcD34vApOEYmEU2HiNA+K4Y6I5xIIhWlkS1YITyhHf Y/4xglrHoT1mBbi8qh7Twn/ikNwAodksjv/6bH51NCDMRsiFSttn1g0byXSfhzK5UU/j ee5MGXcv5p2wIn+5/YQSjTTMyH1/8so450UC0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HQxHXe9qDJTlzNQ2vfZ3lzJbmmrbFJ73g54XQyBlcEA=; b=ncGgPxLn5N9vIKU7Q8084aXNIOpzz0RioAdVrHRilvvTqlU7rZ9dKI+YaGTx29H1rD 1EE4CgYQrOviESUA1pgIkcho0CdePWaLIA0AQW+sIf0C9xIEcCKCzf3mP8ChFTlTw40i wP4sOc1WngVmh8jAeV8ER2wBOXKC6EeHUkNDeOilFMqBOqjwVD0vO1ePO1UdKZrhHJE2 ywqAMKITlR89MGwXqR4Plrt05JQLGQfXRmUrnWuqYUR15KO5wyd4oAhJh4xAsEkqT2FA ETwcK+HbmSUEJumSNnJRFyoHr5FD3cxZ/5hGlygt2EWFqB6XmSy/3IB5oUeKXMRPs17p BbFA== X-Gm-Message-State: AN3rC/4fEL+nUV8fPReZR2Qf91CKjxKjWM5qJLyftGtAQAPQXoHl5oKq bje9F5+xQyrtNkd3UxA/laGPPRQ0Ag== X-Received: by 10.223.164.6 with SMTP id d6mr8281881wra.144.1492709636209; Thu, 20 Apr 2017 10:33:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.72.130 with HTTP; Thu, 20 Apr 2017 10:33:35 -0700 (PDT) In-Reply-To: References: From: William Whyte Date: Thu, 20 Apr 2017 13:33:35 -0400 Message-ID: To: "Scott Fluhrer (sfluhrer)" Cc: Douglas Stebila , "" Content-Type: multipart/alternative; boundary=f403045f13889e8ea7054d9c8ba8 Archived-At: Subject: Re: [TLS] AdditionalKeyShare Internet-Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 20 Apr 2017 17:34:01 -0000 --f403045f13889e8ea7054d9c8ba8 Content-Type: text/plain; charset=UTF-8 Sorry! Link to the most recent version... https://tools.ietf.org/html/ draft-whyte-qsh-tls13-04 William On Thu, Apr 20, 2017 at 1:08 PM, William Whyte wrote: > Link to that draft: https://tools.ietf.org/html/draft-whyte-qsh-tls13-02 > > Cheers, > > William > > On Wed, Apr 19, 2017 at 2:42 PM, Scott Fluhrer (sfluhrer) < > sfluhrer@cisco.com> wrote: > >> >> > -----Original Message----- >> > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Douglas Stebila >> > Sent: Monday, April 17, 2017 2:24 PM >> > To: >> > Subject: [TLS] AdditionalKeyShare Internet-Draft >> > >> > Dear TLS mailing list, >> > >> > We have posted an Internet-Draft >> > https://tools.ietf.org/html/draft-schanck-tls-additional-ke >> yshare-00 >> > for using an additional key share in TLS 1.3. The intended use case is >> to >> > provide support for transitional key exchange mechanisms in which both a >> > pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are >> used. >> > (Google's experiment with New Hope in 2016 had such an arrangement.) Our >> > draft replicates the functionality of the KeyShare extension in a new >> > extension called AdditionalKeyShare. Like KeyShare, the client's >> > AdditionalKeyShare contains a vector of KeyShareEntry structs. The >> server >> > can respond with a single matching KeyShareEntry in the >> AdditionalKeyShare >> > extension of its ServerHello. The resulting additional shared secret is >> included >> > in the TLS key schedule after the ECDH shared secret. >> > >> > While the motivation for our Internet-Draft is to facilitate the >> transition to >> > post-quantum algorithms, our Internet-Draft does not specify any post- >> > quantum algorithms. >> >> We have a draft with similar goals; draft-whyte-qsh-tls13 . It also >> tries to achieve Quantum-safeness through multiple key exchange mechanisms; >> however in terms of protocol, it works somewhat differently. You have the >> 'normal' key exchange (as exists in the protocol), and a second one on the >> side. We allows the client to define a hybrid group (which consists of >> several key exchanges done in parallel). One of our goals was to stay >> within the existing TLS architecture as much as possible (and thus limiting >> the changes needed to the TLS state machine and parsing logic); things such >> as modifying the key derivation mechanism (such as you do) were considered >> to be too large. >> >> It may be worth your while to go through our draft,,, >> >> > >> > There are a couple of items for discussion related to this draft: >> > >> > - We only provide a mechanism for a single AdditionalKeyShare, thus >> leading >> > to >> > the session establishing at most PSK + ECDHE + 1 additional shared >> secret. Is >> > there a value in even more shared secrets than that? Will someone want >> > to include more than one post-quantum algorithm? If so, our draft >> could be >> > adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but we >> > did not >> > want to add that complexity unless there was desire for it. >> >> Our draft allows for that naturally. >> >> As for the need, well, I expect that some will want it. We don't have >> any postquantum key exchanges that are both practical and really well >> trusted (at least, to the same extent that (EC)DH is); I would expect that >> some people will want to spread their risk and do (for example) x25519 + >> Frodo + SIDH. >> >> > >> > - TLS 1.3 allows the client to restrict the use of PSKs that they >> provide in >> > ClientHello through the "psk_key_exchange_modes" extension. The client >> > may, >> > for instance, request that the PSK only be used in a PSK+(EC)DHE >> mode, so >> > as >> > to ensure that the resumed session has forward secrecy. It is >> unclear the >> > best way to reconcile this with support for multiple key shares; we >> outline >> > some possibilities in Section 4 of our Internet-Draft, and we welcome >> input. >> > >> > We have also created a pull request to TLS 1.3 draft 19 which includes a >> > clarification on how additional secrets are to be included in the TLS >> key >> > schedule. >> > https://github.com/jschanck/tls13-spec >> > >> > John and Douglas >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > --f403045f13889e8ea7054d9c8ba8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry! Link to the most recent version...=C2=A0https://tools.ietf.org/html/draft-whyte-qsh-tl= s13-04

William

On Thu, Apr 20, 2017 at 1:08 PM, William Wh= yte <wwhyte@onboardsecurity.com> wrote:
Link to that draft:=C2=A0ht= tps://tools.ietf.org/html/draft-whyte-qsh-tls13-02

<= div>Cheers,

William

On Wed, Apr 19, 2017 at 2:42 PM, Scott Fluhrer (sfluhrer) <sfluhrer@c= isco.com> wrote:
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Douglas Stebila
> Sent: Monday, April 17, 2017 2:24 PM
> To: <tls@ietf.org= >
> Subject: [TLS] AdditionalKeyShare Internet-Draft
>
> Dear TLS mailing list,
>
> We have posted an Internet-Draft
>=C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00<= br> > for using an additional key share in TLS 1.3.=C2=A0 The intended use c= ase is to
> provide support for transitional key exchange mechanisms in which both= a
> pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are us= ed.
> (Google's experiment with New Hope in 2016 had such an arrangement= .) Our
> draft replicates the functionality of the KeyShare extension in a new<= br> > extension called AdditionalKeyShare. Like KeyShare, the client's > AdditionalKeyShare contains a vector of KeyShareEntry structs. The ser= ver
> can respond with a single matching KeyShareEntry in the AdditionalKeyS= hare
> extension of its ServerHello. The resulting additional shared secret i= s included
> in the TLS key schedule after the ECDH shared secret.
>
> While the motivation for our Internet-Draft is to facilitate the trans= ition to
> post-quantum algorithms, our Internet-Draft does not specify any post-=
> quantum algorithms.

We have a draft with similar goals; draft-whyte-qsh-tls13 .=C2=A0 It= also tries to achieve Quantum-safeness through multiple key exchange mecha= nisms; however in terms of protocol, it works somewhat differently.=C2=A0 Y= ou have the 'normal' key exchange (as exists in the protocol), and = a second one on the side.=C2=A0 We allows the client to define a hybrid gro= up (which consists of several key exchanges done in parallel).=C2=A0 One of= our goals was to stay within the existing TLS architecture as much as poss= ible (and thus limiting the changes needed to the TLS state machine and par= sing logic); things such as modifying the key derivation mechanism (such as= you do) were considered to be too large.

It may be worth your while to go through our draft,,,

>
> There are a couple of items for discussion related to this draft:
>
> - We only provide a mechanism for a single AdditionalKeyShare, thus le= ading
> to
>=C2=A0 =C2=A0the session establishing at most PSK + ECDHE + 1 additiona= l shared secret.=C2=A0 Is
>=C2=A0 =C2=A0there a value in even more shared secrets than that? Will = someone want
>=C2=A0 =C2=A0to include more than one post-quantum algorithm?=C2=A0 If = so, our draft could be
>=C2=A0 =C2=A0adapted to have AdditionalKeyShare1, AdditionalKeyShare2, = etc., but we
> did not
>=C2=A0 =C2=A0want to add that complexity unless there was desire for it= .

Our draft allows for that naturally.

As for the need, well, I expect that some will want it.=C2=A0 We don't = have any postquantum key exchanges that are both practical and really well = trusted (at least, to the same extent that (EC)DH is); I would expect that = some people will want to spread their risk and do (for example) x25519 + Fr= odo + SIDH.

>
> - TLS 1.3 allows the client to restrict the use of PSKs that they prov= ide in
>=C2=A0 =C2=A0ClientHello through the "psk_key_exchange_modes"= extension. The client
> may,
>=C2=A0 =C2=A0for instance, request that the PSK only be used in a PSK+(= EC)DHE mode, so
> as
>=C2=A0 =C2=A0to ensure that the resumed session has forward secrecy.=C2= =A0 It is unclear the
>=C2=A0 =C2=A0best way to reconcile this with support for multiple key s= hares; we outline
>=C2=A0 =C2=A0some possibilities in Section 4 of our Internet-Draft, and= we welcome input.
>
> We have also created a pull request to TLS 1.3 draft 19 which includes= a
> clarification on how additional secrets are to be included in the TLS = key
> schedule.
>=C2=A0 =C2=A0 =C2=A0https://github.com/jschanck/tls13= -spec
>
> John and Douglas
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--f403045f13889e8ea7054d9c8ba8-- From nobody Thu Apr 20 14:41:31 2017 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 2E49012E05D for ; Thu, 20 Apr 2017 14:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 wZbo4gMZ3zme for ; Thu, 20 Apr 2017 14:41:26 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id CB9DF129C68 for ; Thu, 20 Apr 2017 14:41:26 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5517C496C0A; Thu, 20 Apr 2017 21:41:26 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 35814496C03; Thu, 20 Apr 2017 21:41:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1492724486; bh=XjAdLgf5/tveCks13gaOk0BxSYPF39bHyx4ohiv32gM=; l=6092; h=To:References:Cc:From:Date:In-Reply-To:From; b=o6+CDwbYeqxKKmQILqsjYjq+Wibm1tJtHB+RnWHH/3UB9/1jaQRyl3IBe0FHvkS7U Ok9SvtPr7WZnTIagjTyHj9XB7FP0S2l1F/Dmaj3UClAX+M6pPMZGCtPwSvbJLrqmJV Tv01P64UirplECz9oUMgDyFr0o840o387IBWtE9o= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id C28521E09A; Thu, 20 Apr 2017 21:41:25 +0000 (GMT) To: Martin Thomson , Sean Turner References: Cc: "" From: Benjamin Kaduk Message-ID: Date: Thu, 20 Apr 2017 16:41:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F01640D89D4CD3E61563657C" Archived-At: Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 20 Apr 2017 21:41:30 -0000 This is a multi-part message in MIME format. --------------F01640D89D4CD3E61563657C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit I also reviewed the changes and have no objections. I will just note that leaving the 'implicit' value in the PublicValueEncoding but then removing the select() block that used it in ClientECDiffieHellmanPublic looks a little weird at first glance, but is probably okay (since implicit was only used for the fixed_ECDH methods that are removed by this document). -Ben On 04/13/2017 03:54 AM, Martin Thomson wrote: > I have reviewed the changes. They look good. I have some reservations > about section 7 (implementation status) given that I expect it to date > badly, but it isn't really doing any actual harm either. > > On 11 Apr. 2017 11:09 pm, "Sean Turner" > wrote: > > All, > > draft-ietf-tls-rfc4492bis has been revised since it left the WG > and we agree with Yoav’s statement at the mic in Chicago that the > WG should review the changes before we ask Kathleen (our newly > appointed AD) to continue progressing the draft. Please review > the differences from the -12 version that went through WGLC and > the latest version [0] and let us know by 20170426 whether there > is anything that would stop progression of the draft. > > Thanks, > > J&S > > [0] > https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-rfc4492bis-12&url2=draft-ietf-tls-rfc4492bis-16 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------F01640D89D4CD3E61563657C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I also reviewed the changes and have no objections.

I will just note that leaving the 'implicit' value in the PublicValueEncoding but then removing the select() block that used it in ClientECDiffieHellmanPublic looks a little weird at first glance, but is probably okay (since implicit was only used for the fixed_ECDH methods that are removed by this document).

-Ben
On 04/13/2017 03:54 AM, Martin Thomson wrote:
I have reviewed the changes. They look good.  I have some reservations about section 7 (implementation status) given that I expect it to date badly, but it isn't really doing any actual harm either.

On 11 Apr. 2017 11:09 pm, "Sean Turner" <sean@sn3rd.com> wrote:
All,

draft-ietf-tls-rfc4492bis has been revised since it left the WG and we agree with Yoav’s statement at the mic in Chicago that the WG should review the changes before we ask Kathleen (our newly appointed AD) to continue progressing the draft.  Please review the differences from the -12 version that went through WGLC and the latest version [0] and let us know by 20170426 whether there is anything that would stop progression of the draft.

Thanks,

J&S

[0] https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-rfc4492bis-12&url2=draft-ietf-tls-rfc4492bis-16
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--------------F01640D89D4CD3E61563657C-- From nobody Fri Apr 21 00:44:53 2017 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 D74681294F4 for ; Fri, 21 Apr 2017 00:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.9 X-Spam-Level: X-Spam-Status: No, score=-4.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 G8jtxGnWFinu for ; Fri, 21 Apr 2017 00:44:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 9E63B12947C for ; Fri, 21 Apr 2017 00:44:49 -0700 (PDT) Received: from [192.168.91.191] ([195.149.223.176]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M1VlJ-1c87hQ0tSb-00tWmT; Fri, 21 Apr 2017 09:44:41 +0200 To: Benjamin Kaduk , Mark Dunn References: <16998c3d-4de6-7c88-d8a3-6d6193326500@objectiveintegration.uk> <3ad253be-6298-6adc-ed08-4ce113763840@gmx.net> <652e33d7-cb5a-2ce1-f7cc-34c57128d660@akamai.com> Cc: "tls@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Fri, 21 Apr 2017 09:44:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <652e33d7-cb5a-2ce1-f7cc-34c57128d660@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="M2aGBEHABU4i9ej7Nujol29iQrd2WCqup" X-Provags-ID: V03:K0:RQlU2sFEeEsoXgfex9IC/Xom3cAT7XWPBnwbO8G/6Xl3E0SBXgW 6jFnMEin6CSWZIKfRrfhHFHkuk596gh5NbK4xpHzPyhgF3xFb2jWYMDP6jBP8w053OGUkYV 0q8Po4nhinbF0M8WgV8u6iLtlXFGJmWPdjx5+rOA6i69ll48u1vCEhn3b9cknEMe2PkC5Os yFmWf5SrRF/jkBRqEAfww== X-UI-Out-Filterresults: notjunk:1;V01:K0:EvmC6QiNgBU=:Q6QugcOk4RV0v2RvZIy/el pm426QqPOzXB+9voiQq+lYutavEXI+e460jn0n6qzVCJSjh3dMwsM8n99zX9BA0Y24qw6+hz2 xIrgZNQphzOeMYuB5E+yFMAJ3sHIMVQ0QuTr87WJgqbAEBIFs0dH6U8nlZwp5v7liJzfdJONw Z7Fn0ef5Cliqft+VNkYZH53obRmYkGc9qeL0qVwfEo9MeQop0iCFvahHhJ8hj7bI2hwcaLlpa zXmxbHSamqMPSxaATeQxunu0cxKu6zW64rVBUz6XDFIYOI8jfQrl9FHltPv8crwyQTOGBa//M euaxgtRN/LrdatQNzUxIYxCBM5CytrTfFK1DQlCk7ktmsf//cuBwRRD5xp0ZPF2FGGVpEZDeR VJVbMkM/iTozStJ4D692iqic1aokpUBvxcCrichW8z8LdMMC34Gh8fDDSuhi8Ldf503OzQ0iw O/9ahsS16P3wMC1SGCr0cLO1MxYJp2a4X4alddSX05tqNzdf28647AFFDsQsDjFvFaAi78LZC VcYuvha8i1lSTpeOtDtXrJJ9cpW85fRRidj+pqypnqH2VmFDpb1A1clb6Qv11a8tF9h2RZlO3 f8hm3orSQRL3205+UtKpsS6J11a+IcKi+jygT1gHr3BpIi27T/2JmvPoRU9s65bws0TwXYogP NbIiqwPpg9Flho20HQwdZ3vqIIrYB9mRnDcP/vk2pjaw/S7Uoy0gwnVP4dMY/nC8gtaS1bpJE VekGW2g6ohYtnpRQnXPI0QZV0SFY9aII7eBkFZX0TXVFn/QWgc31Z0BUEXY= Archived-At: Subject: Re: [TLS] [xLS 1.3: cookie] - DTLS queries X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 07:44:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M2aGBEHABU4i9ej7Nujol29iQrd2WCqup Content-Type: multipart/mixed; boundary="i4lAsBs3E61TwM8UkadbinIxsXbiH6pOj"; protected-headers="v1" From: Hannes Tschofenig To: Benjamin Kaduk , Mark Dunn Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] [xLS 1.3: cookie] - DTLS queries References: <16998c3d-4de6-7c88-d8a3-6d6193326500@objectiveintegration.uk> <3ad253be-6298-6adc-ed08-4ce113763840@gmx.net> <652e33d7-cb5a-2ce1-f7cc-34c57128d660@akamai.com> In-Reply-To: <652e33d7-cb5a-2ce1-f7cc-34c57128d660@akamai.com> --i4lAsBs3E61TwM8UkadbinIxsXbiH6pOj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ben, thanks for your remark. I don't think that this is an issue in DTLS since the epoch field provides additional information to properly select the correct key. Ciao Hannes On 04/20/2017 04:34 PM, Benjamin Kaduk wrote: > On 04/20/2017 01:22 AM, Hannes Tschofenig wrote: >> >> On 04/19/2017 07:07 PM, Mark Dunn wrote: >>> >>> I understand an HRR cookie should cause an extra round trip, but in t= his >>> case because of >>> "DTLS servers SHOULD perform a cookie exchange whenever a new= >>> handshake is being performed" >>> And >>> "Early data is not permitted after HelloRetryRequest." >>> This results in 2-RTT as the default case, is this what you intended?= >> This is a very good observation. I added an issue to the tracker about= >> this question: >> https://github.com/tlswg/tls13-spec/issues/972 >> >> It would be good to have a justification for this restriction and it >> would be worthwhile to re-consider it in the DTLS specification since >> the use of HRRs will be common with connection-less transport protocol= s. >=20 > Note that we currently document sending HRR as a way for a server to > reject early data without having to do trial decryption to determine th= e > end of early data (since the outer content-type is meaningful for the > ClientHello2). I expect there will be some situations where servers do= > not want to implement trial decryption, so removing this functionality > without replacement seems ill-advised. >=20 > -Ben --i4lAsBs3E61TwM8UkadbinIxsXbiH6pOj-- --M2aGBEHABU4i9ej7Nujol29iQrd2WCqup Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY+bhmAAoJEGhJURNOOiAtiSsH/078Vn3No0ZlUAhMWL/cn0sc Bm5vYqT6v0oTCdApJctfhWsEzKbH9t6s6qsulAyPrTy/GxyNnlwr+jidKDr9Cy8H c6ntBklU1eAjOs5boFiv0ifcj5hWUm4Yv28rGwTUa7LfQJIHA9sEM+ZgxRQLXivp w0nY64QHXapflAwQXcR28b4wFgSJFzF6YmXpH0/dSh7mxqZh6Hm9efsLJPT55NzS XiiIMD1nc0V+yhGdIHGdIGAdQyS77EvGaBBu4J6vWzAlGCWO+LHG2P5CEY0u5Zcy alrnJTMGc5e/vxCI+lr6G9oxledL0+WEkcbn4enSEHzASq8sH4YEsgrNW3dbyWg= =DFLV -----END PGP SIGNATURE----- --M2aGBEHABU4i9ej7Nujol29iQrd2WCqup-- From nobody Fri Apr 21 01:37:30 2017 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 C8394129420 for ; Fri, 21 Apr 2017 01:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 G1kVrPs-lmaF for ; Fri, 21 Apr 2017 01:37:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 A4243129AF7 for ; Fri, 21 Apr 2017 01:37:26 -0700 (PDT) Received: from [192.168.91.191] ([195.149.223.176]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LrZOj-1c0LVO1MNB-013RM2 for ; Fri, 21 Apr 2017 10:37:23 +0200 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 To: "" Message-ID: Date: Fri, 21 Apr 2017 10:37:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fixtobeic9LXj5qokmBqQjpd8lMHLwfou" X-Provags-ID: V03:K0:UqqL7aCK9Oh1dt+s3efWhjg95JqVCQX1aifNqXWyh+bsmeXGnz1 GgIaVqYK4DsFVOmbArCkkGU7mRNMskqKCmF18oaSRCuAOmjLeyGGuCLwD7PMfd8Q/4JSrWj XOQpSnbwJogwWgnQfMCcO8Jvr25iUWUuYYtNTlSpSPmPSdu06ZtZbRWHx+XUQ94B9cZ18D1 /mc61AABQHojjIvl9BJ5g== X-UI-Out-Filterresults: notjunk:1;V01:K0:2xa7FF0ARqw=:NvRDFDTfKhYhm44060Eh/n nT6VptDxSwNL6zvbwX6UMlQxwt3sEaj3eFsWAbnxZQOVFdoiMXW1lo2Wt4M34As5aRTGo6s77 XBcXsV1aCx7jE+W52qiS2cGFkzGuEKsbugufyJYh84ZXG/vk6kvSjFr6MxKYXxHTMQ0Uk+bG/ 6n4rKraCqtkAIH0f/o57LA7VIlCs3YUsoa4rPBDdK5MRY3pMSdHzcqHlOyUM2PztGShgNtZ87 JvuY0aoqv6/Cl9Re515DEGz+UulYnWlKWBsr+Nox+74fZmHaomCWRh7kSls0RKCPlFAcjtobo a+86WRNzn4NkB4XPTa8/4rtEwCfv0sCuIinGxoHnMQyzWZs3k1rpHRhVH9cOyKpBn8P0gf4rS Z8dFclsfGpVgXHDznuux45yCYyK/+ZNyFrle2KyEiU8czSlpPFor5Und5NSwLGQeiR4sSen63 4w/vuFcoMWfv+R4hsRIFJzQu0bAvveQB8f3VxR9/9Ycg7rp6MxKbFvnxk2VaYaUmaJ+ZbPeQo 95pr9ojkHgeJP8p4wCXXUrZTvIeCn0hSZ8TMsH7ZSuKIrHdk1d1sfVNav2qJmrekIg9qgINjh XJOj5iE21FKCBIkbyEXPRj4BeZ6A94FWKdYuAwVtwK7XvQAOoEyucs+DLMBz2PDKqRRqXb58V 2LtJ6vfHlBx/oHhfzNx4ZXk71A1vyD1R1CMS0x9qDDOTLbI77n0rXw6jduRdwcAy7xcCoyup1 6tBSGlD6T2V6FM23g2Z7r2o/XCOyFDtC/wWJyU5xabBuPFBeOKiDIlV4TxM= Archived-At: Subject: [TLS] draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 08:37:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fixtobeic9LXj5qokmBqQjpd8lMHLwfou Content-Type: multipart/mixed; boundary="p8ux7Ds3Dm8GvO1p8wL01GkuaFBEUxvG4"; protected-headers="v1" From: Hannes Tschofenig To: "" Message-ID: Subject: draft-rescorla-tls-subcerts-01 --p8ux7Ds3Dm8GvO1p8wL01GkuaFBEUxvG4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I read through draft-rescorla-tls-subcerts-01 and I ran into some basic questions. I have been wondering why the TLS server operator obtains an end-entity certificate from a CA (which cannot be used to sign further certificates) instead of running an intermediate CA him-/herself instead. This would work without requiring any changes to the client side. The proposed solution, although technically feasible, will unfortunately take a long time to deploy since it requires cooperation from clients, servers, and also from CAs. What is also not clear to my why some of the certificate management protocols, which provide the necessary level of automation, cannot be used with CAs to request short-lived certificates. Ciao Hannes --p8ux7Ds3Dm8GvO1p8wL01GkuaFBEUxvG4-- --fixtobeic9LXj5qokmBqQjpd8lMHLwfou Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY+cTCAAoJEGhJURNOOiAtigAH/jr7njuBHhu8QwnPUCWy4lqW fFC+edlQ5bHCFjPR4o0qOG5kG4jCGn3ce/kkRdlGST5AmBP7GFo8XXQ8XVfjcZj1 V5RZry9Xf5rTiu935rQ6w/auPQMgfvB+G5lEQKbtOyfzJCG3bBptb1P0oRs36+gd 6PYVd/IuvUnd2lsJWoEVgdDcIxVIYyUyX++l+66d/iHMerLb7FomjfxAT0giLO/L 46oFI7B0QQnG9Fuxg+pKlko8u+uXKQDM6gLFrhZCMOpnJzGzYpi5NikAfFdXSvpd 4J5XXbkiFHQP38WGag0MHq3R7K2S5slzzGUV+0O8rr70YPTvMqXQSU28xpj6uuU= =Hp7J -----END PGP SIGNATURE----- --fixtobeic9LXj5qokmBqQjpd8lMHLwfou-- From nobody Fri Apr 21 01:44:12 2017 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 8CD19129B04 for ; Fri, 21 Apr 2017 01:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 jdnlZPwne1vV for ; Fri, 21 Apr 2017 01:44:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 BF0181294F4 for ; Fri, 21 Apr 2017 01:44:08 -0700 (PDT) Received: from [192.168.91.191] ([195.149.223.176]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lg5kl-1cD5On2sjD-00pbyN for ; Fri, 21 Apr 2017 10:44:06 +0200 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 To: "" Message-ID: <55e7544b-808a-5e0e-f66e-3a6f4a79e218@gmx.net> Date: Fri, 21 Apr 2017 10:44:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XVMu7eUnrqmNboOfEhghlF9eHPgFTRovJ" X-Provags-ID: V03:K0:A1efaMeJYFHL7+Eac1caiTLEYkOfJEvCvSm6YSroUnotIPXo6Rd JJz70GD9GCU9Sbr73wxLPpeukBCEmyaUr/od87JAANPblDV9U5whrlikpnt23er/15Ug183 VfCm8lW3BVn41C9E9cU566PnYcFOidNLxPVsPTHToW9cJyOSrQX5nXmbcxwsbFNarBkjQyV O14D/N1+QZcnQwnPipBGw== X-UI-Out-Filterresults: notjunk:1;V01:K0:+ZtPi4iE2TI=:MPpZ5caBuw+7njoFTB1+rP xqXtricK5dMac5+7bdFAn5QyjQiVsiGoz0ieK2eLAj+cPRFLoiUHIKiYLCRAX3V/EOH2HVPxO qjIIlaq0HtifS/CI0zozfSB2cRNQuAXyCh7da7i7yEE2cwBCfj6NGVNdtk2e8HYmXi7nfiafr qhXZpWTZAMtqafbVAlMoMfVkbRrTTwU8y69dnvQ+1S8YPurLbgc3+3VBbPEZMJdVwMOw1yl1M NitIIi8ZvvWN0oK8IjU/zTL63GerDM92MUOZuulG2UPpzb/IH3bBVtiKv/nTejyjAkuYv5PsR HoqLXl3DwaY1LVnFwtHoRgVz5K5ffwFsloE0uSvexz4y9POkuyEvnEOxjoJrkgtk6C9oAjJNf 1eW8tK011Fk5h16wQ422ZXOPdO/5oVh+2xytgY+vNfQQzNFCGR9rtIM5sDo09du38FkQ1+WUw qAZsNM+g9XV9oyqO1IKa4uN8jUUqmnnqskNmzCkPta4jWcq823Tw3Mohk0IDUd8WrgVGjQj24 6TEZwe7nLyvfKamFLQh8RCyGsGtEi/QxfnDQ5XGKlKy4VcWxMLtTl0XhYemo5nhVwv2WYyxDx FeASsxbiYsshaoCIG4vp8wHJowmf8fNcS23OtseDxrZW36FvGGPasikqYJkkwYB4OuHXhE98a 0TrA19K6w6mqgQhHSmB/mJjNwzoRrfftGxkNJ44Cc9sNUzzhgmZQocv749G54epW6qON8JLD7 SZkguM2GCdShrTpuqAWJwDbqOZQFw2yrQHZxbGVbopVkVF6Lv8gCx/AT+uU= Archived-At: Subject: [TLS] draft-sullivan-tls-exported-authenticator-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 08:44:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XVMu7eUnrqmNboOfEhghlF9eHPgFTRovJ Content-Type: multipart/mixed; boundary="894MjmRHKuNFnpXmIkQkU0e4hxnBsB2Vt"; protected-headers="v1" From: Hannes Tschofenig To: "" Message-ID: <55e7544b-808a-5e0e-f66e-3a6f4a79e218@gmx.net> Subject: draft-sullivan-tls-exported-authenticator-01 --894MjmRHKuNFnpXmIkQkU0e4hxnBsB2Vt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have read draft-sullivan-tls-exported-authenticator-01 and have a few questions. I haven't followed this work previously but have been wondering whether this functionality would be useful for "me". The described functionality sounds like post-handshake authentication from TLS 1.3 (although it does not use that term throughout the document). I would have thought that this functionality is a replacement to the TLS 1.2 renegotiation but then there is also the TLS 1.3 content in there which raises the question about how this relates to the post-handshake authentication functionality. What does the following sentence mean and what is the use case for it? " This proof of authentication can be exported and transmitted out of band from one party to be validated by the other party. " Who are the parties? Ciao Hannes --894MjmRHKuNFnpXmIkQkU0e4hxnBsB2Vt-- --XVMu7eUnrqmNboOfEhghlF9eHPgFTRovJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY+cZRAAoJEGhJURNOOiAt/oYH/3C86lEnAEQ8g9niIxYxrJZO 1QcHtPMZXpMAu7NqLaRpyPMhFXKPau3YYyayQDuafshbG6e6IM7iDZrK+Umx2wwU tBSpuB9cgfUPBoFmQ1vUBxJTFiiTzSrGWxtPysETTGQI6HNd+w6B2kRvGuIcIAC4 PJ+yRZih2aJxTy/taV4Fd6h9BDhs4CBamvVvycfvgaqTUzg4G0CxbhVMl4jbx9Eo KQnqdU8nFMLe0HOV2hnnjlLEeXX7vcUcqADyd2HRzVe9G6VLfeuKh1K7+UMR56wx wFXyJLBVCTePdKbXN4VzWZbnfT6V5RsFB3K3D8W5OU9B1dw8SWHqBFKqEKQEGyw= =uj4n -----END PGP SIGNATURE----- --XVMu7eUnrqmNboOfEhghlF9eHPgFTRovJ-- From nobody Fri Apr 21 03:49:05 2017 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 8A534126B71 for ; Fri, 21 Apr 2017 03:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 ToqtNZxOg9u1 for ; Fri, 21 Apr 2017 03:49:02 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 62343126D73 for ; Fri, 21 Apr 2017 03:49:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 944382454C; Fri, 21 Apr 2017 13:48:59 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 8WgFhdjCEPTD; Fri, 21 Apr 2017 13:48:59 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5C377C4; Fri, 21 Apr 2017 13:48:59 +0300 (EEST) Date: Fri, 21 Apr 2017 13:48:57 +0300 From: Ilari Liusvaara To: Hannes Tschofenig Cc: "" Message-ID: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 10:49:05 -0000 On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote: > I read through draft-rescorla-tls-subcerts-01 and I ran into some basic > questions. > > I have been wondering why the TLS server operator obtains an end-entity > certificate from a CA (which cannot be used to sign further > certificates) instead of running an intermediate CA him-/herself > instead. This would work without requiring any changes to the client > side. The proposed solution, although technically feasible, will > unfortunately take a long time to deploy since it requires cooperation > from clients, servers, and also from CAs. There is enormous amount of red tape obtaining intermediates, even technically constrained ones. And as consequence, it is enormously expensive (through not nearly as expensive as public CA). Defining new extensions is much more deployable, as slow as it is (AFAICT, no BR changes needed). Regarding clients, I think the draft specifies LURK as backup plan for clients that don't support subcerts (which causes some extra latency if triggered). > What is also not clear to my why some of the certificate management > protocols, which provide the necessary level of automation, cannot be > used with CAs to request short-lived certificates. AFAIK, that would cause issues with CT and OCSP signing. The latter would be fixable by reintroducing CABForum ballot 153 and passing it (the reasons 153 failed were obviously political instead of technical). -Ilari From nobody Fri Apr 21 03:52:20 2017 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 2614E126B71 for ; Fri, 21 Apr 2017 03:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 sEminioAqP12 for ; Fri, 21 Apr 2017 03:52:16 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id A129C1294CD for ; Fri, 21 Apr 2017 03:52:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 9A6FF1EFFF; Fri, 21 Apr 2017 13:52:15 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id AfFdZoqHSe43; Fri, 21 Apr 2017 13:52:15 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5AACCC4; Fri, 21 Apr 2017 13:52:15 +0300 (EEST) Date: Fri, 21 Apr 2017 13:52:14 +0300 From: Ilari Liusvaara To: Hannes Tschofenig Cc: "" Message-ID: <20170421105213.GB20822@LK-Perkele-V2.elisa-laajakaista.fi> References: <55e7544b-808a-5e0e-f66e-3a6f4a79e218@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55e7544b-808a-5e0e-f66e-3a6f4a79e218@gmx.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 10:52:18 -0000 On Fri, Apr 21, 2017 at 10:44:01AM +0200, Hannes Tschofenig wrote: > I have read draft-sullivan-tls-exported-authenticator-01 and have a few > questions. I haven't followed this work previously but have been > wondering whether this functionality would be useful for "me". > > The described functionality sounds like post-handshake authentication > from TLS 1.3 (although it does not use that term throughout the > document). I would have thought that this functionality is a replacement > to the TLS 1.2 renegotiation but then there is also the TLS 1.3 content > in there which raises the question about how this relates to the > post-handshake authentication functionality. There are two things that can't be accomplished with PHA: - Authenticating the server for more identities. - Transmitting application context with the certificate. TLS 1.2 renegotiation also is incapable of either of those. > What does the following sentence mean and what is the use case for it? > > " > This proof of authentication can > be exported and transmitted out of band from one party to be > validated by the other party. > " > Who are the parties? Most probably TLS client and server. -Ilari From nobody Fri Apr 21 04:08:07 2017 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 BA9E31292AE for ; Fri, 21 Apr 2017 04:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 rluQR3BHNKI7 for ; Fri, 21 Apr 2017 04:08:03 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0139.outbound.protection.outlook.com [104.47.1.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF361272E1 for ; Fri, 21 Apr 2017 04:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r/2Q9FbE/PhmzsDyuMBGuOKbzY33CbeSB4zvc3Qnz1I=; b=QSXDZzTNS6GxBdVUYZ5Ixf/pwMW+qzkcURj2eKVhsKHQqhdtqFps9Tnx9zQxtDiifKyAo+hO/0cTgsdTP2gvWjYpGuwrZqBOZeVI/2bp+Kn0QT70nrWDEwlVcODsgOwYpIznbURJCXYcb4JtKVd8w8EADKZ7xUXmJGpGQVrUync= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1103.eurprd07.prod.outlook.com (10.163.168.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Fri, 21 Apr 2017 11:08:00 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) with mapi id 15.01.1047.008; Fri, 21 Apr 2017 11:08:00 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Ilari Liusvaara , Hannes Tschofenig CC: "" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [TLS] draft-rescorla-tls-subcerts-01 Thread-Index: AQHSunqIZYO5VLtqn0+DOPOxbhXZyKHPpMuAgAAWDwA= Date: Fri, 21 Apr 2017 11:08:00 +0000 Message-ID: <5C7D62E9-3F3F-45B6-B1AC-A92B95895A16@on.nokia.com> References: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [81.134.152.4] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1103; 7:XNFM6p92uJ7J8i3QudgfZz/x96RF9acPablHoLwMGHihu1+j4riSXAsFRoo9BusklMW8/GDJTBxwwrpPkqNpPpc8O9CmPdQdHFk1eqLQrRnhnQU2B9eiTocrNgZI+qGcfFudt+SXfoe1QO05esZ7ujp1Emvxh5eAzkr3iOu0Aimba1/Bbtw/p7nUmTskNanEUYeDTiolZDiKAHbUlw5IHQrLJZ5ut5lUcU2xd58FMLH/z/JPZmS/9KGPO95pQuJtRPtBw8klZZEjsFpQpwK3D4HSX5R1C1N1zbOcJg/cMtotOvesium4lCM/drQ0fztwY2Rywj9XfwWonH4an9rEig== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39400400002)(39840400002)(39850400002)(39860400002)(24454002)(6116002)(8936002)(3846002)(122556002)(102836003)(6512007)(33656002)(305945005)(4326008)(77096006)(107886003)(25786009)(6436002)(99286003)(4001350100001)(5660300001)(53546009)(38730400002)(53936002)(6506006)(6246003)(6486002)(189998001)(6306002)(229853002)(2906002)(81166006)(8676002)(2900100001)(66066001)(2950100002)(7736002)(3660700001)(82746002)(3280700002)(50986999)(83506001)(83716003)(86362001)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1103; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 36488a68-4ced-41d5-9f42-08d488a6ac67 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:VI1PR07MB1103; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:VI1PR07MB1103; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1103; x-forefront-prvs: 02843AA9E0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0250CB6DF301D646967436FC2A85EE62@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 11:08:00.1631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1103 Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 11:08:06 -0000 T24gMjEvMDQvMjAxNyAxMTo0OCwgIlRMUyBvbiBiZWhhbGYgb2YgSWxhcmkgTGl1c3ZhYXJhIiA8 dGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNv bT4gd3JvdGU6DQpPbiBGcmksIEFwciAyMSwgMjAxNyBhdCAxMDozNzoyMUFNICswMjAwLCBIYW5u ZXMgVHNjaG9mZW5pZyB3cm90ZToNCj4gPiBXaGF0IGlzIGFsc28gbm90IGNsZWFyIHRvIG15IHdo eSBzb21lIG9mIHRoZSBjZXJ0aWZpY2F0ZSBtYW5hZ2VtZW50DQo+ID4gcHJvdG9jb2xzLCB3aGlj aCBwcm92aWRlIHRoZSBuZWNlc3NhcnkgbGV2ZWwgb2YgYXV0b21hdGlvbiwgY2Fubm90IGJlDQo+ ID4gdXNlZCB3aXRoIENBcyB0byByZXF1ZXN0IHNob3J0LWxpdmVkIGNlcnRpZmljYXRlcy4NCj4g DQo+IEFGQUlLLCB0aGF0IHdvdWxkIGNhdXNlIGlzc3VlcyB3aXRoIENUIGFuZCBPQ1NQIHNpZ25p bmcuDQoNClNwZWFraW5nIGFzIG9uZSBvZiB0aGUgY28tYXV0aG9ycyBvZiBbMV06IGl0IGlzIG5v dCBjb21wbGV0ZWx5IGNsZWFyIHRvIG1lIHdoYXQNCmlzIHRoZSBsaW1pdGF0aW9uIGluIENUIHRo YXQgd291bGQgcHJldmVudCBpdCB0byBjb3BlIHdpdGggdGhlIHBlcnZhc2l2ZSB1c2Ugb2YNCnNo b3J0LXRlcm0gY2VydGlmaWNhdGVzLiAgQ2FuIGFueW9uZSBzaGVkIGEgbGlnaHQgb24gdGhpcz8N Cg0KQ2hlZXJzLCB0aGFua3MsDQp0DQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LXNoZWZmZXItYWNtZS1zdGFyLTAwLnR4dA0KDQo= From nobody Fri Apr 21 08:50:39 2017 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 C5D9F12954B for ; Fri, 21 Apr 2017 08:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 WBaI29CqG2Op for ; Fri, 21 Apr 2017 08:50:35 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C066A1296CD for ; Fri, 21 Apr 2017 08:50:31 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3LFl859015383; Fri, 21 Apr 2017 16:50:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=KnvMdO9/qLVoijAQo/i0tqhfj5B01wVzqCRJl1LpriU=; b=co4AqP0KerZo7ED/mMWIZBOf6GG+BbFdsZMqcZrM+NnSlRUkzFFNaNFBHuElzFBFCbME vNaJBSLpWg+tM8HfAg4/0SSCpL15wK6LEbjUlqvkSxk1y69Du7S4mF01q25Xtl8To1Kk f56HegThNiPJh9r0f282cnL7sividre+089ciozXwiIchaUJQBaXMe3PW8BjVqbdLJ4l 1TicN4SOxMOuHdfrou/8Lg7ZFEn6R0rBFJ8xGYzKfnxJVnfC5p/P31l7WYtj4uHk7CpD RhfwiGXEK5TNpZAFXkGNvpEUb6Wr9UFvVJy/FMCml9/JJOfd3KRl+0e3Y5YUBI6rwYPr Rg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 29y2s8xa9x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Apr 2017 16:50:26 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3LFkEli018954; Fri, 21 Apr 2017 11:50:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 29wqn5m043-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 21 Apr 2017 11:50:24 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 21 Apr 2017 11:50:24 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 21 Apr 2017 11:50:24 -0400 From: "Salz, Rich" To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Ilari Liusvaara , Hannes Tschofenig CC: "" Thread-Topic: [TLS] draft-rescorla-tls-subcerts-01 Thread-Index: AQHSunqGQj5aZlGSNUq3e1Ek/6MTFKHP59mAgAAFUwCAAAuPcA== Date: Fri, 21 Apr 2017 15:50:23 +0000 Message-ID: References: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> <5C7D62E9-3F3F-45B6-B1AC-A92B95895A16@on.nokia.com> In-Reply-To: <5C7D62E9-3F3F-45B6-B1AC-A92B95895A16@on.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.7] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-21_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704210282 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-21_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704210283 Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 15:50:38 -0000 > Speaking as one of the co-authors of [1]: it is not completely clear to m= e what > is the limitation in CT that would prevent it to cope with the pervasive = use of > short-term certificates. Can anyone shed a light on this? I believe the concerns are scaling log servers and perhaps needing to "rota= te" them if, say, 90% of their tree is invalid in a year. From nobody Fri Apr 21 23:49:59 2017 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 25B221287A7 for ; Fri, 21 Apr 2017 23:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 fFo7MXfayj9G for ; Fri, 21 Apr 2017 23:49:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49C5124BFA for ; Fri, 21 Apr 2017 23:49:55 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 89BC7C21865A; Sat, 22 Apr 2017 06:49:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 89BC7C21865A Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 89BC7C21865A Received: from ovpn-204-17.brq.redhat.com (ovpn-204-17.brq.redhat.com [10.40.204.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C564B6031D; Sat, 22 Apr 2017 06:49:53 +0000 (UTC) Message-ID: <1492786351.14070.2.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Cc: "tls@ietf.org" In-Reply-To: References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 21 Apr 2017 16:52:31 +0200 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Sat, 22 Apr 2017 06:49:54 +0000 (UTC) Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 22 Apr 2017 06:49:58 -0000 On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > 4.1.1. HelloRetryRequest how many times can it be re-sent by the > > server? I assume only a single one, but it maybe good to make it > > explicit. > > This is forbidden in S 4.1.4. > https://tlswg.github.io/tls13-spec/#hello-retry-request > >    If a client receives a second HelloRetryRequest in the same >    connection (i.e., where the ClientHello was itself in response to > a >    HelloRetryRequest), it MUST abort the handshake with an >    “unexpected_message†alert. >     > Does this seem sufficient? I must have missed it. Yes, it seems fine. > > 4.4.2.1.  OCSP Status and SCT Extensions > > This is a very nice addition to TLS 1.3. Something that I miss as > an > > implementer is guidelines on how to determine the (time) validity > of an > > OCSP stapled response. Here my point is that OCSP responses have > > several fields optional (e.g., nextUpdate), which make a validation > to > > be hand-wavy. It would be nice to have a profile of OCSP responses > that > > would be recommended for use in TLS, as well or a recommendation of > > what constitutes a "fresh" response for use in TLS. > > Do you have any thoughts on what text we should insert here? I admit > to being not that familiar with the practical matters of OCSP > stapling. My issue with OCSP when used under TLS was how to determine the validity of the response when the nextUpdate field is missing. I've added some text for that introducing an (arbitrary) upper limit at: https://github.com/tlswg/tls13-spec/pull/974 > > 5.1. I miss a maximum number of alerts received per session, or > some > > other alert limiting mechanism (having CVE-2016-8610 in mind). > > All alerts now result in connection termination, so the limit > seems to implicitly be 1. Nice. > > > > 7.5. There is no definition of early_exporter_secret, and it is > unclear > > why it is even mentioned. In short how is this supposed to be used, > and > > why should implementations consider adding an interface to it? > > It is defined in: > https://tlswg.github.io/tls13-spec/#key-schedule > > I added some text to explain why you would want it. Thanks. There is a typo on that description "is define for use" -> "is defined for use".   regards, Nikos From nobody Sat Apr 22 04:54:35 2017 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 A153D129B2C for ; Sat, 22 Apr 2017 04:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 YnSXNgMI6vYb for ; Sat, 22 Apr 2017 04:54:31 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 71A611294CD for ; Sat, 22 Apr 2017 04:54:31 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id 203so59446061ywe.0 for ; Sat, 22 Apr 2017 04:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y9HF6dIlClFA17FAynh24ufmUBFchalOTV0l1ADt024=; b=UxOkowzzrCvH+R1LcZA9STh5eeWR1gCJCST9OPfbukePk+gVT7AeYbBAtvYRg66qNT 0X/ZafcFeveHjFO8o6Oxoo0c1u0CpuzMF1874m9T07JM2x+sHWCSyzUYVD2u/ot1pjt8 cEcAbDjbOsTmkznmFtU9zYxtz86+MqwBdArc1m/uHPfNVcXBnkMi6k6N38Km1e03jYLN mPT9ZP69cy5khJaGLke2FAiXBHEIcuSQACJgeo/1aBYvnH+hooKzc4qv/9zHH9zH4gF/ ZliOwPacUE0EHhWvB0bVdfuKsXPba1BwzRenVyMHOWPNir8kyzPUpyBSptu9RK71I0UQ whrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y9HF6dIlClFA17FAynh24ufmUBFchalOTV0l1ADt024=; b=GIjola73JAK58frANOkXCMKlsTo6pJOSMm7Q+Gs1cmaJnG3q/1nisYIt0cqRjtHUWl TV2RC4sWaI1gSFvEcSAVPeWpoNtcJRNnijOA8OPajlWPtF9mrMYvdTQIk+bB/IBVq/5M Z92SUmKX+HXF1IoSX0V9A0eBl5gZWfzZWZNoYXcNK8XnTux1sgCvZcuN/O9Cym42b7Gw zTOvNAP7WoD3jkm4ly3+R+dJm1wNg44IPKheywMFGqlw3wwMR3NZxR2TsOdJAkqazP4u PyM9P10sxH3ir2Ncjt+VMS9a6P1yIYz8tgNu3DCnHtXnXBCPrAYDSsn7gjIJCIa92OQE nYIw== X-Gm-Message-State: AN3rC/5eNW0M3qCMVKOMZNs8tPrebgyiGaTt85MgF4tXGSphVLnmacBc WZxrk/yaBeRYYGQdc/QMIFIBDcGRge0r X-Received: by 10.129.172.93 with SMTP id z29mr830241ywj.125.1492862070752; Sat, 22 Apr 2017 04:54:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Sat, 22 Apr 2017 04:53:50 -0700 (PDT) In-Reply-To: <1492786351.14070.2.camel@redhat.com> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> From: Eric Rescorla Date: Sat, 22 Apr 2017 07:53:50 -0400 Message-ID: To: Nikos Mavrogiannopoulos Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f403045f285c6d31bd054dc009a9 Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 22 Apr 2017 11:54:34 -0000 --f403045f285c6d31bd054dc009a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos wrote: > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > > > 4.1.1. HelloRetryRequest how many times can it be re-sent by the > > > server? I assume only a single one, but it maybe good to make it > > > explicit. > > > > This is forbidden in S 4.1.4. > > https://tlswg.github.io/tls13-spec/#hello-retry-request > > > > If a client receives a second HelloRetryRequest in the same > > connection (i.e., where the ClientHello was itself in response to > > a > > HelloRetryRequest), it MUST abort the handshake with an > > =E2=80=9Cunexpected_message=E2=80=9D alert. > > > > Does this seem sufficient? > > I must have missed it. Yes, it seems fine. > > > > 4.4.2.1. OCSP Status and SCT Extensions > > > This is a very nice addition to TLS 1.3. Something that I miss as > > an > > > implementer is guidelines on how to determine the (time) validity > > of an > > > OCSP stapled response. Here my point is that OCSP responses have > > > several fields optional (e.g., nextUpdate), which make a validation > > to > > > be hand-wavy. It would be nice to have a profile of OCSP responses > > that > > > would be recommended for use in TLS, as well or a recommendation of > > > what constitutes a "fresh" response for use in TLS. > > > > Do you have any thoughts on what text we should insert here? I admit > > to being not that familiar with the practical matters of OCSP > > stapling. > > My issue with OCSP when used under TLS was how to determine the > validity of the response when the nextUpdate field is missing. I've > added some text for that introducing an (arbitrary) upper limit at: > https://github.com/tlswg/tls13-spec/pull/974 This text looks good to me, but it is is a normative change and we've been through WGLC so I'd like to hear from a few other people that they're OK with it (or have the chairs tell me that silence is consent). David Benjamin? Richard Barnes? Ryan Sleevi? Thanks, -Ekr > > > > > 5.1. I miss a maximum number of alerts received per session, or > > some > > > other alert limiting mechanism (having CVE-2016-8610 in mind). > > > > All alerts now result in connection termination, so the limit > > seems to implicitly be 1. > > Nice. > > > > > > > > 7.5. There is no definition of early_exporter_secret, and it is > > unclear > > > why it is even mentioned. In short how is this supposed to be used, > > and > > > why should implementations consider adding an interface to it? > > > > It is defined in: > > https://tlswg.github.io/tls13-spec/#key-schedule > > > > I added some text to explain why you would want it. > > Thanks. There is a typo on that description "is define for use" -> "is > defined for use". > > > regards, > Nikos > > --f403045f285c6d31bd054dc009a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos <nmav@redhat.c= om> wrote:
On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote:

> > 4.1.1. HelloRetryRequest how many times can it be re-sent by the<= br> > > server? I assume only a single one, but it maybe good to make it<= br> > > explicit.
>
> This is forbidden in S 4.1.4.
> https://tlswg.github.io/tls13-spec/= #hello-retry-request
>
> =C2=A0 =C2=A0If a client receives a second HelloRetryRequest in the sa= me
> =C2=A0 =C2=A0connection (i.e., where the ClientHello was itself in res= ponse to
> a
> =C2=A0 =C2=A0HelloRetryRequest), it MUST abort the handshake with an > =C2=A0 =C2=A0=E2=80=9Cunexpected_message=E2=80=9D alert.
> =C2=A0 =C2=A0
> Does this seem sufficient?

I must have missed it. Yes, it seems fine.

> > 4.4.2.1.=C2=A0 OCSP Status and SCT Extensions
> > This is a very nice addition to TLS 1.3. Something that I miss as=
> an
> > implementer is guidelines on how to determine the (time) validity=
> of an
> > OCSP stapled response. Here my point is that OCSP responses have<= br> > > several fields optional (e.g., nextUpdate), which make a validati= on
> to
> > be hand-wavy. It would be nice to have a profile of OCSP response= s
> that
> > would be recommended for use in TLS, as well or a recommendation = of
> > what constitutes a "fresh" response for use in TLS.
>
> Do you have any thoughts on what text we should insert here? I admit > to being not that familiar with the practical matters of OCSP
> stapling.

My issue with OCSP when used under TLS was how to determine the
validity of the response when the nextUpdate field is missing. I've
added some text for that introducing an (arbitrary) upper limit at:
https://github.com/tlswg/tls13-spec/pull/974

This text looks good to me, but it is is a no= rmative change and we've
been through WGLC so I'd like to= hear from a few other people that they're OK
with it (or hav= e the chairs tell me that silence is consent). David Benjamin?
Ri= chard Barnes? Ryan Sleevi?

Thanks,
-Ekr<= /div>




> > 5.1. I miss a maximum number of alerts received per session, or > some
> > other alert limiting mechanism (having CVE-2016-8610 in mind). >
> All alerts now result in connection termination, so the limit
> seems to implicitly be 1.

Nice.

>
>
> > 7.5. There is no definition of early_exporter_secret, and it is > unclear
> > why it is even mentioned. In short how is this supposed to be use= d,
> and
> > why should implementations consider adding an interface to it? >
> It is defined in:
> https://tlswg.github.io/tls13-spec/#key-sc= hedule
>
> I added some text to explain why you would want it.

Thanks. There is a typo on that description "is define for use&= quot; -> "is
defined for use".

=C2=A0
regards,
Nikos


--f403045f285c6d31bd054dc009a9-- From nobody Sat Apr 22 05:00:28 2017 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 35B00129B6A for ; Sat, 22 Apr 2017 05:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 4-vPXeX6pJsq for ; Sat, 22 Apr 2017 05:00:22 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 27A43129BBF for ; Sat, 22 Apr 2017 05:00:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id A604C21BB7; Sat, 22 Apr 2017 15:00:20 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id zCnQIqXuWU4x; Sat, 22 Apr 2017 15:00:19 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 7FC1B2313; Sat, 22 Apr 2017 15:00:19 +0300 (EEST) Date: Sat, 22 Apr 2017 15:00:17 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Message-ID: <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 22 Apr 2017 12:00:26 -0000 On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote: > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > wrote: > > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > > > > Do you have any thoughts on what text we should insert here? I admit > > > to being not that familiar with the practical matters of OCSP > > > stapling. > > > > My issue with OCSP when used under TLS was how to determine the > > validity of the response when the nextUpdate field is missing. I've > > added some text for that introducing an (arbitrary) upper limit at: > > https://github.com/tlswg/tls13-spec/pull/974 > > > This text looks good to me, but it is is a normative change and we've > been through WGLC so I'd like to hear from a few other people that they're > OK > with it (or have the chairs tell me that silence is consent). David > Benjamin? > Richard Barnes? Ryan Sleevi? I searched what minimum standards for "public" CAs say. The maximum lifetime there is 10 days (but IIRC some widely-used root program has lower limit, might have been 7 days).. Anybody happens to know a CA that doesn't put NextUpdate in? If so, what's the OCSP issuance frequency? -Ilari From nobody Sat Apr 22 13:43:44 2017 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 BB96F126CD8 for ; Sat, 22 Apr 2017 13:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 BZYZoRmShj3h for ; Sat, 22 Apr 2017 13:43:41 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0113.outbound.protection.outlook.com [104.47.0.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F1E1205D3 for ; Sat, 22 Apr 2017 13:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M5tMkICuQp5lUK9LJicRg7c4Cu8+U/tADil5IQSWCQE=; b=HLyYwpYArqtbxjGefaT/erp4dACUD9rniNyP7XrG+Ozw5nAaMrsi022nTf3d3/ApmPOquqmK61ab2bAwiI6p3xF7Y0Jn8QwVeGvrlkMG0NA7D038vlejbhCphC4v5uCZXTYLDZyfCzPdGekoUPthUbUpXA3zCCOUA/VtqTm9bD8= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1101.eurprd07.prod.outlook.com (10.163.168.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Sat, 22 Apr 2017 20:43:36 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) with mapi id 15.01.1047.008; Sat, 22 Apr 2017 20:43:35 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: "Salz, Rich" , Ilari Liusvaara , Hannes Tschofenig CC: "" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [TLS] draft-rescorla-tls-subcerts-01 Thread-Index: AQHSunqIZYO5VLtqn0+DOPOxbhXZyKHPpMuAgAAWDwCAAD4pgIAB9P+A Date: Sat, 22 Apr 2017 20:43:35 +0000 Message-ID: References: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> <5C7D62E9-3F3F-45B6-B1AC-A92B95895A16@on.nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [92.20.252.102] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1101; 7:t7dCNjrDubPPWmCcuX9sYHV0+PlGBbljFwfcsys6Z+lNVFLH9Sguce2DGadGkLbbbFxXdW4HG4I2LpWCFSFqDu+I10vJZfsXc8UOQgFVTs4Mmchos60I5uKO3CzzPeTWhdenFCxjhb7Z5yFgMcdxYAPLqriWkfzH2bc2M8H+MVvHI0Owk0EVyK741YVwkhyiy4YoxBQmPgIyVVOhjdldZ3VZYX7WzJQBNWhTdMHB6u6xrwnsPd2ncOnqPkCg8GVhcv6dUKDOuRx5H7ndRcSLcFvP1Qump5uaLNVDtkFO7Ez4wEBGHZGqlSaoWvwt4vd/dz8h+uuQVVwhm/NqBcoxmA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39860400002)(39450400003)(39400400002)(39840400002)(39850400002)(24454002)(6512007)(6486002)(33656002)(6506006)(38730400002)(77096006)(6436002)(122556002)(83716003)(102836003)(99286003)(229853002)(6116002)(107886003)(2906002)(25786009)(3846002)(66066001)(53546009)(2950100002)(189998001)(53936002)(3660700001)(50986999)(6246003)(2900100001)(8676002)(305945005)(93886004)(54356999)(8936002)(3280700002)(4001350100001)(83506001)(4326008)(81166006)(5660300001)(82746002)(86362001)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1101; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 346743ee-ed36-4c01-4f82-08d489c03f3b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1101; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:VI1PR07MB1101; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1101; x-forefront-prvs: 0285201563 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2017 20:43:35.0938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1101 Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 22 Apr 2017 20:43:43 -0000 T24gMjEvMDQvMjAxNyAxNjo1MCwgIlNhbHosIFJpY2giIDxyc2FsekBha2FtYWkuY29tPiB3cm90 ZToNCj4gPiBTcGVha2luZyBhcyBvbmUgb2YgdGhlIGNvLWF1dGhvcnMgb2YgWzFdOiBpdCBpcyBu b3QgY29tcGxldGVseSBjbGVhciB0byBtZQ0KPiA+IHdoYXQgaXMgdGhlIGxpbWl0YXRpb24gaW4g Q1QgdGhhdCB3b3VsZCBwcmV2ZW50IGl0IHRvIGNvcGUgd2l0aCB0aGUNCj4gPiBwZXJ2YXNpdmUg dXNlIG9mIHNob3J0LXRlcm0gY2VydGlmaWNhdGVzLiAgQ2FuIGFueW9uZSBzaGVkIGEgbGlnaHQg b24gdGhpcz8NCj4gDQo+IEkgYmVsaWV2ZSB0aGUgY29uY2VybnMgYXJlIHNjYWxpbmcgbG9nIHNl cnZlcnMgYW5kIHBlcmhhcHMgbmVlZGluZyB0bw0KPiAicm90YXRlIiB0aGVtIGlmLCBzYXksIDkw JSBvZiB0aGVpciB0cmVlIGlzIGludmFsaWQgaW4gYSB5ZWFyLg0KDQpUaGFua3MgUmljaC4gIEkg bmVlZCB0byBkb3VibGUgY2hlY2sgdGhhdCwgYnV0IEkgZ3Vlc3MgdGhlcmUgYXJlIHJlbWVkaWVz IGZvcg0KdGhlIGlzc3VlcyB5b3UgbWVudGlvbiAtLSBlLmcuLCBhZGRpbmcgbW9yZSBsb2dzIC8g aGF2aW5nIHNlcGFyYXRlIGxvZ3MgZm9yDQp2ZXJ5IHNob3J0IHRlcm0gc3R1ZmYuDQoNCg== From nobody Sat Apr 22 13:46:01 2017 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 4469B126CD8; Sat, 22 Apr 2017 13:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 VQ9It7wY7J9U; Sat, 22 Apr 2017 13:45:51 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0124.outbound.protection.outlook.com [104.47.0.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5564A1205D3; Sat, 22 Apr 2017 13:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IPfvbFxklwuz0+wwkdYOz2JGf61a39TYfk3tFlrI0wE=; b=YxIq9Bgf9s+wiP1vVIylt+cu5ECnxENJrkSNtZBUPKWAaXbBQbSZGJ/YjdImCjW5ZGeAMSL1UtrsmFVMGOOb28Hom8xgbuvEVyNOHf42rK2LphJJDbfGLhmAMJjUgDzWfTdd1/1osHyGHUN9X9xarMuuxvohoGQONrH+DV1tjVc= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1101.eurprd07.prod.outlook.com (10.163.168.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Sat, 22 Apr 2017 20:45:48 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) with mapi id 15.01.1047.008; Sat, 22 Apr 2017 20:45:48 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Sean Turner , "" CC: "lurk@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts Thread-Index: AQHSs8NhzzsnOYQ6cUqHw4ZKRql4zaHR/BIA Date: Sat, 22 Apr 2017 20:45:47 +0000 Message-ID: <1C79FEF6-34A6-459E-AE45-2F6E6A78B45C@on.nokia.com> References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> In-Reply-To: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: sn3rd.com; dkim=none (message not signed) header.d=none;sn3rd.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [92.20.252.102] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1101; 7:AKxVsYp9thVS7Xb6GvjX6r4m+X/PnosjdlEttirt+yo/cLMpLhk2Qf/xuFupr3LnB93LO+GI9tpfUpqoaUXyxIP6WZzMXxpN+I2HAMb5VKr4WsTbyu5Vs64L8ownDA76ZVSCHv4/eO/ON7I0KhLIJFxk2Rp2mMrXnUK5iCSDaBoNPdlVZrXpSy5UtkRl9eqcrlARHquJcLCJmQcM9mgdZ/6EcGVY+mVzIXrJU8cDVCDctg/s5VWPqrxuNqrNiJJq05eeCnvnxJMQRbwFyDlkZNu6J2hZrTNU+ZNYyKjM81LBhdrV595ojsn2GSHAw1qu9ag+KSMyxCtRSVgKENQOGA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39860400002)(39450400003)(39400400002)(39840400002)(39850400002)(6512007)(6486002)(33656002)(6506006)(38730400002)(77096006)(6436002)(122556002)(83716003)(102836003)(99286003)(229853002)(6116002)(107886003)(54906002)(2906002)(25786009)(3846002)(66066001)(2950100002)(189998001)(53936002)(3660700001)(50986999)(6246003)(2900100001)(8676002)(305945005)(54356999)(8936002)(3280700002)(4001350100001)(83506001)(4326008)(81166006)(5660300001)(82746002)(86362001)(230783001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1101; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 2d2402c8-7fbe-46ad-3e0f-08d489c08e4e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1101; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:VI1PR07MB1101; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1101; x-forefront-prvs: 0285201563 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <550FFF2DD61E4244B27ABD981D50A94E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2017 20:45:47.8549 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1101 Archived-At: Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 22 Apr 2017 20:45:53 -0000 SSd2ZSByZWFkIGRyYWZ0LXJlc2NvcmxhLXRscy1zdWJjZXJ0cy0wMSBhbmQgaGF2ZSBhIGZldyBj b21tZW50cy4NCg0KSXQncyBhIHdlbGwgd3JpdHRlbiBkb2N1bWVudCBhbmQgdGhlIGxvdy1sZXZl bCBtZWNoYW5pY3MgbG9vayBvay4gIEhvd2V2ZXIsDQpJIHRoaW5rIEkgaGF2ZSBhIGNvdXBsZSBv ZiBpc3N1ZXMgd2l0aCB0aGUgb3ZlcmFsbCBkZXNpZ24uDQoNCkZpcnN0OiBpdCBpcyBub3Qgc2Vs Zi1zdWZmaWNpZW50LiAgVGhlIGZhY3QgdGhhdCBjbGllbnRzIG11c3Qgb3B0LWluIGltcGxpZXMN CnRoYXQgc2VydmVycyBtdXN0IGhhdmUgYSBiYWNrdXAgcGxhbi4gIFNpbmNlIGtlZXBpbmcgdGhl IGhpZ2gtdmFsdWUga2V5DQptYXRlcmlhbCBpbiB0aGUgc2FtZSBub2RlIGFzIHRoZSBkZWxlZ2F0 ZSBjcmVkZW50aWFscyBjb250cmFkaWN0cyB0aGUgYmFzaWMNCnNlY3VyaXR5IGdvYWwsIHRoZSBv bmx5IHJlYWxpc3RpYyBmYWxsYmFjayBpcyB0byBoYXZlIGEga2V5LXNlcnZlciAvIExVUksgYm94 DQphdCBoYW5kPyAgQnV0IHRoaXMgaGFzIHRoZSBrbm93biBhbmQgYWxyZWFkeSBkaXNjdXNzZWQg bGltaXRhdGlvbnMgLS0NCmNvbXBsaWNhdGVkIHNldHVwIGFuZCBvcGVyYXRpb25zLCBzY2FsaW5n IGlzc3Vlcywgc2luZ2xlIHBvaW50IG9mIGZhaWx1cmUsDQpldGMuIC0tIHdoaWNoIG1ha2UgaXQg aW5hcHBsaWNhYmxlIHRvIHNvbWUga2V5IHVzZSBjYXNlcyAoQ0ROKS4NCg0KU2Vjb25kLCB3ZSBu ZWVkIHRvIGNoYW5nZSB0aGUgc3RhY2sgYXQgdGhlIGVuZHBvaW50cy4gIFRoaXMgbWlnaHQgYmUg T0sgZm9yDQpicm93c2VycywgYnV0IGl0J3MgYSBiaXQgbW9yZSBwcm9ibGVtYXRpYyB3aGVuIHRo ZSBVQSBpcyBhbiBTVEIgb3IgYQ0KcmVzaWRlbnRpYWwgZ2F0ZXdheSwgYXMgdGhlc2UgdGhpbmdz IHRlbmQgdG8gaGF2ZSBtdWNoIHNsb3dlciByZWxlYXNlIGFuZA0KdXBncmFkZSBjeWNsZXMuDQoN CldpdGggcmVnYXJkcyB0byBXRyBhZG9wdGlvbiwgSSBndWVzcyBJJ20gbmV1dHJhbC4gIEkgdGhp bmsgaXQgZG9lc24ndCBodXJ0DQp0byBoYXZlIHNvbWV0aGluZyBsaWtlIHRoaXMsIGJ1dCBmb3Ig dGhlIHJlYXNvbnMgc3RhdGVkIGFib3ZlLCBJJ20gbm90IHN1cmUNCml0IHByb3ZpZGVzIGEgc29s dXRpb24gdG8gdGhlIExVUksgcHJvYmxlbS4NCg0KQ2hlZXJzLCB0DQoNClBTOiBJdCdkIGJlIG5p Y2UgaWYgdGhlIGRvY3VtZW50IGRpc2N1c3NlZCB0aGUgaW1wbGljYXRpb24gb2YgdGhlICJ1bnJl Z3VsYXRlZCINCmRlbGVnYXRpb24gbWVjaGFuaXNtIGVzcGVjaWFsbHkgd2l0aCByZWdhcmRzIHRv IGl0cyBhdWRpdGFiaWxpdHkuDQoNCg== From nobody Sat Apr 22 14:42:12 2017 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 0CC1C1243F3 for ; Sat, 22 Apr 2017 14:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 XNzDyG7TlqSZ for ; Sat, 22 Apr 2017 14:42:08 -0700 (PDT) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FC31205D3 for ; Sat, 22 Apr 2017 14:42:08 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 70303A8A32BD; Sat, 22 Apr 2017 21:42:06 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 558A51FE01C8; Sat, 22 Apr 2017 23:42:06 +0200 (CEST) Date: Sat, 22 Apr 2017 23:42:06 +0200 From: Kurt Roeckx To: Ilari Liusvaara Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20170422214205.bxu5whfqzy5kshsw@roeckx.be> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 22 Apr 2017 21:42:11 -0000 On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote: > On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote: > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > > wrote: > > > > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > > > > > > Do you have any thoughts on what text we should insert here? I admit > > > > to being not that familiar with the practical matters of OCSP > > > > stapling. > > > > > > My issue with OCSP when used under TLS was how to determine the > > > validity of the response when the nextUpdate field is missing. I've > > > added some text for that introducing an (arbitrary) upper limit at: > > > https://github.com/tlswg/tls13-spec/pull/974 > > > > > > This text looks good to me, but it is is a normative change and we've > > been through WGLC so I'd like to hear from a few other people that they're > > OK > > with it (or have the chairs tell me that silence is consent). David > > Benjamin? > > Richard Barnes? Ryan Sleevi? > > I searched what minimum standards for "public" CAs say. The maximum > lifetime there is 10 days (but IIRC some widely-used root program has > lower limit, might have been 7 days).. > > Anybody happens to know a CA that doesn't put NextUpdate in? If so, > what's the OCSP issuance frequency? The CA Browser baseline requirements have this in 4.9.7: For the status of Subscriber Certificates: If the CA publishes a CRL, then the CA SHALL update and reissue CRLs at least once every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field For the status of Subordinate CA Certificates: The CA SHALL update and reissue CRLs at least (i) once every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate, and the value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field. And in 4.9.10: For the status of Subscriber Certificates: The CA SHALL update in formation provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days. For the status of Subordinate CA Certificates: The CA SHALL update information provided via an Online Certificate Status Protocol at least (i) every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate. So for OCSP of a subordinate CAs there doesn't seem to be any requirement for a nextUpdate. Kurt From nobody Sat Apr 22 19:01:11 2017 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 CF5DB129ABD for ; Sat, 22 Apr 2017 19:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 Ug2p9GmsnaC1 for ; Sat, 22 Apr 2017 19:01:08 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2F8129AB5 for ; Sat, 22 Apr 2017 19:01:07 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id C3AD130002B26 for ; Sat, 22 Apr 2017 19:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=YYif2GN7sj7jp11NA97QEPgLh7w=; b= p3Ul4lP47TKX9vA5fdcm6Pv6KqyRugJTYqxF8qOKWRN32uEvDSZanvTxBBJ+cS2D pGcngaVv7YYx9DQh8H8LpbhjmcUmls/PfdleFaXrgd93CcwN9PsngEokykgnvwcj y0KtQlkK8/hNR10sXQCIY+c9Jzcf0PXG8OolIkLcWqg= Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 96FC430002B21 for ; Sat, 22 Apr 2017 19:01:05 -0700 (PDT) Received: by mail-lf0-f48.google.com with SMTP id 75so59526124lfs.2 for ; Sat, 22 Apr 2017 19:01:05 -0700 (PDT) X-Gm-Message-State: AN3rC/4bI4xdj8eMlucMLuusf2X0klwIHXJTDTap0hv8xKBx/noH6fL8 hXLnE1Kdp2uAXAY7pdSXJajuHfMYSQ== X-Received: by 10.25.204.67 with SMTP id c64mr5934872lfg.107.1492912863832; Sat, 22 Apr 2017 19:01:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.165.67 with HTTP; Sat, 22 Apr 2017 19:01:03 -0700 (PDT) In-Reply-To: <20170422214205.bxu5whfqzy5kshsw@roeckx.be> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> From: Ryan Sleevi Date: Sat, 22 Apr 2017 22:01:03 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Kurt Roeckx Cc: Ilari Liusvaara , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1a0bcaedf554054dcbdcd6 Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 23 Apr 2017 02:01:10 -0000 --94eb2c1a0bcaedf554054dcbdcd6 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx wrote: > > So for OCSP of a subordinate CAs there doesn't seem to be any > requirement for a nextUpdate. > Correct. This is part of the many asynchronicities related to CRLs and OCSP in the BRs (another example: https://cabforum.org/pipermail/public/2017-April/010497.html ) for which I'd love a consistent and normative profile, for which I have a bit of a normative profile already. My own $.02, however, is that I'm not keen to see such a profile of CA behaviour in TLS. It will almost certainly be ignored and/or supplanted. I'm not sure I understand under what adversarial or threat model this makes sense for TLS, since an OCSP responder that doesn't provide a nextUpdate can always have that message replayed to the client even if stapling was omitted. Or is the suggestion that a server that staples an expired response = fail the TLS connection, but a server that staples nothing, and the OCSP responder supplies an expired response = everything OK? If so, that asymmetry equally seems weird. Much like the question about whether or not the certificate chain is a 'bag of certs' or not, i'd rather not see this tackled in TLS, and see an appropriate profile (either for OCSP and/or within the CA/Browser Forum), that more consistently defines and addresses the threat model. --94eb2c1a0bcaedf554054dcbdcd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx <kurt@roeckx.be> wrote:
So for OCSP of a subordinate CAs there doesn't seem to be any
requirement for a nextUpdate.

Correct. = This is part of the many asynchronicities related to CRLs and OCSP in the B= Rs (another example:=C2=A0https://cabforum.org/pipermail/public/2017-April/01= 0497.html ) for which I'd love a consistent and normative profile, = for which I have a bit of a normative profile already.
=C2=A0
My own $.02, however, is that I'm not keen to see such a profile= of CA behaviour in TLS. It will almost certainly be ignored and/or supplan= ted. I'm not sure I understand under what adversarial or threat model t= his makes sense for TLS, since an OCSP responder that doesn't provide a= nextUpdate can always have that message replayed to the client even if sta= pling was omitted. Or is the suggestion that a server that staples an expir= ed response =3D fail the TLS connection, but a server that staples nothing,= and the OCSP responder supplies an expired response =3D everything OK? If = so, that asymmetry equally seems weird.

Much like = the question about whether or not the certificate chain is a 'bag of ce= rts' or not, i'd rather not see this tackled in TLS, and see an app= ropriate profile (either for OCSP and/or within the CA/Browser Forum), that= more consistently defines and addresses the threat model.
--94eb2c1a0bcaedf554054dcbdcd6-- From nobody Sun Apr 23 03:34:52 2017 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 4C4381276AF for ; Sun, 23 Apr 2017 03:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 65I225fbcN_V for ; Sun, 23 Apr 2017 03:34:48 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id C51CA1252BA for ; Sun, 23 Apr 2017 03:34:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 211C621AA4; Sun, 23 Apr 2017 13:34:45 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ZS42TjHD3YqY; Sun, 23 Apr 2017 13:34:44 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id B3450C4; Sun, 23 Apr 2017 13:34:44 +0300 (EEST) Date: Sun, 23 Apr 2017 13:34:42 +0300 From: Ilari Liusvaara To: Kurt Roeckx Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170422214205.bxu5whfqzy5kshsw@roeckx.be> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 23 Apr 2017 10:34:50 -0000 On Sat, Apr 22, 2017 at 11:42:06PM +0200, Kurt Roeckx wrote: > On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote: > > On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote: > > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > > > wrote: > > > > > > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > > > > > > > > Do you have any thoughts on what text we should insert here? I admit > > > > > to being not that familiar with the practical matters of OCSP > > > > > stapling. > > > > > > > > My issue with OCSP when used under TLS was how to determine the > > > > validity of the response when the nextUpdate field is missing. I've > > > > added some text for that introducing an (arbitrary) upper limit at: > > > > https://github.com/tlswg/tls13-spec/pull/974 > > > > > > > > > This text looks good to me, but it is is a normative change and we've > > > been through WGLC so I'd like to hear from a few other people that they're > > > OK > > > with it (or have the chairs tell me that silence is consent). David > > > Benjamin? > > > Richard Barnes? Ryan Sleevi? > > > > I searched what minimum standards for "public" CAs say. The maximum > > lifetime there is 10 days (but IIRC some widely-used root program has > > lower limit, might have been 7 days).. > > > > Anybody happens to know a CA that doesn't put NextUpdate in? If so, > > what's the OCSP issuance frequency? > I meant if anyone has seen a OCSP response from "public" CA lately that lacks NextUpdate. And the 12 month update interval for intermediates is IMO just crazy, and won't work properly in TLS 1.3, now that multistaple is pretty much a baseline feature. Looking at those rules, 7 day default would still work fine with 4 day issue frequency. And 7 days also seems to be the limit for various kinds caching (e.g. tickets, subcerts, etc...) that circumvent revocation in various drafts and specs. As for what the TLS library I have written does if OCSP staple lacks NextUpdate, it outright causes handshake failure and fatal alert. -Ilari From nobody Sun Apr 23 09:01:15 2017 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 A0EFA120227 for ; Sun, 23 Apr 2017 09:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 9v4ZVHygqGqg for ; Sun, 23 Apr 2017 09:01:12 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A8B12420B for ; Sun, 23 Apr 2017 09:01:12 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 8B0A0A00491F for ; Sun, 23 Apr 2017 09:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=wAVnqGuObT/imm32n/Cpcso0wfM=; b= XKTARr/JaPqIGHE8e89nBHElNVW0lmK4isSH6yoqMKjcVz/ZEjA5LRGhJl/MvF65 fJDfhYEWMmrYrxlUdOGJC7+Pe45wGGhUcdoJqE2ykczfp33uflWj70SwZ2meG1XW xT/XdXJOocWWapqM7bRmwwv6lRF3brBLIAmqoP3NXwc= Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 54B0FA00491E for ; Sun, 23 Apr 2017 09:01:11 -0700 (PDT) Received: by mail-lf0-f46.google.com with SMTP id 88so63280912lfr.0 for ; Sun, 23 Apr 2017 09:01:11 -0700 (PDT) X-Gm-Message-State: AN3rC/7MIruhZZFOIRfj9Yyonlyqr8CnX5FCSIvXjCkMy30kN1M3gzeW 9rNVD0Ups52LuHjeuUUz81ylvW0z0A== X-Received: by 10.46.21.12 with SMTP id s12mr7779151ljd.47.1492963269157; Sun, 23 Apr 2017 09:01:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.165.67 with HTTP; Sun, 23 Apr 2017 09:01:08 -0700 (PDT) In-Reply-To: <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> From: Ryan Sleevi Date: Sun, 23 Apr 2017 12:01:08 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Ilari Liusvaara Cc: Kurt Roeckx , "tls@ietf.org" Content-Type: multipart/alternative; boundary=f403045f76aa52325a054dd7992c Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 23 Apr 2017 16:01:14 -0000 --f403045f76aa52325a054dd7992c Content-Type: text/plain; charset=UTF-8 On Sun, Apr 23, 2017 at 6:34 AM, Ilari Liusvaara wrote: > > I meant if anyone has seen a OCSP response from "public" CA lately that > lacks NextUpdate. > Why would it matter? Are you suggesting we determine what should be part of TLS based on what CAs are doing? That's going to be sadness all around :) > And the 12 month update interval for intermediates is IMO just crazy, > and won't work properly in TLS 1.3, now that multistaple is pretty much > a baseline feature. > I have no desire to support multistaple within Chrome. That it's specified is great, but I believe multistaple is, for the general _browser_ case, unnecessary. That's not to say it's not useful in other venues or in specialized cases, which is the only reason I haven't complained here. > Looking at those rules, 7 day default would still work fine with 4 day > issue frequency. And 7 days also seems to be the limit for various > kinds caching (e.g. tickets, subcerts, etc...) that circumvent > revocation in various drafts and specs. > Again, that's public CAs. There are more participants in the ecosystem than that. I don't think it's necessary or appropriate to set an upperbound based on the Baseline Requirements. For that matter, I don't believe it's necessary or appropriate to set an upperbound in TLS at all. > > > As for what the TLS library I have written does if OCSP staple lacks > NextUpdate, it outright causes handshake failure and fatal alert. > So far, the preference on our end has been for a TLS library that doesn't have to have deeply-ingrained knowledge of the PKI, including OCSP, and instead treat these as separate layers. This PR necessitates that awareness by force of spec, and as such, makes it either unnecessarily difficult to implement or simply unlikely to be implemented. Given that stapling "issues" exist even without stapling, it does seem an unnecessary reach to include within the spec. --f403045f76aa52325a054dd7992c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 23, 2017 at 6:34 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
I meant if anyone has seen a OCSP response from "public" CA latel= y that
lacks NextUpdate.

Why would it matter? = Are you suggesting we determine what should be part of TLS based on what CA= s are doing? That's going to be sadness all around :)
=C2=A0<= /div>
And the 12 month update interval for intermediates is IMO just crazy,
and won't work properly in TLS 1.3, now that multistaple is pretty much=
a baseline feature.

I have no desire to= support multistaple within Chrome. That it's specified is great, but I= believe multistaple is, for the general _browser_ case, unnecessary. That&= #39;s not to say it's not useful in other venues or in specialized case= s, which is the only reason I haven't complained here.
=C2=A0=
Looking at those rules, 7 day default would still work fine with 4 day
issue frequency. And 7 days also seems to be the limit for various
kinds caching (e.g. tickets, subcerts, etc...) that circumvent
revocation in various drafts and specs.

Again, that's public CAs. There are more participants in the ecosystem= than that. I don't think it's necessary or appropriate to set an u= pperbound based on the Baseline Requirements. For that matter, I don't = believe it's necessary or appropriate to set an upperbound in TLS at al= l.
=C2=A0


As for what the TLS library I have written does if OCSP staple lacks
NextUpdate, it outright causes handshake failure and fatal alert.

So far, the preference on our end has been for a= TLS library that doesn't have to have deeply-ingrained knowledge of th= e PKI, including OCSP, and instead treat these as separate layers. This PR = necessitates that awareness by force of spec, and as such, makes it either = unnecessarily difficult to implement or simply unlikely to be implemented. = Given that stapling "issues" exist even without stapling, it does= seem an unnecessary reach to include within the spec.
--f403045f76aa52325a054dd7992c-- From nobody Sun Apr 23 09:39:35 2017 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 E4E451274D0 for ; Sun, 23 Apr 2017 09:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 9bc2x5fZ4UNm for ; Sun, 23 Apr 2017 09:39:31 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id E12EF120227 for ; Sun, 23 Apr 2017 09:39:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 0FD0421A33; Sun, 23 Apr 2017 19:39:29 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id NNoPalKFrJfP; Sun, 23 Apr 2017 19:39:28 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id B7E8827F; Sun, 23 Apr 2017 19:39:28 +0300 (EEST) Date: Sun, 23 Apr 2017 19:39:27 +0300 From: Ilari Liusvaara To: Ryan Sleevi Cc: Kurt Roeckx , "tls@ietf.org" Message-ID: <20170423163926.GA17271@LK-Perkele-V2.elisa-laajakaista.fi> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 23 Apr 2017 16:39:33 -0000 On Sun, Apr 23, 2017 at 12:01:08PM -0400, Ryan Sleevi wrote: > On Sun, Apr 23, 2017 at 6:34 AM, Ilari Liusvaara > wrote: > > > And the 12 month update interval for intermediates is IMO just crazy, > > and won't work properly in TLS 1.3, now that multistaple is pretty much > > a baseline feature. > > > > I have no desire to support multistaple within Chrome. That it's specified > is great, but I believe multistaple is, for the general _browser_ case, > unnecessary. That's not to say it's not useful in other venues or in > specialized cases, which is the only reason I haven't complained here. Well, given the 12 month(!!!) uppoer limit on public CAs, supporting intermediate stapling would be downright harmful. And that kind of upper limit makes the non-stapled version just useless. I imagine browsers have their own CA revocation lists, and don't use any form of CA-published CRLs nor OCSP. WebPKI does not take revocation seriously. -Ilari From nobody Sun Apr 23 11:19:00 2017 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 6A280127342 for ; Sun, 23 Apr 2017 11:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 GVexaFywWBqE for ; Sun, 23 Apr 2017 11:18:56 -0700 (PDT) Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD04E1270FC for ; Sun, 23 Apr 2017 11:18:56 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 136FAA8A01C4; Sun, 23 Apr 2017 18:18:52 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id E4A181FE05A2; Sun, 23 Apr 2017 20:18:51 +0200 (CEST) Date: Sun, 23 Apr 2017 20:18:51 +0200 From: Kurt Roeckx To: Ryan Sleevi Cc: Ilari Liusvaara , "tls@ietf.org" Message-ID: <20170423181851.myedywszjezeftl7@roeckx.be> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 23 Apr 2017 18:18:58 -0000 On Sun, Apr 23, 2017 at 12:01:08PM -0400, Ryan Sleevi wrote: > > And the 12 month update interval for intermediates is IMO just crazy, > > and won't work properly in TLS 1.3, now that multistaple is pretty much > > a baseline feature. > > > > I have no desire to support multistaple within Chrome. That it's specified > is great, but I believe multistaple is, for the general _browser_ case, > unnecessary. That's not to say it's not useful in other venues or in > specialized cases, which is the only reason I haven't complained here. I think your general browser case is that the browsers have worked around it by having a different mechanism to revoke them. I believe it would be better that browsers didn't have to do this, so that it worked properly in all cases. Kurt From nobody Sun Apr 23 11:46:36 2017 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 BCD1A1294F0 for ; Sun, 23 Apr 2017 11:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 KmHJkB7Wohqj for ; Sun, 23 Apr 2017 11:46:32 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C310C1252BA for ; Sun, 23 Apr 2017 11:46:32 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 4192A33D1BA; Sun, 23 Apr 2017 18:46:32 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Ilari Liusvaara Cc: Eric Rescorla , "tls@ietf.org" References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> From: Geoffrey Keating Date: 23 Apr 2017 11:46:32 -0700 In-Reply-To: <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 23 Apr 2017 18:46:35 -0000 Ilari Liusvaara writes: > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > > wrote: > > > > > My issue with OCSP when used under TLS was how to determine the > > > validity of the response when the nextUpdate field is missing. I've > > > added some text for that introducing an (arbitrary) upper limit at: > > > https://github.com/tlswg/tls13-spec/pull/974 ... > Anybody happens to know a CA that doesn't put NextUpdate in? If so, > what's the OCSP issuance frequency? The definition is: If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time. I think 15 days is much too long. I would suggest wording it more like: If the nextUpdate value is omitted, the server SHOULD refresh the response so that the thisUpdate field is no more than 24 hours in the past. and not place any requirement on the client; if the client wants fresher information than the server provides, it can go fetch it itself. From nobody Mon Apr 24 00:58:19 2017 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 BDD84129407 for ; Mon, 24 Apr 2017 00:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 3xYg2vrT28g9 for ; Mon, 24 Apr 2017 00:58:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7595412940A for ; Mon, 24 Apr 2017 00:58:16 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5E5CD19CBD1; Mon, 24 Apr 2017 07:58:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5E5CD19CBD1 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5E5CD19CBD1 Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.2.129]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4E2765C466; Mon, 24 Apr 2017 07:58:14 +0000 (UTC) Message-ID: <1493020692.3390.8.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Ryan Sleevi , Ilari Liusvaara Cc: "tls@ietf.org" Date: Mon, 24 Apr 2017 09:58:12 +0200 In-Reply-To: References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 24 Apr 2017 07:58:15 +0000 (UTC) Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 07:58:18 -0000 On Sun, 2017-04-23 at 12:01 -0400, Ryan Sleevi wrote: > > > > As for what the TLS library I have written does if OCSP staple > > lacks > > NextUpdate, it outright causes handshake failure and fatal alert. > > So far, the preference on our end has been for a TLS library that > doesn't have to have deeply-ingrained knowledge of the PKI, including > OCSP, and instead treat these as separate layers. This PR > necessitates that awareness by force of spec, That's intentional. Not every application is firefox or chrome and thus application writers cannot be expected to set sane defaults for OCSP validity time _when the nextUpdate field is missing_. The reason they cannot be expected to do that, is that it is not by way obvious what to do. Ilari's implentation closes the connection, mine sets a limit of 15 days, and I guess each and every other one behaves differently. It is the role of the standards to clarify uncertainties for implementers or forbid such options (I'd equally be happy if we have a text that forbids an empty nextUpdate field in OCSP responses to be used in the context of TLS 1.3 ocsp stapling). > Given that stapling "issues" exist even without stapling, it does > seem an unnecessary reach to include within the spec. There is a usability and interoperability issue there. Given that there is no common interpretation of what the missing nextUpdate field means in terms of validity, there some equally valid interpretations: 1. the response is invalid for use in TLS 1.3 2. the response is valid for a limited amount of time 1, 7, 8, 9, 15 days 3. the response is valid for an unlimited amount of time (which raises the question of why staple at all in that case?) Without a clarification in the spec, we are going to see implementations that fail when encountered with such response, implementations that work fine, and implementations that claim the response is too old. That would most likely result to ocsp stapling becoming the thing to disable for things to work. regards, Nikos From nobody Mon Apr 24 01:20:15 2017 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 1C07B12960D for ; Mon, 24 Apr 2017 01:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 i2yzvxpqlasa for ; Mon, 24 Apr 2017 01:20:12 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 47A7412957F for ; Mon, 24 Apr 2017 01:20:12 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id e132so45578588ite.1 for ; Mon, 24 Apr 2017 01:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bkn52+bprOgS8DjcRLHj82SdUKMvYaylICOL7uoSSyI=; b=LTG2ywgnKBJynrWUZYtWaM5D40wSU7LQTr2ank7KJumrT+CZLmX+S0h8WTdVnpuLEh utjuiHrq8dlJa8AyxDz8AVov0OaSJZtGkCJtCv1S4tRD6TvrwaqafvhqiBPZAhwlq6P0 5GBtlw/ztjLtbbIRfHHGb/yqD2ENTY6yL4biUuUgaAgPXscxkSOX5Jim3HvG8p6LeV/S 4TSQlWmMR4wm8bIk40VQ11MpXmwduvwV2tEIxZ12C9qqgcv2S0OC9zdtyJnPaA0SRCPe 3LMxH1KvhGy7/XWxFfPrd5XYxktSVkJyOEPhWiDIWvogHsVOehu3EwsYyAug9uHEuGCM GUGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bkn52+bprOgS8DjcRLHj82SdUKMvYaylICOL7uoSSyI=; b=QYVG9CFaFMsUfqf9xWtrSuaGoS8iGNloaBIO0PyfZrQ7LQ6Wctrnqa+AtcOOlKnnZd m0cpVQBSgdRD6tqadpE9FoDdTC1rQST3mjn4B5Q7+FR6JLzsFvXYfQ+UBWDODhmqtZFb Ygg8pNMUnbz7WE+2cBXYh+2qBjryMrClqeIaLf0gGI/box2gp6Y2XRv8D3Zcc/3jqUU6 RdPHEGb3uyKDLPSRJQpNkei6WtHvwDDTYHWnS7vecVd3E9jiAJf1hCBEpZaVQhi3dhn/ 7+fR1/HyjDTAD7mr/m2Dupd1zwXtUPu3whqWDHpOy1R4h9XHIfjYRGNWxdFatRE5072X eLGQ== X-Gm-Message-State: AN3rC/4T+lzTutcvy30CqaSK1iSKz1RlresndTuItcQVnPAv8hTP1JwA yBjL97t+4963rCq/41fqgx9MImMRG5qE X-Received: by 10.36.74.82 with SMTP id k79mr11697435itb.58.1493021879759; Mon, 24 Apr 2017 01:17:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.73.154 with HTTP; Mon, 24 Apr 2017 01:17:58 -0700 (PDT) In-Reply-To: References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> From: Brian Smith Date: Sun, 23 Apr 2017 22:17:58 -1000 Message-ID: To: Ryan Sleevi Cc: Kurt Roeckx , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1144e054c909ad054de53eda Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 08:20:14 -0000 --001a1144e054c909ad054de53eda Content-Type: text/plain; charset=UTF-8 Ryan Sleevi wrote: > On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx wrote: >> >> So for OCSP of a subordinate CAs there doesn't seem to be any >> requirement for a nextUpdate. >> > > Correct. This is part of the many asynchronicities related to CRLs and > OCSP in the BRs (another example: https://cabforum.org/ > pipermail/public/2017-April/010497.html ) for which I'd love a consistent > and normative profile, for which I have a bit of a normative profile > already. > > My own $.02, however, is that I'm not keen to see such a profile of CA > behaviour in TLS. It will almost certainly be ignored and/or supplanted. > The TLS 1.3 specification isn't the right place to specify what to do with OCSP responses that do not have a nextUpdate field. Cheers, Brian -- https://briansmith.org/ --001a1144e054c909ad054de53eda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ryan= Sleevi <ryan-ietftls@sleevi.com> wrote:
On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roe= ckx <kurt@roeckx.be> wrote:
So for OCSP of a subordinate CAs there doesn't seem to be any
requirement for a nextUpdate.

Co= rrect. This is part of the many asynchronicities related to CRLs and OCSP i= n the BRs (another example:=C2=A0https://cabforum.org/= pipermail/public/2017-April/010497.html ) for which I'd love a= consistent and normative profile, for which I have a bit of a normative pr= ofile already.
=C2=A0
My own $.02, however, is that I&#= 39;m not keen to see such a profile of CA behaviour in TLS. It will almost = certainly be ignored and/or supplanted.

The TLS 1.3 specification isn't the right place to= specify what to do with OCSP responses that do not have a nextUpdate field= .

Cheers,
Brian
--
--001a1144e054c909ad054de53eda-- From nobody Mon Apr 24 05:21:34 2017 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 460DB129413 for ; Mon, 24 Apr 2017 05:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001] 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 lgmlKcMi2Btc for ; Mon, 24 Apr 2017 05:21:29 -0700 (PDT) Received: from mail.objectiveintegration.uk (objectiveintegration.uk [134.213.135.47]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1411A1314B4 for ; Mon, 24 Apr 2017 05:21:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.objectiveintegration.uk (Postfix) with ESMTP id 7C0791A02E46 for ; Mon, 24 Apr 2017 12:21:27 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at objectiveintegration.uk Received: from mail.objectiveintegration.uk ([127.0.0.1]) by localhost (mail.objectiveintegration.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sax_pJKD_5MJ for ; Mon, 24 Apr 2017 12:21:04 +0000 (UTC) Received: from [192.168.110.3] (host86-179-241-20.range86-179.btcentralplus.com [86.179.241.20]) (Authenticated sender: mark.dunn@objectiveintegration.uk) by mail.objectiveintegration.uk (Postfix) with ESMTPSA id 2C0A11A01A96 for ; Mon, 24 Apr 2017 12:21:04 +0000 (UTC) From: Mark Dunn To: "tls@ietf.org" Message-ID: <1989fd9d-d76c-bc0c-dce0-de47a76fe94c@objectiveintegration.uk> Date: Mon, 24 Apr 2017 13:21:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] TLS: Cryptographic Computations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 12:21:31 -0000 Sorry, I am having a dull moment trying to understand the Transcript-hash, could someone help please? From *TLS 1.3: section 4* I have: enum { client_hello(1), server_hello(2), new_session_ticket(4), end_of_early_data(5), hello_retry_request(6), encrypted_extensions(8), certificate(11), certificate_request(13), certificate_verify(15), finished(20), key_update(24), message_hash(254), (255) } HandshakeType; struct { HandshakeType msg_type; /* handshake type */ uint24 length; /* bytes in message */ select (Handshake.msg_type) { case client_hello: ClientHello; case server_hello: ServerHello; case end_of_early_data: EndOfEarlyData; case hello_retry_request: HelloRetryRequest; case encrypted_extensions: EncryptedExtensions; case certificate_request: CertificateRequest; case certificate: Certificate; case certificate_verify: CertificateVerify; case finished: Finished; case new_session_ticket: NewSessionTicket; case key_update: KeyUpdate; } body; } Handshake; and from *TLS 1.3: Section 4.1* I have: uint16 ProtocolVersion; opaque Random[32]; uint8 CipherSuite[2]; /* Cryptographic suite selector */ struct { ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ Random random; opaque legacy_session_id<0..32>; CipherSuite cipher_suites<2..2^16-2>; opaque legacy_compression_methods<1..2^8-1>; Extension extensions<8..2^16-1>; } ClientHello; So combining the two for a ClientHello gives something like struct { HandshakeType msg_type = 0x01; /* handshake type client_hello*/ uint24 length = 0x001234; /* example of number of bytes in message */ struct { ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ Random random; ... } ClientHello; } ClientHelloHandshake In trying to understand the transcript hash, I read in *TLS **1.3: section 7* "Note that because the handshake transcript includes the random values in the Hello messages, any given handshake will have different traffic secrets" This gives me a warm fuzzy feeling but *TLS 1.3: section 7.1* states "Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers." I am guessing that "handshake message" is the ClientHelloHandshake I created above and the "record layer headers" is the ClientHello, Does this mean that the transcript-hash just uses the ClientHelloHandshake.msg_type and ClientHelloHandshake.length highlighted below? struct { *HandshakeType msg_type = 0x01; /* handshake type client_hello*/ uint24 length = 0x001234; /* example of number of bytes in message */* struct { ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ Random random; ... } ClientHello; } ClientHelloHandshake If so, how does ClientHelloHandshake.ClientHello.random get included in the handshake transcript? From nobody Mon Apr 24 05:39:27 2017 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 97D4B129438 for ; Mon, 24 Apr 2017 05:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 UYQuRcBI5pjY for ; Mon, 24 Apr 2017 05:39:23 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 79F2512EC04 for ; Mon, 24 Apr 2017 05:39:23 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id k11so31620207ywb.1 for ; Mon, 24 Apr 2017 05:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sAzzISBmD5wxua4IyWkagCqdVTynVhqUUClhywbbdd4=; b=iCYxdEOvAoUDhOS2sz5NSmOQPa09b/kF0zdIutCsrudprYTWOKSGmDq9JUGHSdFX02 fmCX6KR37R+Ht04Y/FRGeQ7I8kA91l4uCtzjvkCeIjT9T+rlhdrOLJ7UlMQ4PjSmhnWB cotgVuLWK7NCIPRY3zjdpv8q2bAqGkn7kl8LXcrWrtCBCXznCCkPQEeFCeYUR5aZz7LW NPn7jD63Z5RYcQob7UIUFcoFgL2yCHCMoyVuCVvM7TnWZeFLnah61cUGI+JtsLH1shqB /3wyXCbmfCFN4Pfv2gq1Xi6wFeAQsKV66fFRAMFX4W8vKkzJHPBhGVnVn58tjqO8THq7 ZAqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sAzzISBmD5wxua4IyWkagCqdVTynVhqUUClhywbbdd4=; b=Uj+Idg1gjvE6GijNtpZVFEAXv6y0HkzBqeaJcmTf7JpwsdLL8NmGCrmsFfqJCwmKxi GmiSHVf/Zra7yinzkjb4tOkDPYl2WaDI0uzt37Tkqz0FSrQ9kcv+RHOT7WCRmsPWD67N 7ihxUMWTmZZDRT2qqkxYuvIQGGX4OAA4RKmV9UoLlBU5OIF77dhOEd3hBtvbZUv1/ZnM BV6P+QOLLmyDRRi2soWmEBmH9zeETeHW1yaL9dCDqeYxnw9PKJlPQW35OOAPJeYQ2qJ0 s1/nmOZfa6IGFfQpzklCjNoz0FBTe+MBl95Il7Rw3GaeF3u/lQ5HjeIXrf62Weyj+lM+ SCyA== X-Gm-Message-State: AN3rC/7oqhZNoWhspmYrJpIhhRIJNnkkocJ3fsFS9ENLRCFKL0pQS1eR lBidY3l+vy8drVFoVes+sjzuzMkugPblSzE= X-Received: by 10.13.203.73 with SMTP id n70mr4532461ywd.71.1493037562759; Mon, 24 Apr 2017 05:39:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 24 Apr 2017 05:38:42 -0700 (PDT) In-Reply-To: <1989fd9d-d76c-bc0c-dce0-de47a76fe94c@objectiveintegration.uk> References: <1989fd9d-d76c-bc0c-dce0-de47a76fe94c@objectiveintegration.uk> From: Eric Rescorla Date: Mon, 24 Apr 2017 05:38:42 -0700 Message-ID: To: Mark Dunn Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114fd3d6909cc7054de8e5c9 Archived-At: Subject: Re: [TLS] TLS: Cryptographic Computations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 12:39:26 -0000 --001a114fd3d6909cc7054de8e5c9 Content-Type: text/plain; charset=UTF-8 Hi Mark, You might find it helpful to refer to: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ Which contains test vectors. On Mon, Apr 24, 2017 at 5:21 AM, Mark Dunn < mark.dunn@objectiveintegration.uk> wrote: > Sorry, I am having a dull moment trying to understand the Transcript-hash, > could someone help please? > > From *TLS 1.3: section 4* I have: > > enum { > client_hello(1), > server_hello(2), > new_session_ticket(4), > end_of_early_data(5), > hello_retry_request(6), > encrypted_extensions(8), > certificate(11), > certificate_request(13), > certificate_verify(15), > finished(20), > key_update(24), > message_hash(254), > (255) > } HandshakeType; > > struct { > HandshakeType msg_type; /* handshake type */ > uint24 length; /* bytes in message */ > select (Handshake.msg_type) { > case client_hello: ClientHello; > case server_hello: ServerHello; > case end_of_early_data: EndOfEarlyData; > case hello_retry_request: HelloRetryRequest; > case encrypted_extensions: EncryptedExtensions; > case certificate_request: CertificateRequest; > case certificate: Certificate; > case certificate_verify: CertificateVerify; > case finished: Finished; > case new_session_ticket: NewSessionTicket; > case key_update: KeyUpdate; > } body; > } Handshake; > > and from *TLS 1.3: Section 4.1* I have: > > uint16 ProtocolVersion; > opaque Random[32]; > > uint8 CipherSuite[2]; /* Cryptographic suite selector */ > > struct { > ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ > Random random; > opaque legacy_session_id<0..32>; > CipherSuite cipher_suites<2..2^16-2>; > opaque legacy_compression_methods<1..2^8-1>; > Extension extensions<8..2^16-1>; > } ClientHello; > > So combining the two for a ClientHello gives something like > > struct { > HandshakeType msg_type = 0x01; /* handshake type > client_hello*/ > uint24 length = 0x001234; /* example of number of > bytes in message */ > struct { > ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ > Random random; > ... > } ClientHello; > } ClientHelloHandshake > > In trying to understand the transcript hash, I read in *TLS **1.3: section > 7* > > "Note that because the handshake transcript includes the random values > in the Hello messages, any given handshake will have different traffic > secrets" > > This gives me a warm fuzzy feeling but *TLS 1.3: section 7.1* states > > "Messages are the concatenation of the indicated handshake messages, > including the handshake message type and length fields, but not including > record layer headers." > > I am guessing that "handshake message" is the ClientHelloHandshake I > created above and the "record layer headers" is the ClientHello, > I think this is where you are going wrong. Remember that in order to be serialized on the wire the handshake message is wrapped in a TLSPlaintext structure (and then potentially encrypted). It's those which are the record headers and which are excluded. What is included is what you are calling ClientHelloHandshake. -Ekr Does this mean that the transcript-hash just uses the > ClientHelloHandshake.msg_type and ClientHelloHandshake.length highlighted > below? > > struct { > *HandshakeType msg_type = 0x01; /* handshake type client_hello*/ uint24 > length = 0x001234; /* example of number of bytes in message */* > struct { > ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ > Random random; > ... > } ClientHello; > } ClientHelloHandshake > > If so, how does ClientHelloHandshake.ClientHello.random get included in > the handshake transcript? > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114fd3d6909cc7054de8e5c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mark,

You might find it helpful to r= efer to:

Which contains test vectors.
<= div>

On = Mon, Apr 24, 2017 at 5:21 AM, Mark Dunn <mark.dunn@objecti= veintegration.uk> wrote:
So= rry, I am having a dull moment trying to understand the Transcript-hash, co= uld someone help please?

>From *TLS 1.3: section 4* I have:

=C2=A0 =C2=A0enum {
=C2=A0 =C2=A0 =C2=A0 =C2=A0client_hello(1),
=C2=A0 =C2=A0 =C2=A0 =C2=A0server_hello(2),
=C2=A0 =C2=A0 =C2=A0 =C2=A0new_session_ticket(4),
=C2=A0 =C2=A0 =C2=A0 =C2=A0end_of_early_data(5),
=C2=A0 =C2=A0 =C2=A0 =C2=A0hello_retry_request(6),
=C2=A0 =C2=A0 =C2=A0 =C2=A0encrypted_extensions(8),
=C2=A0 =C2=A0 =C2=A0 =C2=A0certificate(11),
=C2=A0 =C2=A0 =C2=A0 =C2=A0certificate_request(13),
=C2=A0 =C2=A0 =C2=A0 =C2=A0certificate_verify(15),
=C2=A0 =C2=A0 =C2=A0 =C2=A0finished(20),
=C2=A0 =C2=A0 =C2=A0 =C2=A0key_update(24),
=C2=A0 =C2=A0 =C2=A0 =C2=A0message_hash(254),
=C2=A0 =C2=A0 =C2=A0 =C2=A0(255)
=C2=A0 =C2=A0} HandshakeType;

=C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0HandshakeType msg_type;=C2=A0 =C2=A0 /* handshak= e type */
=C2=A0 =C2=A0 =C2=A0 =C2=A0uint24 length;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0/* bytes in message */
=C2=A0 =C2=A0 =C2=A0 =C2=A0select (Handshake.msg_type) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case client_hello:=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ClientHello;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case server_hello:=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ServerHello;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case end_of_early_data:=C2=A0 =C2= =A0 =C2=A0EndOfEarlyData;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case hello_retry_request:=C2=A0 = =C2=A0HelloRetryRequest;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case encrypted_extensions:=C2=A0 E= ncryptedExtensions;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case certificate_request:=C2=A0 = =C2=A0CertificateRequest;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case certificate:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Certificate;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case certificate_verify:=C2=A0 =C2= =A0 CertificateVerify;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case finished:=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Finished;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case new_session_ticket:=C2=A0 =C2= =A0 NewSessionTicket;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case key_update:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 KeyUpdate;
=C2=A0 =C2=A0 =C2=A0 =C2=A0} body;
=C2=A0 =C2=A0} Handshake;

and from *TLS 1.3: Section 4.1* I have:

=C2=A0 =C2=A0uint16 ProtocolVersion;
=C2=A0 =C2=A0opaque Random[32];

=C2=A0 =C2=A0uint8 CipherSuite[2];=C2=A0 =C2=A0 /* Cryptographic suite sele= ctor */

=C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0ProtocolVersion legacy_version =3D 0x0303;=C2=A0= =C2=A0 /* TLS v1.2 */
=C2=A0 =C2=A0 =C2=A0 =C2=A0Random random;
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaque legacy_session_id<0..32>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0CipherSuite cipher_suites<2..2^16-2>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaque legacy_compression_methods<1..2^8= -1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0Extension extensions<8..2^16-1>;
=C2=A0 =C2=A0} ClientHello;

So combining the two for a ClientHello gives something like

=C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 HandshakeType msg_type=C2=A0 =3D 0x01;=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0/* handshake type client_hello*/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint24 length=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0=3D 0x001234;=C2=A0 =C2=A0 =C2=A0/* example of number of bytes in me= ssage */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ProtocolVersion legacy_version = =3D 0x0303;=C2=A0 =C2=A0 /* TLS v1.2 */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Random random;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } ClientHello;
=C2=A0 =C2=A0 }=C2=A0 ClientHelloHandshake

In trying to understand the transcript hash, I read in *TLS **1.3: section = 7*

=C2=A0 =C2=A0 "Note that because the handshake transcript includes the= random values in the Hello messages, any given handshake will have differe= nt traffic secrets"

This gives me a warm fuzzy feeling but *TLS 1.3: section 7.1* states

=C2=A0 =C2=A0 "Messages are the concatenation of the indicated handsha= ke messages, including the handshake message type and length fields, but no= t including record layer headers."

I am guessing that "handshake message" is the ClientHelloHandshak= e I created above and the "record layer headers" is the ClientHel= lo,

I think this is where you are going= wrong. Remember that in order to be serialized on the wire the handshake m= essage is wrapped in a TLSPlaintext structure (and then potentially encrypt= ed). It's those which are the record headers and which are excluded. Wh= at is included is what you are calling ClientHelloHandshake.

=
-Ekr



Does this mean that the transcript-hash just uses the ClientHelloHandshake.= msg_type and ClientHelloHandshake.length highlighted below?

=C2=A0 =C2=A0struct {
*HandshakeType msg_type =3D 0x01; /* handshake type client_hello*/ uint24 l= ength =3D 0x001234; /* example of number of bytes in message */*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ProtocolVersion legacy_version = =3D 0x0303;=C2=A0 =C2=A0 /* TLS v1.2 */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Random random;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } ClientHello;
=C2=A0 =C2=A0 }=C2=A0 ClientHelloHandshake

If so, how does ClientHelloHandshake.ClientHello.random get included i= n the handshake transcript?


<= div>
-Ekr



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114fd3d6909cc7054de8e5c9-- From nobody Mon Apr 24 05:57:49 2017 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 6695B1270A7 for ; Mon, 24 Apr 2017 05:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 iA-Kx6eI9k6X for ; Mon, 24 Apr 2017 05:57:45 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 9D09D13151C for ; Mon, 24 Apr 2017 05:57:39 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id k11so31862680ywb.1 for ; Mon, 24 Apr 2017 05:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=FxK0ESmNqHzi0BttbjYvRl1THSODMm3mILCXRW4itrY=; b=C155KVwuX2zdYw3zk3QATFDjFQJGoZXGvp0v0dBp3ljPod2OaeWhe3KLE07ONlxkUQ wm9EEHmHeJr35VDIuG59fslRHL+4N//Cby9cPjZ+pKjELTDVqJg3FC8kOEVoHXK45Cjo aDkNCZ3lCzY1DN4+c/GblldYMlGfvV/3Khb+/4vUVSbCEyRXuD9xbFSAadNp/TkkrQ4Y l8ePCpXemPw6S1amWxrEY9JHHUg4eoukLt+ZUB7USoeLI8+c+QKzeFJjzKo1QU1VnAzc GS1TI4lJHwMrGeS5MypLoVnXp0Buod3TN/xB8JQQwygqgmi3QNkxddVxG4N5w7zrIaPj 0rxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FxK0ESmNqHzi0BttbjYvRl1THSODMm3mILCXRW4itrY=; b=n9ukDnbpaiAP8i/lUzwjRXN3EogjrG22YnXI2/sz93yLxXSKQtNSHMO1Gxzos928On niyJ2Xx5kO5at8w0/eHzngkBe9DueEgB5vggnRCpE9rqr90qRX1gd6RIHp38Y36JpGc1 Et0z8d5riKKXOLYKn8c4ahiNThWxK6SoYo8GInokzuoD83z11yKDAPh6SQuUrRt9l/Px j5o5otzYrYj05yxJuZrZRvgaS2A+HMVjsnQ4gpORBuPEBDKADlXxNcZy3l+74qxP7Ce/ L0lrHqnt3Eb7BMR5hzSf8CAIbXBipBODQ/Gd1mixGRJ4KDIK4eV/ECgDP0B/Nm12cykb eLpA== X-Gm-Message-State: AN3rC/4Sj6aMkSe7ZfNpD98GJcV6jXLZNT5ek6dEepMoKiHNM8wqnD9Z 4KzCj50WJ2Ed9nAa7GJSyH97Y31UqtcdtC4= X-Received: by 10.129.125.193 with SMTP id y184mr4424869ywc.120.1493038658689; Mon, 24 Apr 2017 05:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 24 Apr 2017 05:56:58 -0700 (PDT) From: Eric Rescorla Date: Mon, 24 Apr 2017 05:56:58 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11492bfce360c5054de92607 Archived-At: Subject: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 12:57:47 -0000 --001a11492bfce360c5054de92607 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/issues/964 Hi folks, It was raised during the WG meeting in Chicago that some of the labels have gotten a bit long and after checking it seems like many of them push us into two hash blocks, which seems silly. Here is a proposed set of new labels, which, while slightly less clear, all fit into the 18 byte limit which Ilari (and I agree) says is what we have. external binder # was external psk binder key resumption binder # was resumption psk binder key client e. traffic # was client early traffic e. exporter master # was early exporter master secret client hs traffic # was client handshake traffic secret server hs traffic # was server handshake traffic secret client app traffic # was client application traffic secret server app traffic # was server application traffic secret exporter master # was exporter master secret resumption # was resumption master secret key # was key iv # was iv finished # was finished traffic key update # was application traffic secret exporter # was exporter Note that this actually pushes us into multiple hash blocks anyway if we compute > 1 output block, but I don't believe that ever happens except for very silly uses of exporters. I would appreciate a double check that haven't accidentally made one >18 or duplicated or something. If anyone has strong opinions about these, please let me know by Wednesday. Otherwise, I'll merge them into the draft. -Ekr --001a11492bfce360c5054de92607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
https://github.com/tlswg/tls13-spec/issues/964

Hi f= olks,

It was raised during the WG meeting in Chica= go that some of the labels have
gotten a bit long and after check= ing it seems like many of them push us into
two hash blocks, whic= h seems silly.

Here is a proposed set of new label= s, which, while slightly less clear, all fit
into the 18 byte lim= it which Ilari (and I agree) says is what we have.

external binder # was external psk binder key
resumption bi= nder # was resumption psk binder key
client e. traffic # was clie= nt early traffic
e. exporter master # was early exporter master s= ecret
client hs traffic # was client handshake traffic secret
server hs traffic # was server handshake traffic secret
cl= ient app traffic # was client application traffic secret
server a= pp traffic # was server application traffic secret
exporter maste= r # was exporter master secret
resumption # was resumption master= secret
key # was key
iv # was iv
finished # = was finished
traffic key update =C2=A0# was application traffic s= ecret
exporter # was exporter

Note= that this actually pushes us into multiple hash blocks anyway if we
compute > 1 output block, but I don't believe that ever happ= ens except
for very silly uses of exporters. I would appreciate a= double check that=C2=A0
haven't accidentally made one >18= or duplicated or something.

If anyone has strong = opinions about these, please let me know by Wednesday.
Otherwise,= I'll merge them into the draft.

-Ekr


--001a11492bfce360c5054de92607-- From nobody Mon Apr 24 06:21:59 2017 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 4D0E21294CE for ; Mon, 24 Apr 2017 06:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 KXLqCb4Xpx5X for ; Mon, 24 Apr 2017 06:21:57 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3453C1294B5 for ; Mon, 24 Apr 2017 06:21:57 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3ODGhar012686; Mon, 24 Apr 2017 14:21:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=MKNG5nsHEfez7wDCqanALVeLwfKXNElV7Kszc5L+wYI=; b=Ma2F2nMoWzfx6ngnhJohaqWUVRLooAHqvx8cprHPY8HIJA/V9yx2csHWMU3uqcjXsNTS fZHTJtk4wz9uymhquIz4rJv0XRA8zk1AAgfQM96R049IirKcA4hKMppqPC7EWcXRGGD9 QiNDShhAw0WlE6jF6myZntTPRdIk8WVwmM+/Q2/pFYSv/M1yN9jqijVPo+lG7oU5BF6l yV3lSoLsS9a39sC2y0HJtO0NZVIuBlZfbN+j8sbs4PBg1HvuJfen5XkgEVSv1Csfht9e P37NyF2GWwwPysPJjHaY2OK2dlxCMY2k+1WGTmuM0fz7hVdCM83mUvUNQztBfvKOxsXJ Ow== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 29yv8b3a9b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2017 14:21:54 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3ODLEFP018685; Mon, 24 Apr 2017 09:21:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a02gvjdjc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2017 09:21:53 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Apr 2017 09:21:52 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 24 Apr 2017 09:21:52 -0400 From: "Salz, Rich" To: Brian Smith , Ryan Sleevi CC: "tls@ietf.org" Thread-Topic: [TLS] comments on draft-ietf-tls-tls13-19 Thread-Index: AQHSqJjSCranHeW0Kkim8uZ5ZLnDdaGsJHyAgBTntQCAD0N5gIABYGgAgAABzoCAAKKPAIAASFmAgAH7pACAABGIgA== Date: Mon, 24 Apr 2017 13:21:52 +0000 Message-ID: <839a775972954f5ba56f251b53e1feed@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.168] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-24_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704240235 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-24_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704240234 Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 13:21:58 -0000 PiBUaGUgVExTIDEuMyBzcGVjaWZpY2F0aW9uIGlzbid0IHRoZSByaWdodCBwbGFjZSB0byBzcGVj aWZ5IHdoYXQgdG8gZG8gd2l0aCBPQ1NQIHJlc3BvbnNlcyB0aGF0IGRvIG5vdCBoYXZlIGEgbmV4 dFVwZGF0ZSBmaWVsZC4NCg0KV2hlbiBwaHJhc2VkIGxpa2UgdGhpcywgaXQgc2VlbXMgY29tcGxl dGVseSBvYnZpb3VzIHRvIG1lIHRoYXQgdGhpcyBjb3JyZWN0Lg0K From nobody Mon Apr 24 06:26:34 2017 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 1468113151C for ; Mon, 24 Apr 2017 06:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 1QYh6Q1qpVZ4 for ; Mon, 24 Apr 2017 06:26:31 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A2413151B for ; Mon, 24 Apr 2017 06:26:31 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 92C39A00491C for ; Mon, 24 Apr 2017 06:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=tq46SPy3ACOxmGFWwFl36HU9+t4=; b= m/FYh9wCUrosZXYYjTU40ma/58FB/eamxVTZVymBvzj1GO0BUjgNYjC3QOd+VL3y VaRbaDdoKfcMFa1Zio80fe3vjX7EenrIumN2ddJO0+8H4S6A06IWN6A5TxfiP+6q Uu/Eogs5froD/ox33hcmTowg4E6hLbmmAhzFCQoYeLE= Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 5B654A00491B for ; Mon, 24 Apr 2017 06:26:30 -0700 (PDT) Received: by mail-lf0-f43.google.com with SMTP id 88so73807755lfr.0 for ; Mon, 24 Apr 2017 06:26:30 -0700 (PDT) X-Gm-Message-State: AN3rC/7oA978enMVuCaj4F/TFbchb0E/Yf6aK+eaEZfgJ7GBxkKvR4ai B+GJ6FX2quPwhRsD04PqqyRBbUnWZQ== X-Received: by 10.46.21.19 with SMTP id s19mr1217427ljd.47.1493040388551; Mon, 24 Apr 2017 06:26:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.165.67 with HTTP; Mon, 24 Apr 2017 06:26:27 -0700 (PDT) In-Reply-To: <1493020692.3390.8.camel@redhat.com> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> <1493020692.3390.8.camel@redhat.com> From: Ryan Sleevi Date: Mon, 24 Apr 2017 09:26:27 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Nikos Mavrogiannopoulos Cc: Ryan Sleevi , Ilari Liusvaara , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1cda70febec2054de98dda Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 13:26:33 -0000 --94eb2c1cda70febec2054de98dda Content-Type: text/plain; charset=UTF-8 On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos wrote: > > That's intentional. And misguided. It violates the layering. > Not every application is firefox or chrome and thus > application writers cannot be expected to set sane defaults for OCSP > validity time _when the nextUpdate field is missing_. Not every TLS implementation should be required to process the PKI. > The reason they > cannot be expected to do that, is that it is not by way obvious what to > do. Ilari's implentation closes the connection, mine sets a limit of 15 > days, and I guess each and every other one behaves differently. It is > the role of the standards to clarify uncertainties for implementers or > forbid such options (I'd equally be happy if we have a text that > forbids an empty nextUpdate field in OCSP responses to be used in the > context of TLS 1.3 ocsp stapling). > Can you point to where the spec supports your behaviours? That is, where it's a valid reading of the spec to close the connection or to set a limit of 15 days. The point is that it's not a valid reading of the spec. It is, instead, an application profile. And that's great. I don't think anyone would realistically be arguing that applications or other specifications cannot profile the spec to their needs. While I remain unconvinced that TLS is the right thing, what you're describing here is simply a decision you've made for your community. That doesn't mean that because you and Ilari have made different decisions, that should be imposed on the spec. > > Given that stapling "issues" exist even without stapling, it does > > seem an unnecessary reach to include within the spec. > > There is a usability and interoperability issue there. Not within the spec. Within the profile you've done for your community. > Given that there > is no common interpretation of what the missing nextUpdate field means > in terms of validity, there some equally valid interpretations: > 1. the response is invalid for use in TLS 1.3 > That's not an equally valid interpretation. A missing nextUpdate is defined in the relevant OCSP specs. > 2. the response is valid for a limited amount of time 1, 7, 8, 9, 15 > days > That's not an equally valid interpretation. A missing nextUpdate is defined in the relevant OCSP specs. > 3. the response is valid for an unlimited amount of time (which raises > the question of why staple at all in that case?) > A missing nextU... you get the idea. --94eb2c1cda70febec2054de98dda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos <nmav@redhat.co= m> wrote:
=
That's intentional.

And misguid= ed. It violates the layering.
=C2=A0
Not every application is firefox or chrome and thus
application writers cannot be expected to set sane defaults for OCSP
validity time _when the nextUpdate field is missing_.
Not every TLS implementation should be required to process the = PKI.=C2=A0
=C2=A0
The reason = they
cannot be expected to do that, is that it is not by way obvious what to
do. Ilari's implentation closes the connection, mine sets a limit of 15=
days, and I guess each and every other one behaves differently. It is
the role of the standards to clarify uncertainties for implementers or
forbid such options (I'd equally be happy if we have a text that
forbids an empty nextUpdate field in OCSP responses to be used in the
context of TLS 1.3 ocsp stapling).

Can = you point to where the spec supports your behaviours? That is, where it'= ;s a valid reading of the spec to close the connection or to set a limit of= 15 days.

The point is that it's not a valid r= eading of the spec. It is, instead, an application profile. And that's = great. I don't think anyone would realistically be arguing that applica= tions or other specifications cannot profile the spec to their needs. While= I remain unconvinced that TLS is the right thing, what you're describi= ng here is simply a decision you've made for your community. That doesn= 't mean that because you and Ilari have made different decisions, that = should be imposed on the spec.
=C2=A0
>=C2=A0 Given that stapling "issues" exist even without stapli= ng, it does
> seem an unnecessary reach to include within the spec.

There is a usability and interoperability issue there.
=

Not within the spec. Within the profile you've done= for your community.
=C2=A0
G= iven that there
is no common interpretation of what the missing nextUpdate field means
in terms of validity, there some equally valid interpretations:
=C2=A01. the response is invalid for use in TLS 1.3
That's not an equally valid interpretation. A missing next= Update is defined in the relevant OCSP specs.
=C2=A0
=C2=A02. the response is valid for a limited amount of time 1, 7, 8, 9, 15<= br> days

That's not an equally valid in= terpretation. A missing nextUpdate is defined in the relevant OCSP specs.
=C2=A0
=C2=A03. the response is valid for an unlimited amount of time (which raise= s
=C2=A0the question of why staple at all in that case?)

A missing nextU... you get the idea.


--94eb2c1cda70febec2054de98dda-- From nobody Mon Apr 24 08:24:34 2017 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 2B09D131675 for ; Mon, 24 Apr 2017 08:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 nEgSd3xBdyEJ for ; Mon, 24 Apr 2017 08:24:28 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id BC80F131699 for ; Mon, 24 Apr 2017 08:24:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 38EB8247E7; Mon, 24 Apr 2017 18:24:25 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id ujhniHGk2ci8; Mon, 24 Apr 2017 18:24:24 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id B5FD521C; Mon, 24 Apr 2017 18:24:24 +0300 (EEST) Date: Mon, 24 Apr 2017 18:24:22 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170424152422.GA18543@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 15:24:31 -0000 On Mon, Apr 24, 2017 at 05:56:58AM -0700, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/964 > > Here is a proposed set of new labels, which, while slightly less clear, all > fit > into the 18 byte limit which Ilari (and I agree) says is what we have. Doing a santiy check... > external binder # was external psk binder key > resumption binder # was resumption psk binder key > client e. traffic # was client early traffic Isn't the previous label "client early traffic secret"? > e. exporter master # was early exporter master secret > client hs traffic # was client handshake traffic secret > server hs traffic # was server handshake traffic secret > client app traffic # was client application traffic secret > server app traffic # was server application traffic secret > exporter master # was exporter master secret > resumption # was resumption master secret > key # was key > iv # was iv > finished # was finished > traffic key update # was application traffic secret > exporter # was exporter Seems to be missing: derived secret # was derived secret All look to fit into 18 bytes and none seem to be duplicated. -Ilari From nobody Mon Apr 24 08:29:23 2017 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 861971316D7 for ; Mon, 24 Apr 2017 08:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 LmqiS7tlGxxE for ; Mon, 24 Apr 2017 08:29:16 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 DDE671316CB for ; Mon, 24 Apr 2017 08:29:15 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id k11so35930094ywb.1 for ; Mon, 24 Apr 2017 08:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q+uRUd3HvykD4eQGpukVu/vksyh7TqCqU+rFJxJggKw=; b=0KSNu33/wjPZodY3RpcbXBHCSJSWEX8TivNGlFK1ipbbNhRSeKIS1cL6qMhKVKzj3b Q3JFYkHXxYW4yiADiEn/61ZyzN/Ry3nPnIWLTwqJz7BNjGHsquGMMwlYbDp0HTqx7Ot4 LqmzLUUbLRFBvqJfFiMUMtMZiIsLMQJqOH7ntWDABxib9nY3Pb/IsxA9hhKZBuw5aa5S 7McERtPF6M9FOjsgwinUa6Wieryeb2KrJGsLo+j1QXskvmCT7wolUDQ55oguzdYsRNS1 FqTtRPsFHWcnDu9YdDSamiCJyQLJJzfrk1O7omPNJP5Fcj0C7/GQBVvyT9w5E2A5990m mpJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q+uRUd3HvykD4eQGpukVu/vksyh7TqCqU+rFJxJggKw=; b=cUlLf877vCnb8Xaixw8jcMvHQsL86Bt+5aWiKD+fVHT4A+r1xgjx79jEBhG7MdcHB6 hwUD1trOlow2gWhZmsgZ4nnKzgE9oKP5XUpvGH0SQtRR0xgLwD+JbsqFQZ6U3bEdDHG2 CLt/7KBlFxFdRz7yLo1KXFElXK+/1mxA16CBIMpqrVzfF5hm21rPoKRcGSGPPhBuKFb6 5GNrx8cIrHquVbAat3IE3gDia0y0j1SsAvyY2UddDeCvejceoFWK96DdFslFJykTZTQ9 gOL3SxbI3oJYnimoNr4tDAYoltinUVSwWx8Hf+I4rlEMShwWQVdZY6cS8mcOLEqxzS0g SMOA== X-Gm-Message-State: AN3rC/5e8XzQaweOP0jO+xh/tZlcXZdm2xNkofi+KPf9PoPX2OInaqXV S7tZc6iESLYKx2372yKgsxjJwIuPbAmt X-Received: by 10.129.167.3 with SMTP id e3mr5691396ywh.327.1493047754127; Mon, 24 Apr 2017 08:29:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 24 Apr 2017 08:28:33 -0700 (PDT) In-Reply-To: <20170424152422.GA18543@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170424152422.GA18543@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 24 Apr 2017 08:28:33 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1461f20485a9054deb452e Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 15:29:19 -0000 --94eb2c1461f20485a9054deb452e Content-Type: text/plain; charset=UTF-8 On Mon, Apr 24, 2017 at 8:24 AM, Ilari Liusvaara wrote: > On Mon, Apr 24, 2017 at 05:56:58AM -0700, Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/issues/964 > > > > Here is a proposed set of new labels, which, while slightly less clear, > all > > fit > > into the 18 byte limit which Ilari (and I agree) says is what we have. > > Doing a santiy check... > > > external binder # was external psk binder key > > resumption binder # was resumption psk binder key > > client e. traffic # was client early traffic > > Isn't the previous label "client early traffic secret"? > Oops. Yeah, search and replace fail. > e. exporter master # was early exporter master secret > > client hs traffic # was client handshake traffic secret > > server hs traffic # was server handshake traffic secret > > client app traffic # was client application traffic secret > > server app traffic # was server application traffic secret > > exporter master # was exporter master secret > > resumption # was resumption master secret > > key # was key > > iv # was iv > > finished # was finished > > traffic key update # was application traffic secret > > exporter # was exporter > > Seems to be missing: > > derived secret # was derived secret > Yep. This one we can keep. Thans, -Ekr > > All look to fit into 18 bytes and none seem to be duplicated. > > > -Ilari > --94eb2c1461f20485a9054deb452e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 24, 2017 at 8:24 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Mon,= Apr 24, 2017 at 05:56:58AM -0700, Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/issues/9= 64
>
> Here is a proposed set of new labels, which, while slightly less clear= , all
> fit
> into the 18 byte limit which Ilari (and I agree) says is what we have.=

Doing a santiy check...

> external binder # was external psk binder key
> resumption binder # was resumption psk binder key
> client e. traffic # was client early traffic

Isn't the previous label "client early traffic secret"= ?

Oops. Yeah, search and replace fail.<= /div>



> e. exporter master # was early exporter master secret
> client hs traffic # was client handshake traffic secret
> server hs traffic # was server handshake traffic secret
> client app traffic # was client application traffic secret
> server app traffic # was server application traffic secret
> exporter master # was exporter master secret
> resumption # was resumption master secret
> key # was key
> iv # was iv
> finished # was finished
> traffic key update=C2=A0 # was application traffic secret
> exporter # was exporter

Seems to be missing:

derived secret # was derived secret

Yep= . This one we can keep.

Thans,
-Ekr
=C2=A0

All look to fit into 18 bytes and none seem to be duplicated.


-Ilari

--94eb2c1461f20485a9054deb452e-- From nobody Mon Apr 24 08:39:47 2017 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 17F4D13173B for ; Mon, 24 Apr 2017 08:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 AOfIWHfzua8u for ; Mon, 24 Apr 2017 08:39:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 0E97F1316F9 for ; Mon, 24 Apr 2017 08:39:43 -0700 (PDT) Received: from [192.168.91.191] ([195.149.223.176]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LyWAQ-1bxFoR0j14-015s1s; Mon, 24 Apr 2017 17:39:41 +0200 To: Ilari Liusvaara References: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> Cc: "" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Mon, 24 Apr 2017 17:39:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PVjpU3JKWiE4rafBxRLcSAbhdgN7uQ9Jm" X-Provags-ID: V03:K0:dyhnJ8MlbOlmbG5l2KwCmvKx79J3XLe8bGcaGcjVh5CeIaoCKvp PNCYoqVyPmyDotQdRg+J++W6H6vX4uLWgkmdNxOcwNHLR7ycRswFM/GzydF7U2/WFxInsIF EiXwHJoBNVvcMfpdIScV/rooqDEKCtPKY5pISH+k1jGKFKUSUgH6uwIuKb7Xh4jg41bCC4o NxwGHtJGO1C9pwyRDepag== X-UI-Out-Filterresults: notjunk:1;V01:K0:tNwBH4VnQVQ=:cH27cwUKt0ecadaEkSfTAk n9dCMeDng5SPlyUhxk0CSxV/nqEHmKKJswG9CAHjhV8fhFA52BKiCkRaI9sRvE2YMOQRpu2B9 YuLYDn4pxGG4I3TnzOmjoXePXXGOxcqMD96CNRHMxdwKNvRSa9uoQvOMfDyPKVK0LQ30ciD2U cC5p8k3T6nsex37kt1CpogOJijQfnbRm61XLTmVMX4BWWwHyQzPzzHZ1BRR59CZ9LhCZlwj/0 f+fgnLXxItlWipqLDsw824t6t65QNtfVLcDmpBqnpaCMh95iNXoyB63Xwkh9hR5u4XNjLRU8I Kppp4PrDqmFpr+1RKWvFEzOyKCuYM6qaheAQ8npQs3734hPiVCvWxegJszioc7W4dlcSThc3e fNFpu6nFoYL9T3HYuKgwnj7FMxqjQcSaOgUnR6rPASo3fogKYEN9zb/LMqk1uE9krZ9J2PfAA sjbWBX3yXR/fsg2yDd8G7cDsiBvBDWfxYnnkCuRZz/+oM+e0HEgHrKngwKnTiq65zFsiyGCYT sFzn/mnuja7jZXy31BCZCcC7d7Rutl5j9KCeFt/zisapNBSv8CElvB88REEtqRt9GPeBddnRb yLTmbOB+riejSul0xZjYkHsevdUWbZgS/onlUs6JlKd5m+dt/98NH09L9F3KtHsCVRk4q7acQ 1BGSDNKOxyQPNj7Zs971Zi5nFtBIOVa11zPnIxHVQdwmX+Ll6Tho2Ft/GHDj0+e8yWYMmnDMF +Rt/swyRT3Uz1nbNFjZFPd0/9e7VCvG+C5S30Pa1wl7zOCOWm9iFLMaTMLY= Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 15:39:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PVjpU3JKWiE4rafBxRLcSAbhdgN7uQ9Jm Content-Type: multipart/mixed; boundary="4ldtthqGGik7gTo5o0r1LDvTalEkLrdFl"; protected-headers="v1" From: Hannes Tschofenig To: Ilari Liusvaara Cc: "" Message-ID: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 References: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> --4ldtthqGGik7gTo5o0r1LDvTalEkLrdFl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ilari, thanks for your response. A few remarks inline: On 04/21/2017 12:48 PM, Ilari Liusvaara wrote: > On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote: >> I read through draft-rescorla-tls-subcerts-01 and I ran into some basi= c >> questions. >> >> I have been wondering why the TLS server operator obtains an end-entit= y >> certificate from a CA (which cannot be used to sign further >> certificates) instead of running an intermediate CA him-/herself >> instead. This would work without requiring any changes to the client >> side. The proposed solution, although technically feasible, will >> unfortunately take a long time to deploy since it requires cooperation= >> from clients, servers, and also from CAs. >=20 > There is enormous amount of red tape obtaining intermediates, even > technically constrained ones. And as consequence, it is enormously > expensive (through not nearly as expensive as public CA). In essence you are doing this through the extension as well just using a different format. >=20 > Defining new extensions is much more deployable, as slow as it is > (AFAICT, no BR changes needed). I hope that this is true since otherwise you have just traded one problem against the other one. >=20 > Regarding clients, I think the draft specifies LURK as backup plan > for clients that don't support subcerts (which causes some extra > latency if triggered). I didn't got that impression. >=20 >> What is also not clear to my why some of the certificate management >> protocols, which provide the necessary level of automation, cannot be >> used with CAs to request short-lived certificates. >=20 > AFAIK, that would cause issues with CT and OCSP signing. >=20 > The latter would be fixable by reintroducing CABForum ballot 153 and > passing it (the reasons 153 failed were obviously political instead of > technical). Isn't this something ACME was trying to solve as well? Ciao Hannes >=20 >=20 > -Ilari >=20 --4ldtthqGGik7gTo5o0r1LDvTalEkLrdFl-- --PVjpU3JKWiE4rafBxRLcSAbhdgN7uQ9Jm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY/hw8AAoJEGhJURNOOiAti/wH/3FZMRneLuJmvYf4u9Mz2DNO dhi8AFKUiKBctCvyn8VLdVcyTpS57vsfffsRWSKCWOTUmDSL/NgQdQginIpUuAUN WDVskhfchUiMGnsb1atVtOjfEDrgadyBzx2IfP0K37IJea2C+Zo0LHrExfLLJ/q+ mOhM9heIUDJpci8DVp6yuS51U05BCfgoCK/WX1MkEQH7n64gHU4dWrm6TATNizIN znO2O7hzIUpvrmy4Ybevfa8UFg7XNxF5KPkpWaYBbkHk475qcZHnjJ9dUUik8nf4 MztQSqjZseDa9LY9AoEkTSQpZS9c86n9LMT991th5LXco7quYoJK8xesSOeepFg= =Ze3G -----END PGP SIGNATURE----- --PVjpU3JKWiE4rafBxRLcSAbhdgN7uQ9Jm-- From nobody Mon Apr 24 08:42:17 2017 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 C36CF131708 for ; Mon, 24 Apr 2017 08:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.901 X-Spam-Level: X-Spam-Status: No, score=-4.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 sUWGhYg8ib-2 for ; Mon, 24 Apr 2017 08:42:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 688751316B1 for ; Mon, 24 Apr 2017 08:42:13 -0700 (PDT) Received: from [192.168.91.191] ([195.149.223.176]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M9ra4-1crhmM0ZJ2-00B0zL; Mon, 24 Apr 2017 17:42:10 +0200 To: Ilari Liusvaara References: <55e7544b-808a-5e0e-f66e-3a6f4a79e218@gmx.net> <20170421105213.GB20822@LK-Perkele-V2.elisa-laajakaista.fi> Cc: "" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Mon, 24 Apr 2017 17:42:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170421105213.GB20822@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mQxpMe1PDAiDiBgS2tOAV8pMbwIJSPMSO" X-Provags-ID: V03:K0:WLCqfdMndwyp0e8+bX0zSJX0ZZ9ZuHxCBobXXPeQzHwjcOPqGOI 1OzABOWMgLLoaVLa2ZpRy4uzlkTbuTI5+/f/AE/fBGalteah+F+VHQCXa9PoQ8AiSRRxplQ m83B275fND2CH9dN2C9ftQuT/e5kbICw2HzeKYRFWdMYs6ascRl6ehHEkczbRIu0uW+ucdA 0osUJ9rP1jTbKOpmzxbfA== X-UI-Out-Filterresults: notjunk:1;V01:K0:EX0ULoG3TMA=:kJXVPEOszzJqeBx58TBu3i dh1bcgMGFi49UF1gLgntLX1f62ePDCL8uosNlBL5lWhbY8/CZwBKBrGB3uxtL5NnR0sFK6SuB i+IDwku9N+79PooKaage/LoY9m881dxI9P6cogBQ9WbiYGnTqfkbOVSwJe1Ed0GAjnGK5w5C+ ESHSou1TTJpTNjCp4joRGJD8h8WnupGQ8Dh8SZO9NdrRuxxRRznXT01wWfbHGwOyAWcF8gtJm jdRiu+/44EiX475DrHNfD6BfAIf9q3/YpijqqCPhye6u+HMd+eHojoac4VpDZBMzQrMYU9dfC Wkz3OQffnoCoueLUMZP9572RX0ciM6P38igJUY1PtbTC8llMr1sl3VUb+z4ex5jixxdz3iXit bacb7OgUA6sOweGxQep2qZ9P/pvL8pQhi3459IoNFeEPIqPjtLiRV0OWJ48FVDzWfDuFRzXEr Q6An3mLdf/WEEwBRLInYq/hqx74GXXkg2SZ0fd+WOgpFbqafF5F1ZFQGeTr5uJULLRRCdRN+f c+Ko1ZAEVN32Ffp097IPYjLfy1vmkFIBxsGIoY54/NLvBXICx94tQxGfWPDeibyiNKkDVUNpy sPI54VeSSjuT8X5w2k1cZD1LYrmzY7QSwVd8dGd0chfTQsWBMio9+ccLwWFAhXC6MJCQNncvx dVv9vOUqYjxYdVcVF1oUTmHFoVn99yncDZP79iYgX0Zy3XvGj8uPlZr+g9k37hFpxgcZNWs69 0pvxYvV8K03iV8vFLp83wwVyo6oHZh306TzGtbo+vLxRjd2XTX9ySD+k8Bk= Archived-At: Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 15:42:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mQxpMe1PDAiDiBgS2tOAV8pMbwIJSPMSO Content-Type: multipart/mixed; boundary="Kf7d0u4lJfO8TFdX8kVk5AnvF8gP493kf"; protected-headers="v1" From: Hannes Tschofenig To: Ilari Liusvaara Cc: "" Message-ID: Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-01 References: <55e7544b-808a-5e0e-f66e-3a6f4a79e218@gmx.net> <20170421105213.GB20822@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170421105213.GB20822@LK-Perkele-V2.elisa-laajakaista.fi> --Kf7d0u4lJfO8TFdX8kVk5AnvF8gP493kf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ilari, thanks for your feedback. Remarks inline: On 04/21/2017 12:52 PM, Ilari Liusvaara wrote: > On Fri, Apr 21, 2017 at 10:44:01AM +0200, Hannes Tschofenig wrote: >> I have read draft-sullivan-tls-exported-authenticator-01 and have a fe= w >> questions. I haven't followed this work previously but have been >> wondering whether this functionality would be useful for "me". >> >> The described functionality sounds like post-handshake authentication >> from TLS 1.3 (although it does not use that term throughout the >> document). I would have thought that this functionality is a replaceme= nt >> to the TLS 1.2 renegotiation but then there is also the TLS 1.3 conten= t >> in there which raises the question about how this relates to the >> post-handshake authentication functionality. >=20 > There are two things that can't be accomplished with PHA: >=20 > - Authenticating the server for more identities. > - Transmitting application context with the certificate. >=20 > TLS 1.2 renegotiation also is incapable of either of those. In what situations would I want those features? The draft is rather brief on the motivational side. > =20 >> What does the following sentence mean and what is the use case for it?= >> >> " >> This proof of authentication can >> be exported and transmitted out of band from one party to be >> validated by the other party. >> " >> Who are the parties? >=20 > Most probably TLS client and server. Maybe the draft should say that. Ciao Hannes >=20 >=20 > -Ilari >=20 --Kf7d0u4lJfO8TFdX8kVk5AnvF8gP493kf-- --mQxpMe1PDAiDiBgS2tOAV8pMbwIJSPMSO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY/hzRAAoJEGhJURNOOiAtQ1EH/RpM/Jh43Bf4hxPWzQtSDyZm RaAdBZh77IYU5YuELpRAq4r14hCiVtdkuS/jW2tx+vOwYpUFfX76d5ZJepmXVRwB jFi/VCwY77F+EgfHTI+cKvdTdJ1cl6QNlwFLuYHZivuOXGrqimU7yELyu99OwWeF 0kZx17SG+xETTCTNvLTbzcPGNVD5ptYxOHSnOtl62iSnk2w6vOZb8b9F6vZkPP8N DUTMioyXSJr8Q3HigvWMGd/P04FuX7QhiGMDjLhZn9Jf6FVt9sFpmiQPqU5QxtmF QI2HVq2wXH2x6gpkxtyvZG9umCZ+GzwWvGxshf2WhMYiggMx5ENucpXA6AbCtXM= =6JDM -----END PGP SIGNATURE----- --mQxpMe1PDAiDiBgS2tOAV8pMbwIJSPMSO-- From nobody Mon Apr 24 08:52:59 2017 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 4A218131744 for ; Mon, 24 Apr 2017 08:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.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 cjBc1nlR3yxx for ; Mon, 24 Apr 2017 08:52:56 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 E3643131746 for ; Mon, 24 Apr 2017 08:52:49 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id g2so14990430pge.3 for ; Mon, 24 Apr 2017 08:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=EaMAkycvl70h4dIDMYLZZVBEzJaW3OtjKlepDooSSxA=; b=PlCb+VcQ/mVOd73V5qxPZrdzwtRX3H+ymEtxefsIgVYyZJ1GCX3C3PpYLgSjdsCy/2 KEKlbpcv6Zr3++25GZHdckktu4iEdKQIzumcWnM0sgEFg6OSH52VVohDGubjkhXGE8fG boH7iBQ5994ekYistlbHVi1+TrXQpbW3KPjV4AlwGDKx6Gwn8qSs3og1vZKCkWKxrjXH ApvBKkOQYONVgxHxmRaDpSCfYhYese2G+0odS/oczapyCgxBMgc39Vqb0QNhjUXoJjYl t6UwBR8Cr4Vj1GTAR/iqtVHVSzSAfPynkjqWrT4WN/sAYjef3lCmv1nMeaI6Ptq/lcjD jeFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=EaMAkycvl70h4dIDMYLZZVBEzJaW3OtjKlepDooSSxA=; b=IM42pZKYxyR5kKPF1X5D3PJlJGUU5aIdwuS1qOd1a0d3g6ela6TLrtAiLhi4AHFhzy riixoK4x9i3sezlMGWA3Lk6u7eEnSvSLNOlx+g8NaHXt2qZQbKrk1otFs0/Ga6GikvAV sc3lsUh3I5XRQKbYhZZ8Ut6VLAP0HqFN+yyZLgBHA1uoD7fY1Vi6wmUXqmriVnNcuhnw mWRUvi7tp0KjHsSqGh0d3Rq7oJtSbyQKa/0hlbOxliJedl69OTU9Aq1d8nXy1wUmr9Bd zVBvyYys/1fmedyQPa+An1RfDxzsOYO/TPWRb1iJDBGLEZp3flvXSvNZnarhHHhq1yQL CKhg== X-Gm-Message-State: AN3rC/65e6kDeH4MdXZKIYjMpiFTc2MHRbwmp3PGMINm//ukTHgLu3WW a7LJfv6o3oMnIAZYH40= X-Received: by 10.98.57.146 with SMTP id u18mr26191641pfj.9.1493049169274; Mon, 24 Apr 2017 08:52:49 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (63-140-90-74-radius.dynamic.acsalaska.net. [63.140.90.74]) by smtp.gmail.com with ESMTPSA id 66sm31717562pfg.14.2017.04.24.08.52.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 08:52:48 -0700 (PDT) To: tls@ietf.org References: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> From: Melinda Shore Message-ID: Date: Mon, 24 Apr 2017 07:52:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MsUSBJlPW7rWPlqcLRtdNNxBbRmbSHrNP" Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 15:52:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MsUSBJlPW7rWPlqcLRtdNNxBbRmbSHrNP Content-Type: multipart/mixed; boundary="qTwVBqwQhii6aqKfjflfbtkp7ksTNEo7o"; protected-headers="v1" From: Melinda Shore To: tls@ietf.org Message-ID: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 References: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: --qTwVBqwQhii6aqKfjflfbtkp7ksTNEo7o Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/24/17 7:39 AM, Hannes Tschofenig wrote: >> There is enormous amount of red tape obtaining intermediates, even >> technically constrained ones. And as consequence, it is enormously >> expensive (through not nearly as expensive as public CA). > In essence you are doing this through the extension as well just using = a > different format. In some sense the proposal is about having a trusted issuer who's not included in public trust stores, which is a reasonable goal (there's a fantastic amount of work, including external audits, in having your intermediate included in browser trust stores, etc.). We haven't had a good delegation story since, like, ever, but now there's a somewhat compelling use case (CDNs) that needs attention and will benefit from a solution. Melinda --qTwVBqwQhii6aqKfjflfbtkp7ksTNEo7o-- --MsUSBJlPW7rWPlqcLRtdNNxBbRmbSHrNP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY/h9PAAoJELiGRpM6HoEu+M0QAKo222ae+GkhTtKZAtOxM3SM rVa3a1vrnUpfGPNLzxD05GrJ3qMRV8FHRq+MO/d4GsrW7OSmuJ5an8O26sX6WPx1 WYuZ9g5fVaPF06aPmC790cCuuwq5F3xzxVL1Mc8p6MRkzUq0fuxeBy5Qhf+Na2fj NcpNOkKMSVLGErXiYVfKb2XocKGs50z7hp0UuWswmqDdOUEXhDDa9WiEVzgnnD2t 4zS/D0EyvFDPxT9CPxbFjLRWzw75n1dG87yIX1hjm6ASr4ibRnOPF9nb9Gm7Jz58 1vv7GE4x+SXUww9a3gzd2N3ifcpN4RNA4ulZIudw2oeIkxoe9bVAawhtl6J3WtbZ ZgT4dGvsU0Qy2eGtzCDq1ldwx1nQMv87DHDWPLPO/CeD6sN00u9Gs2c1vJYw5Ysm dL7c1X2JJVOjUJhJidj7jz10VYOgVP6dbcMS+rNUy3L0TOvek/+tL+bK6LK2a+HZ zMPL653p8mLxfJa8Ekkr442HR97aO74zx6G5VIwaU+aSec0Tladuy0stjH1fCBBx c+v884DLUdzxtjV41d3d6fBTV7IfzaPw1VrOffuw/RjvCJGLLjdC7ZGAPchCJgQD MpAlAIOotdn7CuR3MXtBWzBRe/x33ApsSbHBz+t/3Co7OUIuI8/W+Tj6qW++CUfz Nd3qhI9tzuVdtJsmpvMV =hvpO -----END PGP SIGNATURE----- --MsUSBJlPW7rWPlqcLRtdNNxBbRmbSHrNP-- From nobody Mon Apr 24 09:05:17 2017 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 6ED3C1317B7 for ; Mon, 24 Apr 2017 09:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 ss5427P0cCig for ; Mon, 24 Apr 2017 09:05:14 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1721242EA for ; Mon, 24 Apr 2017 09:05:14 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3OG1hO4021711; Mon, 24 Apr 2017 17:05:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=/1QwFs7w+SCooo2ZyzcXvB9wF+HihpuemEIiY73n+pA=; b=YbzQ6y2niRntJEZkco16yjRP1kGIehiiiJLnBYEx/pt5C044EoczcIxxjQEYLIrjJ/Po GEq/94UgOiVZr4ug0FfqmhkxhMU+91XtVAlnOe9ugm4hW82bIcbD98NdrkpV1+NeETkE XeQf2l26Ghq2pfFdFhj66eZhPyVeVIPiAJZMEKlm0syne9C9pZTiMs0B53CwrlHIFKvg +IFhT7IoAZlPuecWHtSIu51RlZIOTljjL2EGnmUFzFMRXsZuc74jsVSCSX/2A/zs/r3l jb6Y9J0C70sr6bJe4RWpNrC0QAo6cdPav0am1lUx06r8tlfRxVdXXWYlTRXf9jI0ix1o 7g== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 29yxq4vtcs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2017 17:05:11 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3OG0oCO013745; Mon, 24 Apr 2017 12:05:10 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a02gvjq59-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2017 12:05:10 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Apr 2017 12:05:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 24 Apr 2017 12:05:06 -0400 From: "Salz, Rich" To: Melinda Shore , "tls@ietf.org" Thread-Topic: [TLS] draft-rescorla-tls-subcerts-01 Thread-Index: AQHSunqGQj5aZlGSNUq3e1Ek/6MTFKHP59mAgAUIN4CAAAOrAP//wA9g Date: Mon, 24 Apr 2017 16:05:06 +0000 Message-ID: <9a2ffbcc768444f9a38d317c4cca1bb3@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.5] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-24_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704240274 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-24_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704240275 Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 16:05:16 -0000 > included in browser trust stores, etc.). We haven't had a good delegatio= n > story since, like, ever, but now there's a somewhat compelling use case > (CDNs) that needs attention and will benefit from a solution. Emphasis on the somewhat. =20 From nobody Mon Apr 24 09:16:28 2017 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 66D2B1317C7 for ; Mon, 24 Apr 2017 09:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 GOQNgaxf5G1q for ; Mon, 24 Apr 2017 09:16:23 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id D27CE131752 for ; Mon, 24 Apr 2017 09:16:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5DB7125262; Mon, 24 Apr 2017 19:16:21 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id LlGaEMBIcdwc; Mon, 24 Apr 2017 19:16:21 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EF09A2317; Mon, 24 Apr 2017 19:16:20 +0300 (EEST) Date: Mon, 24 Apr 2017 19:16:19 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170424161619.GA18783@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170424152422.GA18543@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 16:16:25 -0000 On Mon, Apr 24, 2017 at 08:28:33AM -0700, Eric Rescorla wrote: > On Mon, Apr 24, 2017 at 8:24 AM, Ilari Liusvaara > wrote: > > > On Mon, Apr 24, 2017 at 05:56:58AM -0700, Eric Rescorla wrote: > > > https://github.com/tlswg/tls13-spec/issues/964 > > > > > > Here is a proposed set of new labels, which, while slightly less clear, > > all > > > fit > > > into the 18 byte limit which Ilari (and I agree) says is what we have. Aargh, turns out that Merke-Damgård strengthening probably affects things... For SHA-256, MD strengthening consists of padding bit and 64-bit message bit count, for total of 65-512 bits of padding. Trying to construct the raw SHA-256 message words for inner hash with 9 byte label (K is key, L is label, H is hash). KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK 36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636 00201254 4C532031 2E332C20 LLLLLLLL LLLLLLLL LL20HHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHH0180 00000000 000003B8 Adding 10th byte to label seems to blow the block (0x3C0=1*512+448): KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK 36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636 00201354 4C532031 2E332C20 LLLLLLLL LLLLLLLL LLLL20HH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHH01 80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000003C0 For comparision, with SHA-384, the blocks for 9-byte label seem to be: KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK 3636363636363636 3636363636363636 3636363636363636 3636363636363636 3636363636363636 3636363636363636 3636363636363636 3636363636363636 3636363636363636 3636363636363636 003012544C532031 2E332C20LLLLLLLL LLLLLLLLLL30HHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHH0180 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000638 (Which has 327 hash block padding bits). -Ilari From nobody Mon Apr 24 09:28:43 2017 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 9960A1317FF for ; Mon, 24 Apr 2017 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 sGyGFCphY379 for ; Mon, 24 Apr 2017 09:28:39 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 F40601317FE for ; Mon, 24 Apr 2017 09:28:34 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id k11so37168825ywb.1 for ; Mon, 24 Apr 2017 09:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q8OrJgVFMNtiu6I+aQ5VJdWj3+KcVV9oDj7tFS/SYnM=; b=j9nXssdicrdCzSht65dhX/afJyij2Jv0y/m+iNrqDWo93V1+76q1qPIX/OlHsLJ6RC Xjl8P6hEvEtdg6TM9vXyVoSR+cAzwiTQz4vZ+aVeRoCgOE4azFR+UO2BA9XygtOQBcVD FbO6w1KrOVAL9nIRV7Egv9id3kateUvcBQmKjUdr2ZAIOxvpRbvduH9AkI82AOZofp+I FsQG1Twp09dRF6fLrIOY/Y87hX1vyO9d8Sdp2ML7ZWFpoBEqtEpkWYaPGNDamI1jZXku QUYRbFsMbGs9UgW4BEM7fGXrilPNeBBGFdiIrhBrz5lZa/B46RrcRrEtNqbQAtpEwljK I2dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q8OrJgVFMNtiu6I+aQ5VJdWj3+KcVV9oDj7tFS/SYnM=; b=rwQ6NgOszGxujRUsMyKt2oqSoCTDV6OIVQOGr3BD9jMLvAblZhtM9GEZ/tSIxse0RT aDYDaGqTDJbafmrrEYr19lQAgdZngATrvfU2A9Com7KTyXaRtFxWu0b2EDVQU+imY+u9 VZw01ZbWTPuCRromue0Eb+TEDE8/DrBWl9U91PLnoJmRv2Awg+2Oek+Tn2jK1L6HVp3I ulhQXay12ECszRkdlmzNsNGYRYe/HCshWwLT4E63VR3dni8ET2aybHb4mGl7LwhvzEPk 69JYmF1apdFDms69aU+uZg1hOFChKA1BpRH6KKNTpRTnyiUdgObLB2blBBQyetijfbIQ B0SA== X-Gm-Message-State: AN3rC/7v7Y8+EzhY12Fyp1K2fVjoMGkwgYAtxlcivTzst5jaIek50VDx X8YxdtrF65QM0R/S3pRLzoRY1NR1yD5b X-Received: by 10.129.51.131 with SMTP id z125mr5792183ywz.87.1493051314267; Mon, 24 Apr 2017 09:28:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 24 Apr 2017 09:27:53 -0700 (PDT) In-Reply-To: References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> <1493020692.3390.8.camel@redhat.com> From: Eric Rescorla Date: Mon, 24 Apr 2017 09:27:53 -0700 Message-ID: To: Ryan Sleevi Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1142165c38038a054dec199e Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 16:28:42 -0000 --001a1142165c38038a054dec199e Content-Type: text/plain; charset=UTF-8 I'm reading there as being no consensus to make this change, so I plan not to absent chair directive. -Ekr On Mon, Apr 24, 2017 at 6:26 AM, Ryan Sleevi wrote: > > > On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos > wrote: > >> >> That's intentional. > > > And misguided. It violates the layering. > > >> Not every application is firefox or chrome and thus >> application writers cannot be expected to set sane defaults for OCSP >> validity time _when the nextUpdate field is missing_. > > > Not every TLS implementation should be required to process the PKI. > > >> The reason they >> cannot be expected to do that, is that it is not by way obvious what to >> do. Ilari's implentation closes the connection, mine sets a limit of 15 >> days, and I guess each and every other one behaves differently. It is >> the role of the standards to clarify uncertainties for implementers or >> forbid such options (I'd equally be happy if we have a text that >> forbids an empty nextUpdate field in OCSP responses to be used in the >> context of TLS 1.3 ocsp stapling). >> > > Can you point to where the spec supports your behaviours? That is, where > it's a valid reading of the spec to close the connection or to set a limit > of 15 days. > > The point is that it's not a valid reading of the spec. It is, instead, an > application profile. And that's great. I don't think anyone would > realistically be arguing that applications or other specifications cannot > profile the spec to their needs. While I remain unconvinced that TLS is the > right thing, what you're describing here is simply a decision you've made > for your community. That doesn't mean that because you and Ilari have made > different decisions, that should be imposed on the spec. > > >> > Given that stapling "issues" exist even without stapling, it does >> > seem an unnecessary reach to include within the spec. >> >> There is a usability and interoperability issue there. > > > Not within the spec. Within the profile you've done for your community. > > >> Given that there >> is no common interpretation of what the missing nextUpdate field means >> in terms of validity, there some equally valid interpretations: >> 1. the response is invalid for use in TLS 1.3 >> > > That's not an equally valid interpretation. A missing nextUpdate is > defined in the relevant OCSP specs. > > >> 2. the response is valid for a limited amount of time 1, 7, 8, 9, 15 >> days >> > > That's not an equally valid interpretation. A missing nextUpdate is > defined in the relevant OCSP specs. > > >> 3. the response is valid for an unlimited amount of time (which raises >> the question of why staple at all in that case?) >> > > A missing nextU... you get the idea. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1142165c38038a054dec199e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm reading there as being no consensus to make this c= hange, so I plan not to absent chair directive.

-Ekr


On Mon, Apr 24, 2017 at 6:26 AM, Ryan Sleevi <ryan-ietftls@sle= evi.com> wrote:


On Mon,= Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:

That's intentional.

And misguid= ed. It violates the layering.
=C2=A0
Not every application is firefox or chrome and thu= s
application writers cannot be expected to set sane defaults for OCSP
validity time _when the nextUpdate field is missing_.
Not every TLS implementation should be required to proce= ss the PKI.=C2=A0
=C2=A0
The reason they
cannot be expected to do that, is that it is not by way obvious what to
do. Ilari's implentation closes the connection, mine sets a limit of 15=
days, and I guess each and every other one behaves differently. It is
the role of the standards to clarify uncertainties for implementers or
forbid such options (I'd equally be happy if we have a text that
forbids an empty nextUpdate field in OCSP responses to be used in the
context of TLS 1.3 ocsp stapling).

Can you point to where the spec supports your behaviours? That is, where= it's a valid reading of the spec to close the connection or to set a l= imit of 15 days.

The point is that it's not a = valid reading of the spec. It is, instead, an application profile. And that= 's great. I don't think anyone would realistically be arguing that = applications or other specifications cannot profile the spec to their needs= . While I remain unconvinced that TLS is the right thing, what you're d= escribing here is simply a decision you've made for your community. Tha= t doesn't mean that because you and Ilari have made different decisions= , that should be imposed on the spec.
=C2=A0
>=C2=A0 Given that stapling "issues" exist even without stapli= ng, it does
> seem an unnecessary reach to include within the spec.

There is a usability and interoperability issue there.
=

Not within the spec. Within the profile you'= ve done for your community.
=C2=A0
Given that there
is no common interpretation of what the missing nextUpdate field means
in terms of validity, there some equally valid interpretations:
=C2=A01. the response is invalid for use in TLS 1.3
That's not an equally valid interpretation. A missi= ng nextUpdate is defined in the relevant OCSP specs.
=
=C2=A0
=C2=A02. the response is valid for a limited amount of time 1, 7, 8, 9, 15<= br> days

That's not an equally v= alid interpretation. A missing nextUpdate is defined in the relevant OCSP s= pecs.
=C2=A0
=C2=A03. the response is valid for an unlimited amount of time (which raise= s
=C2=A0the question of why staple at all in that case?)

A missing nextU... you get the idea.

<= /div>


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a1142165c38038a054dec199e-- From nobody Mon Apr 24 09:33:07 2017 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 1345B131832 for ; Mon, 24 Apr 2017 09:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 3KxfJOJTeWSJ for ; Mon, 24 Apr 2017 09:33:02 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEE513182D for ; Mon, 24 Apr 2017 09:33:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3782A25EAB; Mon, 24 Apr 2017 19:33:01 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id cy2Lrs1qi0Bu; Mon, 24 Apr 2017 19:33:00 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id D11362313; Mon, 24 Apr 2017 19:33:00 +0300 (EEST) Date: Mon, 24 Apr 2017 19:32:59 +0300 From: Ilari Liusvaara To: Hannes Tschofenig Cc: "" Message-ID: <20170424163258.GB18783@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 16:33:05 -0000 On Mon, Apr 24, 2017 at 05:39:39PM +0200, Hannes Tschofenig wrote: > Hi Ilari, > > thanks for your response. A few remarks inline: > > On 04/21/2017 12:48 PM, Ilari Liusvaara wrote: > > On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote: > >> I read through draft-rescorla-tls-subcerts-01 and I ran into some basic > >> questions. > >> > >> I have been wondering why the TLS server operator obtains an end-entity > >> certificate from a CA (which cannot be used to sign further > >> certificates) instead of running an intermediate CA him-/herself > >> instead. This would work without requiring any changes to the client > >> side. The proposed solution, although technically feasible, will > >> unfortunately take a long time to deploy since it requires cooperation > >> from clients, servers, and also from CAs. > > > > There is enormous amount of red tape obtaining intermediates, even > > technically constrained ones. And as consequence, it is enormously > > expensive (through not nearly as expensive as public CA). > > In essence you are doing this through the extension as well just using a > different format. > > > > > Defining new extensions is much more deployable, as slow as it is > > (AFAICT, no BR changes needed). > > I hope that this is true since otherwise you have just traded one > problem against the other one. AFAICT, CAs can add arbitrary extensions if (logically sufficient but not necressary): - CA is "aware" of "a reason" to include it, and - Extension has meaning on "public Internet", and - Extension does not mislead w.r.t. CA validation performed (CABForum Baseline Requirements, version 1.4.4, section 7.1.2.4). For this, AFAICT: - CSR requesting it or other kind of request is "a reason" to include it. - Defined in RFCs for public use imples meaning on "public Internet". - This extension does not affect CA validation. Of course: - Fixed process delay on CABForum for technical changes to BRs is ~7 weeks (1 week of discussion + 1 week of voting + ~4.3 weeks of IPR review + few days of misc. other). That's much faster than the time CAs take to actually offer this (if ever!). - Nobody changes the extension rules in nasty ways for reasons I can't fathom of. > >> What is also not clear to my why some of the certificate management > >> protocols, which provide the necessary level of automation, cannot be > >> used with CAs to request short-lived certificates. > > > > AFAIK, that would cause issues with CT and OCSP signing. > > > > The latter would be fixable by reintroducing CABForum ballot 153 and > > passing it (the reasons 153 failed were obviously political instead of > > technical). > Isn't this something ACME was trying to solve as well? ACME can perform fast rolling of certificates. What it can't deal with is any possible downsides to actually doing that in real world. -Ilari From nobody Mon Apr 24 09:40:17 2017 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 402E3131846 for ; Mon, 24 Apr 2017 09:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 MU1a4O-PCoVh for ; Mon, 24 Apr 2017 09:40:14 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 CA653131844 for ; Mon, 24 Apr 2017 09:40:13 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id k11so37330005ywb.1 for ; Mon, 24 Apr 2017 09:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tD8D01RYdADwwoUjIHqj9CXNfioqc7LnNuolxpmzcYQ=; b=Kq0qSWOYVEtw4GOy1O0v+8ujxpOosQwK3aUcq0JbZ3orJApIqmNDVMqZmR5ZwnjVsU 101JVbg7IOLzNWEPX/ayh50eZ2Dhz54+dP2wQJcY6chCsOHM+mgVln7GxcKIXMEeo/0Q Gj2g3lVnlD+twf+wmXGm8vyBnha3dVkHKSVOH9WmoP3S/yO7FqixxGoNpcUtCd066HvN ohNKoVvKHhQH430AOvaQNjk1xxAgLtRzWhtJWVVaHkZdAFIonpTODr1SQ5DdSZ7GzpcK 01BNp3Tp9ZYt2qOJ0o1rtubQOmXRgE1qypXD4hz5VeL9OFNVKTM7KBE4FPXpEKhB6X8o B0aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tD8D01RYdADwwoUjIHqj9CXNfioqc7LnNuolxpmzcYQ=; b=m4GSz9fUvaDZEUwo/FaD13vGk5Neo6UDnE00873bJRcMytTFK7H3gz3FmV2DSoqoXu 7xJJoJiXQwPR6AG7BOBqUwyjIUXKxSpumonR3OYkDpYMxB9wWk0WhSJLUp93WdXFfJX+ KLGPly/LSvCWW45i0qmVoSzlq1ArYRh6tM12lVnXKyJzn5+wO7NjnU7RRztONTuAzS3P qz5fUIbjRMpYz1drwxbnW9MucYgo2K8687d2QT4yGNSMklQ/FJjgrg2LvuQldgzqMUzx w6DRm8W+T4KiziqmU6UTNUT/fCqgCwwaV5qzQItxYhcZqO1q4RwyqSeSm2VwrP2fZvwH WZDw== X-Gm-Message-State: AN3rC/6FqI7viSHSNFmWrx4mW7lrN76W+NUV4TIUr9C7Ek2rP5DiJtRu 2phs9mADgTwKm4sC+l2eM1zdL7lBuYp2 X-Received: by 10.129.172.93 with SMTP id z29mr5489158ywj.125.1493052012861; Mon, 24 Apr 2017 09:40:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 24 Apr 2017 09:39:32 -0700 (PDT) In-Reply-To: <20170424161619.GA18783@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170424152422.GA18543@LK-Perkele-V2.elisa-laajakaista.fi> <20170424161619.GA18783@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 24 Apr 2017 09:39:32 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f403045f285cdbdd8a054dec421f Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 16:40:16 -0000 --f403045f285cdbdd8a054dec421f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nice catch. 9 bytes seems a bit cramped. What I suggest here is that we remove the "TLS 1.3, ", as it was just there by analogy to the handshake context and then we are back to having 18 bytes. If people feel like we should have some "TLS" prefix, I think "TLS " would be enough, giving us 1 bytes. -Ekr On Mon, Apr 24, 2017 at 9:16 AM, Ilari Liusvaara wrote: > On Mon, Apr 24, 2017 at 08:28:33AM -0700, Eric Rescorla wrote: > > On Mon, Apr 24, 2017 at 8:24 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Mon, Apr 24, 2017 at 05:56:58AM -0700, Eric Rescorla wrote: > > > > https://github.com/tlswg/tls13-spec/issues/964 > > > > > > > > Here is a proposed set of new labels, which, while slightly less > clear, > > > all > > > > fit > > > > into the 18 byte limit which Ilari (and I agree) says is what we > have. > > Aargh, turns out that Merke-Damg=C3=A5rd strengthening probably affects > things... > > For SHA-256, MD strengthening consists of padding bit and 64-bit > message bit count, for total of 65-512 bits of padding. > > Trying to construct the raw SHA-256 message words for inner hash with > 9 byte label (K is key, L is label, H is hash). > > KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK > 36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636 > 00201254 4C532031 2E332C20 LLLLLLLL LLLLLLLL LL20HHHH HHHHHHHH HHHHHHHH > HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHH0180 00000000 000003B8 > > Adding 10th byte to label seems to blow the block (0x3C0=3D1*512+448): > > KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK > 36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636 > 00201354 4C532031 2E332C20 LLLLLLLL LLLLLLLL LLLL20HH HHHHHHHH HHHHHHHH > HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHH01 80000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000003C0 > > > For comparision, with SHA-384, the blocks for 9-byte label seem to be: > > KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK > KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK 3636363636363636 3636363636363636 > 3636363636363636 3636363636363636 3636363636363636 3636363636363636 > 3636363636363636 3636363636363636 3636363636363636 3636363636363636 > 003012544C532031 2E332C20LLLLLLLL LLLLLLLLLL30HHHH HHHHHHHHHHHHHHHH > HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH > HHHHHHHHHHHH0180 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 0000000000000000 0000000000000638 > > (Which has 327 hash block padding bits). > > > -Ilari > --f403045f285cdbdd8a054dec421f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nice catch.

9 bytes seems a bit cramped= . What I suggest here is that we remove the "TLS 1.3, ", as it wa= s just there by analogy to the handshake context and then we are back to ha= ving 18 bytes.

If people feel like we should have = some "TLS" prefix, I think "TLS " would be enough, givi= ng us 1 bytes.

-Ekr


<= /div>

On Mon= , Apr 24, 2017 at 9:16 AM, Ilari Liusvaara <ilariliusvaara@welho.co= m> wrote:
= On Mon, Apr 24, 2017 at 08:28:33AM -0700, Eric Rescorla wrote:
> On Mon, Apr 24, 2017 at 8:24 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Mon, Apr 24, 2017 at 05:56:58AM -0700, Eric Rescorla wrote: > > > https://github.com/tlswg/tls13-spe= c/issues/964
> > >
> > > Here is a proposed set of new labels, which, while slightly = less clear,
> > all
> > > fit
> > > into the 18 byte limit which Ilari (and I agree) says is wha= t we have.

Aargh, turns out that Merke-Damg=C3=A5rd strengthening probably affe= cts
things...

For SHA-256, MD strengthening consists of padding bit and 64-bit
message bit count, for total of 65-512 bits of padding.

Trying to construct the raw SHA-256 message words for inner hash with
9 byte label (K is key, L is label, H is hash).

KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK
36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636
00201254 4C532031 2E332C20 LLLLLLLL LLLLLLLL LL20HHHH HHHHHHHH HHHHHHHH
HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHH0180 00000000 000003B8

Adding 10th byte to label seems to blow the block (0x3C0=3D1*512+448):

KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK
36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636
00201354 4C532031 2E332C20 LLLLLLLL LLLLLLLL LLLL20HH HHHHHHHH HHHHHHHH
HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHH01 80000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 000003C0


For comparision, with SHA-384, the blocks for 9-byte label seem to be:

KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK
KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK 3636363636363636 3636363636363636
3636363636363636 3636363636363636 3636363636363636 3636363636363636
3636363636363636 3636363636363636 3636363636363636 3636363636363636
003012544C532031 2E332C20LLLLLLLL LLLLLLLLLL30HHHH HHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH
HHHHHHHHHHHH0180 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000638

(Which has 327 hash block padding bits).


-Ilari

--f403045f285cdbdd8a054dec421f-- From nobody Mon Apr 24 10:13:35 2017 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 325CF1318AB for ; Mon, 24 Apr 2017 10:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u8DIYUAiFs4D for ; Mon, 24 Apr 2017 10:13:30 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 E70961205F1 for ; Mon, 24 Apr 2017 10:13:29 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id v14so11634067pfd.2 for ; Mon, 24 Apr 2017 10:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BBrRlToKvfOoYt5K6Wjo+tJ25LyVNbvIXNoRelWoLRY=; b=IHg8DfdzaSQ+dmSduODdi7/WjlF5XS0JDjoz3LIY7mb3q34zaQ2zoA0K5p6s/yj2Kl +/kJ4YKOuhQXY8VL9UNT/OOchapQ99WN60rcXtUgJtey9Gn3sU/qRYP29yD8Xz+tF3Xa OvUwRjKm5aFUg5k0285IUH4TOQD1780AVu4ZwXSVqceBgM/0Y3or71EhTPXAIxjWtJYY X5zqFltcVin8e/zgeZsVLzgeV2/nPTh9iocfJVeSqpNiie8/f7pd3pEv0z+OGtU5UVlX n0vSbr85O2H8dJu2sc7+6PeMQf6qZtNl04Jfxa7al2zfMPU+K8blsbCGV+vBlO1J316e 9juQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BBrRlToKvfOoYt5K6Wjo+tJ25LyVNbvIXNoRelWoLRY=; b=bERnwtboJqOOFT4eBTL1D9rbkfcZ/apIV47fgxXIX1xPh4CoYj0KAgNbCgT23ULkPw Edc26Wi4cKF+/1oIJhFNsIak1/IQyLxbvpqOETWdVY+T6KEjnDmSkOvUTmL+wGdDmLO3 QrAnFf+692s+VbOA/Ty0L0U9cl50DDJNQ0mdTW8orRdF+rpxXmq0joqrObL0pdDEPi8I mUZyomqn3Fpc8T+SPT9maL5VzoY7GuZmkeTyPLPWViNUHNY18cuwfdnbElBCfGBf4/GP Ln2ki9u1CRv3lFf3lnd3XFkefcS/jqm3NVsSr9YSfnx3/BZx0SnjvjlAqwNCJw0a8Cbz amNQ== X-Gm-Message-State: AN3rC/5kpufa/x8UVmPt5sbSxl39G4BCWixf9WbCCNXpe03rGcijQeOS m92hsu0alc22kf3hEbzrEuzBoOhnPQ== X-Received: by 10.84.210.72 with SMTP id z66mr33299279plh.191.1493054009476; Mon, 24 Apr 2017 10:13:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.12 with HTTP; Mon, 24 Apr 2017 10:13:27 -0700 (PDT) In-Reply-To: References: <55e7544b-808a-5e0e-f66e-3a6f4a79e218@gmx.net> <20170421105213.GB20822@LK-Perkele-V2.elisa-laajakaista.fi> From: Watson Ladd Date: Mon, 24 Apr 2017 10:13:27 -0700 Message-ID: To: Hannes Tschofenig Cc: Ilari Liusvaara , "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 17:13:34 -0000 On Mon, Apr 24, 2017 at 8:42 AM, Hannes Tschofenig wrote: > Hi Ilari, > > thanks for your feedback. Remarks inline: > > On 04/21/2017 12:52 PM, Ilari Liusvaara wrote: >> On Fri, Apr 21, 2017 at 10:44:01AM +0200, Hannes Tschofenig wrote: >>> I have read draft-sullivan-tls-exported-authenticator-01 and have a few >>> questions. I haven't followed this work previously but have been >>> wondering whether this functionality would be useful for "me". >>> >>> The described functionality sounds like post-handshake authentication >>> from TLS 1.3 (although it does not use that term throughout the >>> document). I would have thought that this functionality is a replacement >>> to the TLS 1.2 renegotiation but then there is also the TLS 1.3 content >>> in there which raises the question about how this relates to the >>> post-handshake authentication functionality. >> >> There are two things that can't be accomplished with PHA: >> >> - Authenticating the server for more identities. >> - Transmitting application context with the certificate. >> >> TLS 1.2 renegotiation also is incapable of either of those. > > > In what situations would I want those features? The draft is rather > brief on the motivational side. Part of the reason TLS client certificate UX sucks is the absence of hints as to which certificates are offered. It's a lot easier to add that to HTTP then to TLS. It also fixes bugs where authentication state doesn't line up nicely with HTTP request state. The other application is to servers which want to indicate they have certificates for other sites, so as to enable connection reuse for a latency and performance win. > > >> >>> What does the following sentence mean and what is the use case for it? >>> >>> " >>> This proof of authentication can >>> be exported and transmitted out of band from one party to be >>> validated by the other party. >>> " >>> Who are the parties? >> >> Most probably TLS client and server. > > Maybe the draft should say that. > > Ciao > Hannes > >> >> >> -Ilari >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Apr 24 10:30:10 2017 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 C00411318CC for ; Mon, 24 Apr 2017 10:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 C4LoVU54q3rP for ; Mon, 24 Apr 2017 10:30:06 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id AF88A1318C9 for ; Mon, 24 Apr 2017 10:30:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id B9D9627168; Mon, 24 Apr 2017 20:30:04 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id VL3lkQ_MAvsr; Mon, 24 Apr 2017 20:30:04 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 6C196286; Mon, 24 Apr 2017 20:30:04 +0300 (EEST) Date: Mon, 24 Apr 2017 20:30:02 +0300 From: Ilari Liusvaara To: Hannes Tschofenig Cc: "" Message-ID: <20170424173002.GC18783@LK-Perkele-V2.elisa-laajakaista.fi> References: <55e7544b-808a-5e0e-f66e-3a6f4a79e218@gmx.net> <20170421105213.GB20822@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 17:30:09 -0000 On Mon, Apr 24, 2017 at 05:42:08PM +0200, Hannes Tschofenig wrote: > Hi Ilari, > > thanks for your feedback. Remarks inline: > > On 04/21/2017 12:52 PM, Ilari Liusvaara wrote: > > On Fri, Apr 21, 2017 at 10:44:01AM +0200, Hannes Tschofenig wrote: > >> I have read draft-sullivan-tls-exported-authenticator-01 and have a few > >> questions. I haven't followed this work previously but have been > >> wondering whether this functionality would be useful for "me". > >> > >> The described functionality sounds like post-handshake authentication > >> from TLS 1.3 (although it does not use that term throughout the > >> document). I would have thought that this functionality is a replacement > >> to the TLS 1.2 renegotiation but then there is also the TLS 1.3 content > >> in there which raises the question about how this relates to the > >> post-handshake authentication functionality. > > > > There are two things that can't be accomplished with PHA: > > > > - Authenticating the server for more identities. > > - Transmitting application context with the certificate. > > > > TLS 1.2 renegotiation also is incapable of either of those. > > > In what situations would I want those features? The draft is rather > brief on the motivational side. - Client authentication in HTTP/2 after handshake. - Dynamically adding server identities in HTTP/2 in order to hide services (SNI encryption is _HARD_). -Ilari From nobody Mon Apr 24 13:57:39 2017 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 B79DD128B92 for ; Mon, 24 Apr 2017 13:57:37 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 y4S8JfJSWgKb for ; Mon, 24 Apr 2017 13:57:36 -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 156F31201F8 for ; Mon, 24 Apr 2017 13:57:34 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id h123so43528391qke.0 for ; Mon, 24 Apr 2017 13:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=UhsQ8oF3QkiV/NeCwJMp06Jj6/lwGiZih7r8tEI1qSc=; b=XRWxzKVgmPrFJPY6EYhDa5ElapYoSn++JRvZ9oZZR+0Oq/BraWGU8dzqQaKCLEcJ2X lEp1ohfCH3mCobmHRifqaurYVY0qOloYRvIVgoBmBcA9WU/WW0GdNUdA+3+1HUClA49G HIK2FfSvgchGddoXpyO7z5/DJLSy2wBMofTml/qi02thFIy89HPSYyVXm+Ssib6RZWaN Q0dBfYwIghXkbYAt3Dbu9OmcRy7nxVeRVX3PU+MoZ036yNzNFliGEZkG9itevus7gdKF AN2oCHzPgkVEP0FppdAuwHZcaOEREjJ676MOlp587ZOLlwwzpBIUk+xdc5gxo6TC9M81 neug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=UhsQ8oF3QkiV/NeCwJMp06Jj6/lwGiZih7r8tEI1qSc=; b=iyhMxijO6pB4Z+XUKEnn9jA71qk/dZy76PFt7VCO+mlhbB7A/jdVVHJjxz+IpZp9TI zf6UwwX3ThFuY+yffTF6SyynMoyedKPeVV/aY0ro8ObZ/lJb2M+LApuOZEn8sIrD++nG vJwKekiqNb9a0L+bMC/gUbLil9Sp//QfKyoXyTOTh0wkAC9akL7DiyrNClDb+Xf6SSd1 QAlQJq6s4rkfPxx5zBQ4DZalnCs7a+m1kNWjbeGv3In+4slx2vlBUATzqVY2dRyaju35 la2BLHyxfgGmUPFWR/cN/PWxDRmeLYZToX5egDXiM/o797eOpeGkXXOLP3XhlCYiUboh B9Cw== X-Gm-Message-State: AN3rC/7phAvNIcu03pz9VBs0tyMgIP3cZr4PE9Y/GHjM8oeEv9NmF3UU x3Zs5yLeOfrecT9T X-Received: by 10.55.130.5 with SMTP id e5mr29246586qkd.166.1493067453100; Mon, 24 Apr 2017 13:57:33 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id t23sm13675541qka.37.2017.04.24.13.57.31 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 24 Apr 2017 13:57:32 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 24 Apr 2017 16:57:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20170424161619.GA18783@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201704241657.30874.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 20:57:38 -0000 On Monday, April 24, 2017 12:39:32 pm Eric Rescorla wrote: > 9 bytes seems a bit cramped. What I suggest here is that we remove the "TLS > 1.3, ", as it was just there by analogy to the handshake context and then > we are back to having 18 bytes. > > If people feel like we should have some "TLS" prefix, I think "TLS " would > be enough, giving us 1 bytes. (assuming you mean 14 bytes here) If I remember correctly, in some discussion quite a while back, we decided we wanted to bake the version number into the labels. This could be done more compactly by adding a ProtocolVersion value (2 bytes) to the HkdfLabel struct. "TLS" could be stuck in there as a static 3 byte opaque string, with no length or space. (yeah, the combined plaintext will go "TLSclient hs traffic", but nobody needs to care) Also, why is HkdfLabel.length 16 bits instead of 8? Is there any conceivable scenario where we'd need to HKDF-Expand to more than 256 bytes, in our uses here? Unless I'm missing something, our values for this field range from 12-32 normally (or up to 64 with 512 bit). Ditching the extra byte here would salvage another byte for labels. (just an aside: HkdfLabel.length would be a lot more clear as to its meaning if it were named HkdfLabel.output_length, instead; too many length values here) With ProtocolVersion + "TLS" + dropped length byte, that results in a label space of 14 bytes, whilst still keeping the version number baked into the label directly. An extra couple of bytes could even be salvaged out of the HkdfLabel struct by ditching the lengths of the 'label' and 'hash_value' fields, though going this far may be overkill. Dave From nobody Mon Apr 24 14:06:31 2017 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 40DF7129456 for ; Mon, 24 Apr 2017 14:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 TR2_5-BKtsgS for ; Mon, 24 Apr 2017 14:06:28 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50119.outbound.protection.outlook.com [40.107.5.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F97C1272E1 for ; Mon, 24 Apr 2017 14:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FStkyxOplYq/3vyAA49KRkUckBacmsW0uJriBS3HL3o=; b=oYkl8yZOX4TZ4uo59HtWkNRaO0NLZFoBOXdYIxJ0hqJRocmySQFmOsN3jCUT+6uoQI7dEoiiV0H7Nn96ldcnh6bNfwTDH6eBG//t/8ilT7ZPZp3ia/t+iyeetG0AKxLbcoNiGlJXHTISkF71jaPH0n178wHsLIV/BTt0aUPmD4M= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1103.eurprd07.prod.outlook.com (10.163.168.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Mon, 24 Apr 2017 21:06:26 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([10.163.168.26]) with mapi id 15.01.1047.019; Mon, 24 Apr 2017 21:06:25 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Hannes Tschofenig , Ilari Liusvaara CC: "" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [TLS] draft-rescorla-tls-subcerts-01 Thread-Index: AQHSunqIZYO5VLtqn0+DOPOxbhXZyKHPpMuAgAUIN4CAAGwOgA== Date: Mon, 24 Apr 2017 21:06:24 +0000 Message-ID: <7B28FF9C-7018-4552-B715-33442406D386@on.nokia.com> References: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2.96.108.227] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1103; 7:rBDayBMf6KE/NfrjPshhkU9oxKqeX4dG6kh/Hi4RnJidk9lZ76b4+NsLr/HNru2fr7cHOcITng9QU7MtjQePUkJogFTExDDn1zM31jA8FplS+JCfOiaXLsVTED0Wn6v5my7nT5J2Z7fnWrVTsi7g4stF4QZn/H7h7wEceTcDwvxuYZBYThX9OmeR1dYadxJVMx7qPJPyZ1CybzTXmoG5CajzdQopiyzIuK/hIPMggp8PAPJjjtJhdq2XP5HCyg90TWnQmrDC3tfxgrv4KEt9eKfUVrKZ+VP3m721ZL1kKBZ38TkLOZayH8tS33ik8pGRJwOVKnTnxKnmuwZEm13Kaw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39410400002)(39840400002)(39860400002)(377454003)(24454002)(25786009)(3660700001)(50986999)(122556002)(2900100001)(86362001)(6246003)(53546009)(83506001)(7736002)(8676002)(38730400002)(99286003)(54356999)(53936002)(4326008)(6512007)(3280700002)(2906002)(76176999)(81166006)(8936002)(107886003)(230783001)(6436002)(77096006)(6486002)(4001350100001)(6506006)(305945005)(6116002)(33656002)(5660300001)(229853002)(189998001)(102836003)(2950100002)(66066001)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1103; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 702cc611-c51a-42cd-bd46-08d48b55c49c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:VI1PR07MB1103; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(248736688235697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:VI1PR07MB1103; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1103; x-forefront-prvs: 0287BBA78D spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3083DB47B12DEB498EF9C34A982A7479@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2017 21:06:24.9877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1103 Archived-At: Subject: Re: [TLS] draft-rescorla-tls-subcerts-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 21:06:30 -0000 SGkgSGFubmVzLA0KDQpPbiAyNC8wNC8yMDE3IDE2OjM5LCAiSGFubmVzIFRzY2hvZmVuaWciIDxo YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCj4gT24gMDQvMjEvMjAxNyAxMjo0OCBQ TSwgSWxhcmkgTGl1c3ZhYXJhIHdyb3RlOg0KPiA+IFJlZ2FyZGluZyBjbGllbnRzLCBJIHRoaW5r IHRoZSBkcmFmdCBzcGVjaWZpZXMgTFVSSyBhcyBiYWNrdXAgcGxhbg0KPiA+IGZvciBjbGllbnRz IHRoYXQgZG9uJ3Qgc3VwcG9ydCBzdWJjZXJ0cyAod2hpY2ggY2F1c2VzIHNvbWUgZXh0cmENCj4g PiBsYXRlbmN5IGlmIHRyaWdnZXJlZCkuDQo+IEkgZGlkbid0IGdvdCB0aGF0IGltcHJlc3Npb24u DQoNCklsYXJpIGlzIGNvcnJlY3QgSSB0aGluayAtLSB0aGUgZmFsbGJhY2sgdG8gTFVSSyBpcyB3 aGF0IHRoZSBkcmFmdCBpbiBpdHMNCmN1cnJlbnQgdmVyc2lvbiBzZWVtcyB0byBpbXBseS4NCg0K PiBJc24ndCB0aGlzIHNvbWV0aGluZyBBQ01FIHdhcyB0cnlpbmcgdG8gc29sdmUgYXMgd2VsbD8N Cg0KV2UgaGF2ZSBwcm9wb3NlZCBhbiBleHRlbnNpb24gdG8gQUNNRSB0aGF0IGhhbmRsZXMgdGhl IGZ1bGwgbGlmZWN5Y2xlIG9mIHRoZQ0KZGVsZWdhdGlvbiwgaW5jbHVkaW5nIHRoZSBhdXRvbWF0 aWMgcmVuZXdhbCBvZiB0aGUgdHJhaWwgb2Ygc2hvcnQgdGVybQ0KY2VydGlmaWNhdGVzLiAgSXQg d29ya3MgaW4gYSBwcmV0dHkgc3RyYWlnaHRmb3J3YXJkIHdheSBhbmQgZG9lc24ndCByZXF1aXJl IGFueQ0KbW9kaWZpY2F0aW9uIGluIHRoZSBlbmRwb2ludHMnIHN0YWNrLg0KDQpDaGVlcnMsIHQN Cg0KDQo= From nobody Mon Apr 24 14:13:38 2017 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 83DF6127241 for ; Mon, 24 Apr 2017 14:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 EWaFByJVxIA2 for ; Mon, 24 Apr 2017 14:13:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id D866213153A for ; Mon, 24 Apr 2017 14:13:34 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5522B20000E; Mon, 24 Apr 2017 21:13:34 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 3F32F200008; Mon, 24 Apr 2017 21:13:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493068414; bh=LW1znL5saWQbmlwkLxndBZyvc79eKEbH1zJQXP9lXWM=; l=2575; h=To:References:From:Date:In-Reply-To:From; b=IWwi79XSKAWDbLc1bo0H4O3KvmDBR/KiDpGs7B3asI+b7DkxytuR+Giu0j1A2cnVn X9nsN1bJYWP5eYtm1zrIv3LW3jbR4vNKjy8RqAYv9Rb5Al3djV5tvRI/WgsHsqi1O/ vge09hN5G8nKhG9c07CR/Usth9ouylHZrr+DRNC8= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id E7E7C98082; Mon, 24 Apr 2017 21:13:33 +0000 (GMT) To: Dave Garrett , tls@ietf.org References: <20170424161619.GA18783@LK-Perkele-V2.elisa-laajakaista.fi> <201704241657.30874.davemgarrett@gmail.com> From: Benjamin Kaduk Message-ID: <3166bcf2-65b1-9409-bf63-8e78e00a1a0b@akamai.com> Date: Mon, 24 Apr 2017 16:13:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201704241657.30874.davemgarrett@gmail.com> Content-Type: multipart/alternative; boundary="------------E9BD3BB551F4B4A5AB7AA6C4" Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 21:13:36 -0000 This is a multi-part message in MIME format. --------------E9BD3BB551F4B4A5AB7AA6C4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/24/2017 03:57 PM, Dave Garrett wrote: >> If people feel like we should have some "TLS" prefix, I think "TLS " would >> be enough, giving us 1 bytes. > (assuming you mean 14 bytes here) > > If I remember correctly, in some discussion quite a while back, we decided we wanted to bake the version number into the labels. This could be done more compactly by adding a ProtocolVersion value (2 bytes) to the HkdfLabel struct. I would prefer to keep both "TLS" and the version number involved. I generally don't mind having a non-ASCII encoding for the version number, but then we have to pay attention to avoid putting a NULL byte in it by accident. -Ben > "TLS" could be stuck in there as a static 3 byte opaque string, with no length or space. (yeah, the combined plaintext will go "TLSclient hs traffic", but nobody needs to care) --------------E9BD3BB551F4B4A5AB7AA6C4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/24/2017 03:57 PM, Dave Garrett wrote:
If people feel like we should have some "TLS" prefix, I think "TLS " would
be enough, giving us 1 bytes.

(assuming you mean 14 bytes here)

If I remember correctly, in some discussion quite a while back, we decided we wanted to bake the version number into the labels. This could be done more compactly by adding a ProtocolVersion value (2 bytes) to the HkdfLabel struct.


I would prefer to keep both "TLS" and the version number involved.  I generally don't mind having a non-ASCII encoding for the version number, but then we have to pay attention to avoid putting a NULL byte in it by accident.

-Ben

"TLS" could be stuck in there as a static 3 byte opaque string, with no length or space. (yeah, the combined plaintext will go "TLSclient hs traffic", but nobody needs to care)

--------------E9BD3BB551F4B4A5AB7AA6C4-- From nobody Mon Apr 24 15:05:24 2017 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 B9EEE131949 for ; Mon, 24 Apr 2017 15:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 AKub15zgT-9T for ; Mon, 24 Apr 2017 15:05:21 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 119D013194C for ; Mon, 24 Apr 2017 15:05:21 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id 6so62253614ybq.2 for ; Mon, 24 Apr 2017 15:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y3ypO3G7UvqHaJtQUe6dGDyJHwwgPdyeih1amJ1K38s=; b=1bbwDMLvlAwNtaP/AR9psQU23Pp4rOcsV28zGgAJSqDQPYCOVo2bKs3hng9yf6rAtk 5m3h1fSCQVl1248IH3/+VKqlLpVYTtEJU9+wqYthknr6E0Flz6Fdjq6mzeYVLE/LaYcv +IxmtNAnYUeu7Y82IikHKjKUGGjNITBTKUi4q3uxe69cWVwmIWbLR+gSOeBFuGucy8v5 zbUFAMEm4dPVQ+iSt87wVgwVtANR3lYXAYzEYfT3CwGpJ1jxeV3QS+2FKxmCfYe+2zyW yBCf1DHESNLWABhFX0wo8gECuGI4++3m0qJg8sGwgOer1s5vIA/nghT8MCDhJH3Xr0SU HYMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y3ypO3G7UvqHaJtQUe6dGDyJHwwgPdyeih1amJ1K38s=; b=Nh43uboxrMrL2lePk40aDX/Z1hsFAfS2iS3TGmSzRR3ZaU4Eotlyzhm4+DvyedC68t vGhg4zZ7hmfG61+bWeAbPMC9jVteduaCal7Nev94mpJJtIyPfsTiGXAPJaV3agv7MCWG fCMoqHf3ZGKu9GTlVLsHxd9HvM6ogViaR4qAyhLqb6CKeVn/xWkOubYn0X/Uac+9Xs/Q 5f2tz8MwJ8IYDWSpzEQoUdPxzZ6WTChH4nwOXjodH6yuo2YOLgR3BBLnM26cU7P+S3VY lnBVDGfg3cQt5vWhV3HdtGT+M7SCbDe2RMo5i1U9Sr/ceEsKIC1XeE8M0RiWM9v+hVDx LKcA== X-Gm-Message-State: AN3rC/5OcBwcLrH3Nx9s0F92u9crgkN0jjURQMbThZBJdO7wDYR1f7DU bmnliEwNQbKq2r41C56hY7nHMzEnnQ== X-Received: by 10.37.179.30 with SMTP id l30mr6881783ybj.107.1493071520289; Mon, 24 Apr 2017 15:05:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 24 Apr 2017 15:04:39 -0700 (PDT) In-Reply-To: <201704241657.30874.davemgarrett@gmail.com> References: <20170424161619.GA18783@LK-Perkele-V2.elisa-laajakaista.fi> <201704241657.30874.davemgarrett@gmail.com> From: Eric Rescorla Date: Mon, 24 Apr 2017 15:04:39 -0700 Message-ID: To: Dave Garrett Cc: "tls@ietf.org" , Ilari Liusvaara Content-Type: multipart/alternative; boundary=f403045f2abe977e27054df0cd8a Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 22:05:23 -0000 --f403045f2abe977e27054df0cd8a Content-Type: text/plain; charset=UTF-8 On Mon, Apr 24, 2017 at 1:57 PM, Dave Garrett wrote: > On Monday, April 24, 2017 12:39:32 pm Eric Rescorla wrote: > > 9 bytes seems a bit cramped. What I suggest here is that we remove the > "TLS > > 1.3, ", as it was just there by analogy to the handshake context and then > > we are back to having 18 bytes. > > > > If people feel like we should have some "TLS" prefix, I think "TLS " > would > > be enough, giving us 1 bytes. > > (assuming you mean 14 bytes here) > > If I remember correctly, in some discussion quite a while back, we decided > we wanted to bake the version number into the labels. I don't remember there really being a reason for that... This could be done more compactly by adding a ProtocolVersion value (2 > bytes) to the HkdfLabel struct. "TLS" could be stuck in there as a static 3 > byte opaque string, with no length or space. (yeah, the combined plaintext > will go "TLSclient hs traffic", but nobody needs to care) > How is this better than "TLS13client hs traffic" in the label? Note that we could do "T13"... With ProtocolVersion + "TLS" + dropped length byte, that results in a label > space of 14 bytes, whilst still keeping the version number baked into the > label directly. > > An extra couple of bytes could even be salvaged out of the HkdfLabel > struct by ditching the lengths of the 'label' and 'hash_value' fields, > though going this far may be overkill. That seems very dangerous. -Ekr > > > Dave > --f403045f2abe977e27054df0cd8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 24, 2017 at 1:57 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Monday, April 24, 2017 12:39:32 pm Eric Rescorla wrote:
> 9 bytes seems a bit cramped. What I suggest here is that we remove the= "TLS
> 1.3, ", as it was just there by analogy to the handshake context = and then
> we are back to having 18 bytes.
>
> If people feel like we should have some "TLS" prefix, I thin= k "TLS " would
> be enough, giving us 1 bytes.

(assuming you mean 14 bytes here)

If I remember correctly, in some discussion quite a while back, we decided = we wanted to bake the version number into the labels.
I don't remember there really being a reason for that...


This could = be done more compactly by adding a ProtocolVersion value (2 bytes) to the H= kdfLabel struct. "TLS" could be stuck in there as a static 3 byte= opaque string, with no length or space. (yeah, the combined plaintext will= go "TLSclient hs traffic", but nobody needs to care)
=C2=A0
How is this better than "TLS13client hs tra= ffic" in the label?

Note that we could do &qu= ot;T13"...


With ProtocolVersion + "TLS" + dropped length byte, that results = in a label space of 14 bytes, whilst still keeping the version number baked= into the label directly.

An extra couple of bytes could even be salvaged out of the HkdfLabel struct= by ditching the lengths of the 'label' and 'hash_value' fi= elds, though going this far may be overkill.

That seems very dangerous.

-Ekr
=C2=A0=


Dave

--f403045f2abe977e27054df0cd8a-- From nobody Mon Apr 24 15:09:05 2017 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 C5E8E1318D0 for ; Mon, 24 Apr 2017 15:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 jl7fSAJgHxjz for ; Mon, 24 Apr 2017 15:09:03 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6077F126B71 for ; Mon, 24 Apr 2017 15:09:03 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 04227496C5C; Mon, 24 Apr 2017 22:09:03 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id D8741496C04; Mon, 24 Apr 2017 22:09:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493071742; bh=pymlVQYwWc1fNiQ7e+MMUTm77V8NQ39HbX5CKMXcybQ=; l=5516; h=To:References:Cc:From:Date:In-Reply-To:From; b=VWhZ+G7MWTYFslCPn6A8T8IcpZmwCiSMvKBIlHab/VYpWw3b6BZMQ4DXfrTen/Gsd ZEmFnN4R//0ey0f32wzjoZHPSqRFcgMW0k53zv1qvbkqRb9BsZULvRLUp+qed8LiAw oywU+4k5T6lv7eWGdYLFcSpCUWHQugpgQf8s22BE= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 72F051E0E7; Mon, 24 Apr 2017 22:09:02 +0000 (GMT) To: Eric Rescorla , Dave Garrett References: <20170424161619.GA18783@LK-Perkele-V2.elisa-laajakaista.fi> <201704241657.30874.davemgarrett@gmail.com> Cc: "tls@ietf.org" From: Benjamin Kaduk Message-ID: Date: Mon, 24 Apr 2017 17:09:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B1A0CF15C3BE3C96D57433CB" Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 22:09:05 -0000 This is a multi-part message in MIME format. --------------B1A0CF15C3BE3C96D57433CB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/24/2017 05:04 PM, Eric Rescorla wrote: > > > On Mon, Apr 24, 2017 at 1:57 PM, Dave Garrett > wrote: > > On Monday, April 24, 2017 12:39:32 pm Eric Rescorla wrote: > > 9 bytes seems a bit cramped. What I suggest here is that we > remove the "TLS > > 1.3, ", as it was just there by analogy to the handshake context > and then > > we are back to having 18 bytes. > > > > If people feel like we should have some "TLS" prefix, I think > "TLS " would > > be enough, giving us 1 bytes. > > (assuming you mean 14 bytes here) > > If I remember correctly, in some discussion quite a while back, we > decided we wanted to bake the version number into the labels. > > > I don't remember there really being a reason for that... > Double-plus extra surefire way to avoid cross-version badness. > > This could be done more compactly by adding a ProtocolVersion > value (2 bytes) to the HkdfLabel struct. "TLS" could be stuck in > there as a static 3 byte opaque string, with no length or space. > (yeah, the combined plaintext will go "TLSclient hs traffic", but > nobody needs to care) > > > How is this better than "TLS13client hs traffic" in the label? > > Note that we could do "T13"... > Probably fine. > > With ProtocolVersion + "TLS" + dropped length byte, that results > in a label space of 14 bytes, whilst still keeping the version > number baked into the label directly. > > An extra couple of bytes could even be salvaged out of the > HkdfLabel struct by ditching the lengths of the 'label' and > 'hash_value' fields, though going this far may be overkill. > > > That seems very dangerous. > It seems not worth doing, yes. -Ben --------------B1A0CF15C3BE3C96D57433CB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/24/2017 05:04 PM, Eric Rescorla wrote:


On Mon, Apr 24, 2017 at 1:57 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
On Monday, April 24, 2017 12:39:32 pm Eric Rescorla wrote:
> 9 bytes seems a bit cramped. What I suggest here is that we remove the "TLS
> 1.3, ", as it was just there by analogy to the handshake context and then
> we are back to having 18 bytes.
>
> If people feel like we should have some "TLS" prefix, I think "TLS " would
> be enough, giving us 1 bytes.

(assuming you mean 14 bytes here)

If I remember correctly, in some discussion quite a while back, we decided we wanted to bake the version number into the labels.

I don't remember there really being a reason for that...


Double-plus extra surefire way to avoid cross-version badness.


This could be done more compactly by adding a ProtocolVersion value (2 bytes) to the HkdfLabel struct. "TLS" could be stuck in there as a static 3 byte opaque string, with no length or space. (yeah, the combined plaintext will go "TLSclient hs traffic", but nobody needs to care)
 
How is this better than "TLS13client hs traffic" in the label?

Note that we could do "T13"...


Probably fine.


With ProtocolVersion + "TLS" + dropped length byte, that results in a label space of 14 bytes, whilst still keeping the version number baked into the label directly.

An extra couple of bytes could even be salvaged out of the HkdfLabel struct by ditching the lengths of the 'label' and 'hash_value' fields, though going this far may be overkill.

That seems very dangerous.


It seems not worth doing, yes.

-Ben
--------------B1A0CF15C3BE3C96D57433CB-- From nobody Mon Apr 24 15:17:05 2017 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 C9A0B126C7A for ; Mon, 24 Apr 2017 15:17:03 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 k1rJenEgIAUh for ; Mon, 24 Apr 2017 15:17:02 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 11BFF120227 for ; Mon, 24 Apr 2017 15:17:02 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id t144so81621220lff.1 for ; Mon, 24 Apr 2017 15:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YBvSjsK9I3YuRUlfDFTlCL/o2EvVhGSVU8mnITHiG/o=; b=BXBSn1qLRWn388I70Ek2wDSJMcfhRL95bygBKKYFPRO8ic77JIAwMx7Uh8AHdZ2rSU ziIACRYrJFPBLhI+/qIZcG2LzqtQ9cKyKprjlmn7izFDxE0FxrRf8G+XctXMH/uDl2uS iLKxR47lMgfoct+pIMQ1FdNfyoKio4glZejpMk0UH69wa/EjZsX6YZ883HkJYAqqjsib hRBbjOMxC4fV3oaXWz06LxGYQWPpf7zmsuU/DFQNOhbTfsTTwWHbWN/mwwI0i57tGyK3 Ur0uZ9AC3O76aQKwCf8qKaHO04vedRB2e0PLOP5vo2P34ZduzCnVx6HCdhudMd4qZejx iI1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YBvSjsK9I3YuRUlfDFTlCL/o2EvVhGSVU8mnITHiG/o=; b=Kre5DZaTv8FG20fipesFDxPdhjIB0xK4UVYpsqqKWwQJi8djG/LixipnwDi7jjLFfa Pw92mU01uq7t1OSNg2VqROV2NslXdh9ez95W3hYf2SHAfLZgbyQuNdv6DrTRvYyoHGT7 uoHkXCk90wGkZHprt4N2A41DGFB3gvxWIuZ6HAuFl/2kVqF8gdno0TwXHRQXK5Ubi6QI X7C2r0xXYl6ALKsHyMUT9PQGZppkQrGs9MPkp1TT9/jYu66YZ0bN025MvwudKH9SM4Io RVRYu7hF6KMEA4T5ySrvvtzMhHMYZua4H1hdWirIrhbAJOd63UiRYzGk9CNG44QwQLUD TLlA== X-Gm-Message-State: AN3rC/747MvweyH44S9HU1NOW0jVx6NZVntHrrf6/4sI45uWEVzY/Ydk Gi5aNNOKMrN3nyH6ce7Ep6j/Y9Q5ig== X-Received: by 10.46.97.26 with SMTP id v26mr9895587ljb.33.1493072220316; Mon, 24 Apr 2017 15:17:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Mon, 24 Apr 2017 15:16:59 -0700 (PDT) In-Reply-To: References: <1989fd9d-d76c-bc0c-dce0-de47a76fe94c@objectiveintegration.uk> From: Martin Thomson Date: Tue, 25 Apr 2017 08:16:59 +1000 Message-ID: To: Eric Rescorla Cc: Mark Dunn , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] TLS: Cryptographic Computations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 22:17:04 -0000 On 24 April 2017 at 22:38, Eric Rescorla wrote: > You might find it helpful to refer to: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ > > Which contains test vectors. Caveat: that is specific to -18. NSS hasn't been fully updated to support -19 and until it does I won't be able to update the draft. From nobody Mon Apr 24 15:17:35 2017 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 DCF1613194B for ; Mon, 24 Apr 2017 15:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 y9piT0nzotAO for ; Mon, 24 Apr 2017 15:17:32 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE6713192A for ; Mon, 24 Apr 2017 15:17:32 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3OMHP8Q014050; Mon, 24 Apr 2017 23:17:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=2QY5QdImdbezMFpc3EbBD6gNdEbNBlILHcvzaoDJRZk=; b=eRzFXbaDPL9beKugE07/lQ3K6i7waSmdA4lZ6aPBl/wSXaS81NsynQ/usH2TllUCO0mv 78ck68DtiOLeiV0pEGJqoAyZ+OkavVb2aylizGctNsLfGYbO5iY20nLPocXfyQuAOXDp heZdTsHQTVXXLSexDU4anxhzP3zS0o2nXcIddghAsvS8VgK+2ZZwD8Q1cFsI/DeiRQvw zapmwleG52yVnTLvIxQTRZIQ6RKFz9vBmn/wLVVW3CvRuU4iMJi87nJB+7WgiKI0FfxM 9mPulqBmWxVwqq7yQrtRJEbZsxrxYr+uLpRBkUewho8ayZ09f0QPpEb5fBCuWEv0liIU nQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2a1q1q94wx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2017 23:17:26 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3OMFpel006718; Mon, 24 Apr 2017 18:17:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a02guua9m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2017 18:17:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Apr 2017 18:17:22 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 24 Apr 2017 18:17:22 -0400 From: "Salz, Rich" To: "Kaduk, Ben" , Eric Rescorla , "Dave Garrett" CC: "tls@ietf.org" Thread-Topic: [TLS] Issue #964: Shortened HKDF labels Thread-Index: AQHSvPpkCeHdU9jaQ0OMY+O6eLmi+6HU5ssAgAABLICAAA1YgIAABn0AgABIEwCAABLDgIAAATiA//+/NxA= Date: Mon, 24 Apr 2017 22:17:22 +0000 Message-ID: <54c33bda78ca4f62bcc13bfe7ddccbce@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170424161619.GA18783@LK-Perkele-V2.elisa-laajakaista.fi> <201704241657.30874.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.94] Content-Type: multipart/alternative; boundary="_000_54c33bda78ca4f62bcc13bfe7ddccbceusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-24_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704240371 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-24_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704240371 Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 22:17:34 -0000 --_000_54c33bda78ca4f62bcc13bfe7ddccbceusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Using a registry also prevents conflicts. --_000_54c33bda78ca4f62bcc13bfe7ddccbceusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Using a registry also prevents con= flicts.

--_000_54c33bda78ca4f62bcc13bfe7ddccbceusma1exdag1mb1msgcorpak_-- From nobody Mon Apr 24 16:21:58 2017 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 DB01213195F for ; Mon, 24 Apr 2017 16:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 s57PvXc-hwVq for ; Mon, 24 Apr 2017 16:21:55 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 7A4E013195A for ; Mon, 24 Apr 2017 16:21:54 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id 6so62584203ybq.2 for ; Mon, 24 Apr 2017 16:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IAhLV/ahzz9VcuOjv6tWjBOu/rR3+zY6F6eqswRkC54=; b=vbBmqE1a8CzIMBqrKAmcM0pKA4lLuksdK/HJm7NJBdjSQdiDNeLYeYmv6Ih5nqxw8Q DSU7NyyDcXmftqEr48bcXtpHO7+/2mjH1hZ9D/nW2ck7D6p/E3UfWwkH8w9WAQbGbgmN 6R2Zlynj5Vkc4LYsgJm1EPTAtWqR3OUmXQd5V6orfzkFh1+ZQzxc2IGG7YkSSTXPSlbX 5Akfs/o0NdgRbhjeKvwSPB34kaGi+QRYw7yg06Jzj/SeHhO5dB0N7rN1Wo1LsO8uKX4u 9/zD5RqsOHGV2H/kpaAYeBQhqI/ipDoOgJi9h0ACCby4OBfE1oLMDWsGjefoyssSYLtD 60XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IAhLV/ahzz9VcuOjv6tWjBOu/rR3+zY6F6eqswRkC54=; b=mqk1NpCv8+gK/oYWg4yLJnZ2mh34lWMkf3AgLkxahjyZA9jRF1RPHqTxal2ttDtQkK QR/HK8oLNJW/NcpVHyjXGdlZbVhf4gQGtP3Ze/HZY4c+YEfSDl5RXwHZ7qwEiViZWVEQ dESKOBPRZC7ymxcGWcgv+EiVSyDZzMpr0JqRMdYbTsD7UV5iEftmDMHCw/oxL2BfQ1wP NZyEdR2LqnGDoZRecoIbVPoL7QbjBwq2kdqprie5jtwXJmKj0+L0gL3fN41L/EABFWM0 4tH2Kwsb6aNR7RLaH92Z6wRWVorxnm66xNomdpKgb4JZ0fngLWASw1hhtn3dT7mKLurG XtvA== X-Gm-Message-State: AN3rC/4mbs+iH4IvhyqLVAJs0XhBSH6AmeaBFzUzmAlnI/jHe/OofHab sY15IOzqgsQzQd2PhwAIe5PeADq/WJd3 X-Received: by 10.37.78.195 with SMTP id c186mr6703853ybb.180.1493076113682; Mon, 24 Apr 2017 16:21:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 24 Apr 2017 16:21:13 -0700 (PDT) In-Reply-To: References: <20170424152422.GA18543@LK-Perkele-V2.elisa-laajakaista.fi> <20170424161619.GA18783@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 24 Apr 2017 16:21:13 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113e88fa611371054df1dfd5 Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 23:21:57 -0000 --001a113e88fa611371054df1dfd5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Based on Ilari's comments, it seems like we just lost 9 bytes, and the TLS 1.3, label was 9 bytes, so these cancel each other out and we have a total of 18 bytes to work with, including the label. Hence, the following proposal for the complete label, where the longest string is 18 bytes. 16 tls13 ext binder # was external psk binder key 16 tls13 res binder # was resumption psk binder key 17 tls13 c e traffic # was client early traffic secret 18 tls13 e exp master # was early exporter master secret 18 tls13 c hs traffic # was client handshake traffic secret 18 tls13 s hs traffic # was server handshake traffic secret 18 tls13 c ap traffic # was client application traffic secret 18 tls13 s ap traffic # was server application traffic secret 16 tls13 exp master # was exporter master secret 16 tls13 res master # was resumption master secret 9 tls13 key # was key 8 tls13 iv # was iv 14 tls13 finished # was finished 17 tls13 traffic upd # was application traffic secret 14 tls13 exporter # was exporter 13 tls13 derived # was derived Further bikeshedding? -Ekr On Mon, Apr 24, 2017 at 9:39 AM, Eric Rescorla wrote: > Nice catch. > > 9 bytes seems a bit cramped. What I suggest here is that we remove the > "TLS 1.3, ", as it was just there by analogy to the handshake context and > then we are back to having 18 bytes. > > If people feel like we should have some "TLS" prefix, I think "TLS " woul= d > be enough, giving us 1 bytes. > > -Ekr > > > > On Mon, Apr 24, 2017 at 9:16 AM, Ilari Liusvaara > wrote: > >> On Mon, Apr 24, 2017 at 08:28:33AM -0700, Eric Rescorla wrote: >> > On Mon, Apr 24, 2017 at 8:24 AM, Ilari Liusvaara < >> ilariliusvaara@welho.com> >> > wrote: >> > >> > > On Mon, Apr 24, 2017 at 05:56:58AM -0700, Eric Rescorla wrote: >> > > > https://github.com/tlswg/tls13-spec/issues/964 >> > > > >> > > > Here is a proposed set of new labels, which, while slightly less >> clear, >> > > all >> > > > fit >> > > > into the 18 byte limit which Ilari (and I agree) says is what we >> have. >> >> Aargh, turns out that Merke-Damg=C3=A5rd strengthening probably affects >> things... >> >> For SHA-256, MD strengthening consists of padding bit and 64-bit >> message bit count, for total of 65-512 bits of padding. >> >> Trying to construct the raw SHA-256 message words for inner hash with >> 9 byte label (K is key, L is label, H is hash). >> >> KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK >> 36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636 >> 00201254 4C532031 2E332C20 LLLLLLLL LLLLLLLL LL20HHHH HHHHHHHH HHHHHHHH >> HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHH0180 00000000 000003B8 >> >> Adding 10th byte to label seems to blow the block (0x3C0=3D1*512+448): >> >> KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK >> 36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636 >> 00201354 4C532031 2E332C20 LLLLLLLL LLLLLLLL LLLL20HH HHHHHHHH HHHHHHHH >> HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHH01 80000000 00000000 >> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000003C0 >> >> >> For comparision, with SHA-384, the blocks for 9-byte label seem to be: >> >> KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK >> KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK 3636363636363636 3636363636363636 >> 3636363636363636 3636363636363636 3636363636363636 3636363636363636 >> 3636363636363636 3636363636363636 3636363636363636 3636363636363636 >> 003012544C532031 2E332C20LLLLLLLL LLLLLLLLLL30HHHH HHHHHHHHHHHHHHHH >> HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH >> HHHHHHHHHHHH0180 0000000000000000 0000000000000000 0000000000000000 >> 0000000000000000 0000000000000000 0000000000000000 0000000000000638 >> >> (Which has 327 hash block padding bits). >> >> >> -Ilari >> > > --001a113e88fa611371054df1dfd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based on Ilari's comments, it seems like we just = lost 9 bytes, and the TLS 1.3, label was 9 bytes, so these cancel each othe= r out and we have a total of 18 bytes to work with, including the label.

Hence, the following proposal for the complete label= , where the longest string is 18 bytes.

=
16 tls13 ext binder =C2=A0 =C2=A0# =C2=A0was external psk binder = key
16 tls13 res binder =C2=A0 =C2=A0# =C2=A0was resumption psk b= inder key
17 tls13 c e traffic =C2=A0 =C2=A0# =C2=A0was client ea= rly traffic secret
18 tls13 e exp master =C2=A0 =C2=A0# =C2=A0was= early exporter master secret
18 tls13 c hs traffic =C2=A0 =C2=A0= # =C2=A0was client handshake traffic secret
18 tls13 s hs traffic= =C2=A0 =C2=A0# =C2=A0was server handshake traffic secret
18 tls1= 3 c ap traffic =C2=A0 =C2=A0# =C2=A0was client application traffic secret
18 tls13 s ap traffic =C2=A0 =C2=A0# =C2=A0was server application = traffic secret
16 tls13 exp master =C2=A0 =C2=A0# =C2=A0was expor= ter master secret
16 tls13 res master =C2=A0 =C2=A0# =C2=A0was re= sumption master secret
9 tls13 key =C2=A0 =C2=A0# =C2=A0was key
8 tls13 iv =C2=A0 =C2=A0# =C2=A0was iv
14 tls13 finished= =C2=A0 =C2=A0# =C2=A0was finished
17 tls13 traffic upd =C2=A0 = =C2=A0# =C2=A0was application traffic secret
14 tls13 exporter = =C2=A0 =C2=A0# =C2=A0was exporter
13 tls13 derived =C2=A0 =C2=A0#= =C2=A0was derived

Further= bikeshedding?

-Ekr


On Mon, Apr 24, 2017 = at 9:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Nice catch.

9 bytes se= ems a bit cramped. What I suggest here is that we remove the "TLS 1.3,= ", as it was just there by analogy to the handshake context and then = we are back to having 18 bytes.

If people feel lik= e we should have some "TLS" prefix, I think "TLS " woul= d be enough, giving us 1 bytes.

-Ekr


On Mon, Apr 24, 2017 at = 9:16 AM, Ilari Liusvaara <ilariliusvaara@welho.com> w= rote:
On Mon, Apr 24, 2017 at 08:28= :33AM -0700, Eric Rescorla wrote:
> On Mon, Apr 24, 2017 at 8:24 AM, Ilari Liusvaara <ilariliusvaara@welho.com&g= t;
> wrote:
>
> > On Mon, Apr 24, 2017 at 05:56:58AM -0700, Eric Rescorla wrote: > > > https://github.com/tlswg/tls13-spe= c/issues/964
> > >
> > > Here is a proposed set of new labels, which, while slightly = less clear,
> > all
> > > fit
> > > into the 18 byte limit which Ilari (and I agree) says is wha= t we have.

Aargh, turns out that Merke-Damg=C3=A5rd strengthening probably affe= cts
things...

For SHA-256, MD strengthening consists of padding bit and 64-bit
message bit count, for total of 65-512 bits of padding.

Trying to construct the raw SHA-256 message words for inner hash with
9 byte label (K is key, L is label, H is hash).

KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK
36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636
00201254 4C532031 2E332C20 LLLLLLLL LLLLLLLL LL20HHHH HHHHHHHH HHHHHHHH
HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHH0180 00000000 000003B8

Adding 10th byte to label seems to blow the block (0x3C0=3D1*512+448):

KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK KKKKKKKK
36363636 36363636 36363636 36363636 36363636 36363636 36363636 36363636
00201354 4C532031 2E332C20 LLLLLLLL LLLLLLLL LLLL20HH HHHHHHHH HHHHHHHH
HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHHHH HHHHHH01 80000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 000003C0


For comparision, with SHA-384, the blocks for 9-byte label seem to be:

KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK
KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK 3636363636363636 3636363636363636
3636363636363636 3636363636363636 3636363636363636 3636363636363636
3636363636363636 3636363636363636 3636363636363636 3636363636363636
003012544C532031 2E332C20LLLLLLLL LLLLLLLLLL30HHHH HHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHH
HHHHHHHHHHHH0180 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000638

(Which has 327 hash block padding bits).


-Ilari


--001a113e88fa611371054df1dfd5-- From nobody Mon Apr 24 16:29:17 2017 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 84D63131962 for ; Mon, 24 Apr 2017 16:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 xGNcvs-c-GRl for ; Mon, 24 Apr 2017 16:29:14 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 249A1131960 for ; Mon, 24 Apr 2017 16:29:14 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6628043346C; Mon, 24 Apr 2017 23:29:13 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 3DB1543342C; Mon, 24 Apr 2017 23:29:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493076553; bh=GjUwdxokuKdgCWJab7Jp5Kn/2yiHvb8gJCR3Y7bB9cw=; l=3586; h=To:References:Cc:From:Date:In-Reply-To:From; b=s/H0FRjsJZU3+NYe9A833U4HpnGZxgdb+7I88ZRJ88RVHaBmCUVqBpV1iKqGaEFDu x4SvNrFFilOyqWq3LT73kpnS/4yRGBupiVZ0+tHuiQP0Bbygc5nY70w3XNR/+0366D +V/npm/DrM6bZ2XdoNEVYxwcwu7uYKtOWTn+ogXM= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id F044B1FCA0; Mon, 24 Apr 2017 23:29:12 +0000 (GMT) To: Eric Rescorla , Ilari Liusvaara References: <20170424152422.GA18543@LK-Perkele-V2.elisa-laajakaista.fi> <20170424161619.GA18783@LK-Perkele-V2.elisa-laajakaista.fi> Cc: "tls@ietf.org" From: Benjamin Kaduk Message-ID: <9e60149e-65bb-d122-68dd-a17081e26247@akamai.com> Date: Mon, 24 Apr 2017 18:29:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7782EF314DCB4A8265E7D36A" Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 24 Apr 2017 23:29:15 -0000 This is a multi-part message in MIME format. --------------7782EF314DCB4A8265E7D36A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/24/2017 06:21 PM, Eric Rescorla wrote: > Based on Ilari's comments, it seems like we just lost 9 bytes, and the > TLS 1.3, label was 9 bytes, so these cancel each other out and we have > a total of 18 bytes to work with, including the label. > > Hence, the following proposal for the complete label, where the > longest string is 18 bytes. > > 16 tls13 ext binder # was external psk binder key > 16 tls13 res binder # was resumption psk binder key > 17 tls13 c e traffic # was client early traffic secret > 18 tls13 e exp master # was early exporter master secret > 18 tls13 c hs traffic # was client handshake traffic secret > 18 tls13 s hs traffic # was server handshake traffic secret > 18 tls13 c ap traffic # was client application traffic secret > 18 tls13 s ap traffic # was server application traffic secret > 16 tls13 exp master # was exporter master secret > 16 tls13 res master # was resumption master secret > 9 tls13 key # was key > 8 tls13 iv # was iv > 14 tls13 finished # was finished > 17 tls13 traffic upd # was application traffic secret > 14 tls13 exporter # was exporter > 13 tls13 derived # was derived > > Further bikeshedding? I had something more olive-ish puce in mind ... but this is fine; ship it. -Ben --------------7782EF314DCB4A8265E7D36A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/24/2017 06:21 PM, Eric Rescorla wrote:
Based on Ilari's comments, it seems like we just lost 9 bytes, and the TLS 1.3, label was 9 bytes, so these cancel each other out and we have a total of 18 bytes to work with, including the label.

Hence, the following proposal for the complete label, where the longest string is 18 bytes.

16 tls13 ext binder    #  was external psk binder key
16 tls13 res binder    #  was resumption psk binder key
17 tls13 c e traffic    #  was client early traffic secret
18 tls13 e exp master    #  was early exporter master secret
18 tls13 c hs traffic    #  was client handshake traffic secret
18 tls13 s hs traffic    #  was server handshake traffic secret
18 tls13 c ap traffic    #  was client application traffic secret
18 tls13 s ap traffic    #  was server application traffic secret
16 tls13 exp master    #  was exporter master secret
16 tls13 res master    #  was resumption master secret
9 tls13 key    #  was key
8 tls13 iv    #  was iv
14 tls13 finished    #  was finished
17 tls13 traffic upd    #  was application traffic secret
14 tls13 exporter    #  was exporter
13 tls13 derived    #  was derived

Further bikeshedding?

I had something more olive-ish puce in mind ... but this is fine; ship it.

-Ben
--------------7782EF314DCB4A8265E7D36A-- From nobody Mon Apr 24 18:09:00 2017 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 5D894131989 for ; Mon, 24 Apr 2017 18:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HEVTg3XpudlI for ; Mon, 24 Apr 2017 18:08:57 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 50A3913198A for ; Mon, 24 Apr 2017 18:08:57 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id c45so128441689qtb.1 for ; Mon, 24 Apr 2017 18:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=+75XDVrXtKuI2XLiwmlu/phLUINHNSJGSGMpGwn4CAk=; b=pkqQj0bwvV0b22C8FfvirMtWZ0t2AEuRkfDtHX31t1KLr18KVDNHKCgs1Od0D2dc5p LNEjnG7WRPNsUZMp3QM/Qu6hlfINWS0hfjF20UHkviC7u3NJBeePYcJ5mny/m9wdSTeP MMvrHVy5uQ0f1E8O/yX5MEI3HoaetpB+6kTZjyQjVRVsXwmaVmmRF5NXcQAcd6TlzjJX ds9eIibjZIUfxI822FONzoT7ww5E+l3lACftVhTFmxSLxKqGSYOF832QS2FfLdr75bBg TUOi7QQw5qpKu+/MephWxFKJhDeUyWAZZf9j98dOLbYiPcUibufH85pcnvrC1ydOxtUL aOIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=+75XDVrXtKuI2XLiwmlu/phLUINHNSJGSGMpGwn4CAk=; b=qYCjtMlmzMg/lrRQZSinyKvrEaufarXWLQ4PK1a34hQI2y0EbtBV6YwTHJqylV69Mk /dFblKhvw6bWbqkNkpDEBrf7Eq+/MKw+bkjMGLm+jsMEIt3d/y3N1BMKkmJ0dPpyaSnC oONNZaxAPOsBZ3CVHKJ7ghqkwqyqfUm4/Hjs8PHo3nwW5NPTigtmy07WvQQXjjoxkPj+ nvu87KzdGclBmUN0L+YUzzN1otnx9xXXVJyQDFec/wl/iTRbisPorLTW5pc7zTs9otr1 WbsmiUNB5tQpU+xKybvzm0tS8Skp1A91JrBXsPlYE4fcJd3uk52tllCPelK/wcN6etJ2 /d3w== X-Gm-Message-State: AN3rC/4iWEXl9IV/SAAO33e9PPu0y+hoKpmNHYxbfA6vtUutiL31vJMK tLTq6otoFMzcpxSt X-Received: by 10.200.48.90 with SMTP id g26mr32097595qte.79.1493082536305; Mon, 24 Apr 2017 18:08:56 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-36-197.phlapa.fios.verizon.net. [71.185.36.197]) by smtp.gmail.com with ESMTPSA id m12sm14138703qtf.2.2017.04.24.18.08.55 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 24 Apr 2017 18:08:55 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 24 Apr 2017 21:08:53 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201704242108.54252.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2017 01:08:59 -0000 On Monday, April 24, 2017 07:21:13 pm Eric Rescorla wrote: > Hence, the following proposal for the complete label, where the longest > string is 18 bytes. > > 16 tls13 ext binder # was external psk binder key > 16 tls13 res binder # was resumption psk binder key > 17 tls13 c e traffic # was client early traffic secret > 18 tls13 e exp master # was early exporter master secret > 18 tls13 c hs traffic # was client handshake traffic secret > 18 tls13 s hs traffic # was server handshake traffic secret > 18 tls13 c ap traffic # was client application traffic secret > 18 tls13 s ap traffic # was server application traffic secret > 16 tls13 exp master # was exporter master secret > 16 tls13 res master # was resumption master secret > 9 tls13 key # was key > 8 tls13 iv # was iv > 14 tls13 finished # was finished > 17 tls13 traffic upd # was application traffic secret > 14 tls13 exporter # was exporter > 13 tls13 derived # was derived > > Further bikeshedding? I think "tls13 c e traffic" is the only one that could be tweaked to be a little more obvious. Abbreviating "early data" as "ed", instead of just "early" as "e", would still fit and follow the same pattern as the other traffic labels. Other than that, this sounds fine. Dave From nobody Mon Apr 24 20:13:15 2017 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 CDB15129416 for ; Mon, 24 Apr 2017 20:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 9cCsy5swbYZx for ; Mon, 24 Apr 2017 20:13:12 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 901A61315D7 for ; Mon, 24 Apr 2017 20:13:12 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id 6so63456217ybq.2 for ; Mon, 24 Apr 2017 20:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nkEQ/nQL6la4BzU7ZmwHZJj/Kokco0/69B5/7yJsnME=; b=cwnmWMPvK/K/fPIiCNVOvza0ui80mPQsACoi1kFcMra7BWazu8b0IV4Wt7RNoCJAAK XnpsadoYI5sD2cctrC6KFFd8i1wG3pYm4BBRgR6M4hYBDiLow8dyzcOC1jJB9uekMkrF I66dAIgUB9x6mRzf5WqBeifwlDtE9H0V28ZEypdrlOtOKp0BguPnZqhKCsjYPMgB/r4O dFKuhfWz1RxQnDBM4IEMAY5NgjeWJ3eTBQ2a/p5e6VNu1bjGpmJG4bE6eHr7zYCt7i7l T6ZQ67I8nSeCmpARxgzr34NsyjrsX1r01juxFjfHMER+TwPWEFHCEztzrdkvERoyaLNQ yyuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nkEQ/nQL6la4BzU7ZmwHZJj/Kokco0/69B5/7yJsnME=; b=F2MH5kHjh79QBeOM+M/1k82slR7zn01kqpyVm4U4vNNDDwN6+6JvZyAU0jrBhnWW9t Cg3AQArRIv04ZiiPj45JAkWlnO6iAFj9Im9z9LMKStNCtPO+5Rz+GklZezoZw97QNs7E nUWpcUmGaDyFZ8370bpmaNgwGTuK1F1zP+/UZRB6sDOnpkhANgRjyGNzUzScsqnpR2TK XyVMq0XZshTi30SR5Bi2UgsUcHgyON6vBi2/vWbqSzmnGoktypqjbw9oPN3nVPWguD+p Jls8cQQdNVha852/YXeiRnMUxslNiQGnijk9SL6v4m5OdSQKLvS68mjbZdlkYxdieHe+ R3ig== X-Gm-Message-State: AN3rC/782WDJZqYMRLBWQ5UNrDz9B7nqgb05Q/CXWs6XM5hapqgpJorE /6CJ3Gc9DWU6IBSzWfzihjY1xpJuyQ== X-Received: by 10.37.173.131 with SMTP id z3mr7549796ybi.64.1493089991750; Mon, 24 Apr 2017 20:13:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 24 Apr 2017 20:12:31 -0700 (PDT) In-Reply-To: <201704242108.54252.davemgarrett@gmail.com> References: <201704242108.54252.davemgarrett@gmail.com> From: Eric Rescorla Date: Mon, 24 Apr 2017 20:12:31 -0700 Message-ID: To: Dave Garrett Cc: "tls@ietf.org" , Ilari Liusvaara Content-Type: multipart/alternative; boundary=f403045dbc2293ab5c054df51afe Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2017 03:13:14 -0000 --f403045dbc2293ab5c054df51afe Content-Type: text/plain; charset=UTF-8 On Mon, Apr 24, 2017 at 6:08 PM, Dave Garrett wrote: > On Monday, April 24, 2017 07:21:13 pm Eric Rescorla wrote: > > Hence, the following proposal for the complete label, where the longest > > string is 18 bytes. > > > > 16 tls13 ext binder # was external psk binder key > > 16 tls13 res binder # was resumption psk binder key > > 17 tls13 c e traffic # was client early traffic secret > > 18 tls13 e exp master # was early exporter master secret > > 18 tls13 c hs traffic # was client handshake traffic secret > > 18 tls13 s hs traffic # was server handshake traffic secret > > 18 tls13 c ap traffic # was client application traffic secret > > 18 tls13 s ap traffic # was server application traffic secret > > 16 tls13 exp master # was exporter master secret > > 16 tls13 res master # was resumption master secret > > 9 tls13 key # was key > > 8 tls13 iv # was iv > > 14 tls13 finished # was finished > > 17 tls13 traffic upd # was application traffic secret > > 14 tls13 exporter # was exporter > > 13 tls13 derived # was derived > > > > Further bikeshedding? > > I think "tls13 c e traffic" is the only one that could be tweaked to be a > little more obvious. Abbreviating "early data" as "ed", instead of just > "early" as "e", would still fit and follow the same pattern as the other > traffic labels. > Unfortunately this woud explode tls13 e exp master. -Ekr Other than that, this sounds fine. > > > Dave > --f403045dbc2293ab5c054df51afe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 24, 2017 at 6:08 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Monday, April 24, 2017 07:21:13 pm Eric Rescorla wrote:
> Hence, the following proposal for the complete label, where the longes= t
> string is 18 bytes.
>
> 16 tls13 ext binder=C2=A0 =C2=A0 #=C2=A0 was external psk binder key > 16 tls13 res binder=C2=A0 =C2=A0 #=C2=A0 was resumption psk binder key=
> 17 tls13 c e traffic=C2=A0 =C2=A0 #=C2=A0 was client early traffic sec= ret
> 18 tls13 e exp master=C2=A0 =C2=A0 #=C2=A0 was early exporter master s= ecret
> 18 tls13 c hs traffic=C2=A0 =C2=A0 #=C2=A0 was client handshake traffi= c secret
> 18 tls13 s hs traffic=C2=A0 =C2=A0 #=C2=A0 was server handshake traffi= c secret
> 18 tls13 c ap traffic=C2=A0 =C2=A0 #=C2=A0 was client application traf= fic secret
> 18 tls13 s ap traffic=C2=A0 =C2=A0 #=C2=A0 was server application traf= fic secret
> 16 tls13 exp master=C2=A0 =C2=A0 #=C2=A0 was exporter master secret > 16 tls13 res master=C2=A0 =C2=A0 #=C2=A0 was resumption master secret<= br> > 9 tls13 key=C2=A0 =C2=A0 #=C2=A0 was key
> 8 tls13 iv=C2=A0 =C2=A0 #=C2=A0 was iv
> 14 tls13 finished=C2=A0 =C2=A0 #=C2=A0 was finished
> 17 tls13 traffic upd=C2=A0 =C2=A0 #=C2=A0 was application traffic secr= et
> 14 tls13 exporter=C2=A0 =C2=A0 #=C2=A0 was exporter
> 13 tls13 derived=C2=A0 =C2=A0 #=C2=A0 was derived
>
> Further bikeshedding?

I think "tls13 c e traffic" is the only one that could be = tweaked to be a little more obvious. Abbreviating "early data" as= "ed", instead of just "early" as "e", would = still fit and follow the same pattern as the other traffic labels.

Unfortunately this woud explode tls13 e exp mas= ter.

-Ekr

Other than that, this sounds fine.


Dave

--f403045dbc2293ab5c054df51afe-- From nobody Tue Apr 25 02:50:11 2017 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 04407129C1E for ; Tue, 25 Apr 2017 02:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 CiYafKMiVIZn for ; Tue, 25 Apr 2017 02:50:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0EF126D85 for ; Tue, 25 Apr 2017 02:50:08 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F414D61D04; Tue, 25 Apr 2017 09:50:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F414D61D04 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com F414D61D04 Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.2.129]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E2E3D8367A; Tue, 25 Apr 2017 09:50:06 +0000 (UTC) Message-ID: <1493113805.15667.7.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Ryan Sleevi Cc: Ilari Liusvaara , "tls@ietf.org" Date: Tue, 25 Apr 2017 11:50:05 +0200 In-Reply-To: References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> <1493020692.3390.8.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 25 Apr 2017 09:50:08 +0000 (UTC) Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2017 09:50:10 -0000 On Mon, 2017-04-24 at 09:26 -0400, Ryan Sleevi wrote: > > > On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos .com> wrote: > > That's intentional.  > > And misguided. It violates the layering. That's a respectable opinion. I disagree. > > The reason they > > cannot be expected to do that, is that it is not by way obvious > > what to > > do. Ilari's implentation closes the connection, mine sets a limit > > of 15 > > days, and I guess each and every other one behaves differently. It > > is > > the role of the standards to clarify uncertainties for implementers > > or > > forbid such options (I'd equally be happy if we have a text that > > forbids an empty nextUpdate field in OCSP responses to be used in > > the > > context of TLS 1.3 ocsp stapling). > > Can you point to where the spec supports your behaviours? That is, > where it's a valid reading of the spec to close the connection or to > set a limit of 15 days. > > The point is that it's not a valid reading of the spec. It is, > instead, an application profile. And that's great. I don't think > anyone would realistically be arguing that applications or other > specifications cannot profile the spec to their needs. While I remain > unconvinced that TLS is the right thing, what you're describing here > is simply a decision you've made for your community. That doesn't > mean that because you and Ilari have made different decisions, that > should be imposed on the spec. >   > > >  Given that stapling "issues" exist even without stapling, it > > does > > > seem an unnecessary reach to include within the spec. > > > > There is a usability and interoperability issue there.  > > Not within the spec. Within the profile you've done for your > community. So you point is that as long as you don't use OCSP responses there is no interoperability issue. That's very interesting point. More interestingly you delegate that definition to an application profile. Could you refer to such application profiles for TLS which define how OCSP responses are to be used? regards, Nikos From nobody Tue Apr 25 05:08:13 2017 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 10F6412EC5B for ; Tue, 25 Apr 2017 05:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] 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 SdkzRJacZ54C for ; Tue, 25 Apr 2017 05:08:09 -0700 (PDT) Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1D95312869B for ; Tue, 25 Apr 2017 05:08:08 -0700 (PDT) Received: from host86-133-145-70.range86-133.btcentralplus.com ([86.133.145.70]:62822 helo=[192.168.1.64]) by relay02.mail.eu.clara.net (relay.clara.net [81.171.239.32]:10465) with esmtpa (authdaemon_plain:drh) id 1d2zGE-0003xI-7O for tls@ietf.org (return-path ); Tue, 25 Apr 2017 12:08:03 +0000 To: tls@ietf.org References: <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk> From: Dr Stephen Henson Message-ID: Date: Tue, 25 Apr 2017 13:08:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2017 12:08:11 -0000 On 18/02/2017 02:31, Dr Stephen Henson wrote: > > Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity > certificates too? > > For example could a TLS 1.2 server legally present a certificate containing an > RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present > a certificate contain an RSASSA-PSS key? > I can't recall getting a definitive answer to this. IMHO we should make the requirements clear in the spec otherwise we could get interop issues. Based on the opinions stated in this thread that would be: 1. When PSS signatures appear certificates, MGF digest and signing digest MUST match and the salt length must equal the digest length. 2. Indicate that the PSS only (id-RSASSA-PSS) and RSA (rsaEncryption) keys MUST be supported both as server keys and CA keys in certificates. 3. PSS only keys MUST be supported for TLS 1.2 also. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Tue Apr 25 07:39:28 2017 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 7E301131533 for ; Tue, 25 Apr 2017 07:39:26 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 xNiupLYtPoD7 for ; Tue, 25 Apr 2017 07:39:24 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 19F67131472 for ; Tue, 25 Apr 2017 07:36:30 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 896DB16C8F1; Tue, 25 Apr 2017 14:36:29 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 6974616C8EB; Tue, 25 Apr 2017 14:36:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493130989; bh=Oi2PKk/PmGkjhpVInoScUK0zrGmo2zwTwZea0mMy8DM=; l=5991; h=To:References:From:Date:In-Reply-To:From; b=JIMOL2PHBwqUQcNNTE9GMGHG/xwskfr6vepLtv/ccFmJJckls0PxQaPfZhcx8+KKh QV42u0p0zVTPHc/zteqm3ALRIBhnGmol+a7fLrfW94f3sKtcwIJcXpTUioBwfVbZ6b w0KJXBmrz1apXSON7fQ2Etd04o7V+M7FzLbdn0vE= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 180311E33C; Tue, 25 Apr 2017 14:36:28 +0000 (GMT) To: Dr Stephen Henson , tls@ietf.org References: <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <05dc96c4-900b-6237-e008-ae8364fffe65@akamai.com> Date: Tue, 25 Apr 2017 09:36:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CD5C658AC67C0F940310A322" Archived-At: Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2017 14:39:26 -0000 This is a multi-part message in MIME format. --------------CD5C658AC67C0F940310A322 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/25/2017 07:08 AM, Dr Stephen Henson wrote: > On 18/02/2017 02:31, Dr Stephen Henson wrote: >> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity >> certificates too? >> >> For example could a TLS 1.2 server legally present a certificate containing an >> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present >> a certificate contain an RSASSA-PSS key? >> > I can't recall getting a definitive answer to this. IMHO we should make the > requirements clear in the spec otherwise we could get interop issues. > > Based on the opinions stated in this thread that would be: > > 1. When PSS signatures appear certificates, MGF digest and signing digest MUST > match and the salt length must equal the digest length. We have (in section 4.2.3, Signature Algorithms): RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA- PSS [RFC3447 ] with mask generation function 1. The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in [SHS ]. When used in signed TLS handshake messages, the length of the salt MUST be equal to the length of the digest output. This codepoint is also defined for use with TLS 1.2. Is the concern that this is insufficiently clearly indicated as placing requirements on signatures of certificates as opposed to signatures of TLS data structures? > 2. Indicate that the PSS only (id-RSASSA-PSS) and RSA (rsaEncryption) keys MUST > be supported both as server keys and CA keys in certificates. Similarly to (1), I believe that it is possible to read the existing (draft-19) text as making these requirements already, so is the concern that the text needs to be more clear? > 3. PSS only keys MUST be supported for TLS 1.2 also. > Section 1.3, "Updates Affecting TLS 1.2" notes: [...] - RSASSA-PSS signature schemes are defined in Section 4.2.3 . An implementation of TLS 1.3 that also supports TLS 1.2 might need to include changes to support these changes even when TLS 1.3 is not in use. See the referenced sections for more details. -Ben --------------CD5C658AC67C0F940310A322 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/25/2017 07:08 AM, Dr Stephen Henson wrote:
On 18/02/2017 02:31, Dr Stephen Henson wrote:

Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
certificates too?

For example could a TLS 1.2 server legally present a certificate containing an
RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
a certificate contain an RSASSA-PSS key?


I can't recall getting a definitive answer to this. IMHO we should make the
requirements clear in the spec otherwise we could get interop issues.

Based on the opinions stated in this thread that would be:

1. When PSS signatures appear certificates, MGF digest and signing digest MUST
match and the salt length must equal the digest length.

We have (in section 4.2.3, Signature Algorithms):

   RSASSA-PSS algorithms  Indicates a signature algorithm using RSASSA-
      PSS [RFC3447] with mask generation function 1.  The digest used in
      the mask generation function and the digest being signed are both
      the corresponding hash algorithm as defined in [SHS].  When used
      in signed TLS handshake messages, the length of the salt MUST be
      equal to the length of the digest output.  This codepoint is also
      defined for use with TLS 1.2.


Is the concern that this is insufficiently clearly indicated as placing requirements on signatures of certificates as opposed to signatures of TLS data structures?



2. Indicate that the PSS only (id-RSASSA-PSS) and RSA (rsaEncryption) keys MUST
be supported both as server keys and CA keys in certificates.

Similarly to (1), I believe that it is possible to read the existing (draft-19) text as making these requirements already, so is the concern that the text needs to be more clear?


3. PSS only keys MUST be supported for TLS 1.2 also.

Section 1.3, "Updates Affecting TLS 1.2" notes:

   [...]
   -  RSASSA-PSS signature schemes are defined in Section 4.2.3.

   An implementation of TLS 1.3 that also supports TLS 1.2 might need to
   include changes to support these changes even when TLS 1.3 is not in
   use.  See the referenced sections for more details.

-Ben

--------------CD5C658AC67C0F940310A322-- From nobody Tue Apr 25 07:59:26 2017 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 3336913158F for ; Tue, 25 Apr 2017 07:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] 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 BfCNyyOncecH for ; Tue, 25 Apr 2017 07:59:22 -0700 (PDT) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by ietfa.amsl.com (Postfix) with ESMTP id DBF811294CD for ; Tue, 25 Apr 2017 07:59:20 -0700 (PDT) Received: from host86-133-145-70.range86-133.btcentralplus.com ([86.133.145.70]:44911 helo=[192.168.1.64]) by relay01.mail.eu.clara.net (relay.clara.net [81.171.239.31]:10465) with esmtpa (authdaemon_plain:drh) id 1d31vq-0004gA-4H (return-path ); Tue, 25 Apr 2017 14:59:13 +0000 To: Benjamin Kaduk , tls@ietf.org References: <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk> <05dc96c4-900b-6237-e008-ae8364fffe65@akamai.com> From: Dr Stephen Henson Message-ID: <926e3b6b-5f0c-e00a-5ba3-9a2cfcdc4e8f@drh-consultancy.co.uk> Date: Tue, 25 Apr 2017 15:59:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <05dc96c4-900b-6237-e008-ae8364fffe65@akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2017 14:59:24 -0000 On 25/04/2017 15:36, Benjamin Kaduk wrote: > On 04/25/2017 07:08 AM, Dr Stephen Henson wrote: >> On 18/02/2017 02:31, Dr Stephen Henson wrote: >>> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity >>> certificates too? >>> >>> For example could a TLS 1.2 server legally present a certificate containing an >>> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present >>> a certificate contain an RSASSA-PSS key? >>> >> I can't recall getting a definitive answer to this. IMHO we should make the >> requirements clear in the spec otherwise we could get interop issues. >> >> Based on the opinions stated in this thread that would be: >> >> 1. When PSS signatures appear certificates, MGF digest and signing digest MUST >> match and the salt length must equal the digest length. > > We have (in section 4.2.3, Signature Algorithms): > > RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA- > PSS [RFC3447 ] with mask generation function 1. The digest used in > the mask generation function and the digest being signed are both > the corresponding hash algorithm as defined in [SHS ]. When used > in signed TLS handshake messages, the length of the salt MUST be > equal to the length of the digest output. This codepoint is also > defined for use with TLS 1.2. > > > Is the concern that this is insufficiently clearly indicated as placing requirements on signatures of certificates as opposed to signatures of TLS data structures? > Yes that's my concern. Supporting PSS signatures on certificates is a mandatory requirement and I think we should be very clear about the parameters we permit. The above paragraph says nothing about salt length limitations on signatures on certificates. We could have a situation where one implementation enforces the salt length to be equal to the digest length (and rejects everything else) and another will allow any valid length. > > >> 2. Indicate that the PSS only (id-RSASSA-PSS) and RSA (rsaEncryption) keys MUST >> be supported both as server keys and CA keys in certificates. > > Similarly to (1), I believe that it is possible to read the existing (draft-19) > text as making these requirements already, so is the concern that the text needs > to be more clear? > Yes. id-RSASSA-PSS isn't mentioned anywhere in the spec. If we require implementations to support this I think we should be explicit about it. We might want to refer to RFC5756/RFC4055 which document the syntax. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Tue Apr 25 10:48:26 2017 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 3CB6913170D for ; Tue, 25 Apr 2017 10:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 LBh4A_XoSzNl for ; Tue, 25 Apr 2017 10:48:24 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E123013013D for ; Tue, 25 Apr 2017 10:48:23 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id C3DADC009F5E for ; Tue, 25 Apr 2017 10:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=sb5ZlQ6iFy6E8gjrieA/2HMde2o=; b= hlgxHPnfb9euzhrmbhtFVtrrdEkUu5aHfjBrfwCfCJsceHWzqM5n4OMDCinvvbhn 3fettd7yiBoMYwzQif8tKClTsdELmYYsEjyknzIqggkILVie36k68sXbQnRjFlln 6oBp9UQu3+TwQjfrM/PXzyRVySoHgXFYMXQ56oUojRo= Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 84512C009F5D for ; Tue, 25 Apr 2017 10:48:22 -0700 (PDT) Received: by mail-lf0-f53.google.com with SMTP id c80so94870158lfh.3 for ; Tue, 25 Apr 2017 10:48:22 -0700 (PDT) X-Gm-Message-State: AN3rC/6CzHIssfHz+ZV6Qzw6d1VOXtDDf0rC612mumLgIa3CfkubKEYZ 5xHHZiRRAfr/tVeLTeT8UR9ED4lH1g== X-Received: by 10.46.20.67 with SMTP id 3mr12746372lju.14.1493142500571; Tue, 25 Apr 2017 10:48:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.165.67 with HTTP; Tue, 25 Apr 2017 10:48:19 -0700 (PDT) In-Reply-To: <1493113805.15667.7.camel@redhat.com> References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <1492786351.14070.2.camel@redhat.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> <1493020692.3390.8.camel@redhat.com> <1493113805.15667.7.camel@redhat.com> From: Ryan Sleevi Date: Tue, 25 Apr 2017 13:48:19 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Nikos Mavrogiannopoulos Cc: Ryan Sleevi , Ilari Liusvaara , "tls@ietf.org" Content-Type: multipart/alternative; boundary=f403045fc1a6588d64054e0154a3 Archived-At: Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2017 17:48:25 -0000 --f403045fc1a6588d64054e0154a3 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 25, 2017 at 5:50 AM, Nikos Mavrogiannopoulos wrote: > > So you point is that as long as you don't use OCSP responses there is > no interoperability issue. That's very interesting point. More > interestingly you delegate that definition to an application profile. > Could you refer to such application profiles for TLS which define how > OCSP responses are to be used? > I would argue that the Web PKI, as practiced by browsers, is one example that is specific to the (publicly trusted CA) ecosystem. In this profile, all major implementations but one (Firefox) allow for stapling an expired response. With the exception of Firefox, when such an expired response is received, they'll (if configured) go obtain a live response. In this respect, PCT got it right - the certificate (and additional inputs, such as OCSP stapling) are inputs to a blackbox which yields a binary response. So, too, should it be for TLS - because in several major clients, that's precisely what it's implemented/exposed as. That's not to say you, for your use case, need to treat it as such. But it highlights the existing disagreement for which using the spec to 'force' clients to a particular viewpoint isn't productive, nor does it meaningfully improve security. --f403045fc1a6588d64054e0154a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 25, 2017 at 5:50 AM, Nikos Mavrogiannopoulos <nmav@redhat.co= m> wrote:

So you point is that as long as you don't use OCSP response= s there is
no interoperability issue. That's very interesting point. More
interestingly you delegate that definition to an application profile.
Could you refer to such application profiles for TLS which define how
OCSP responses are to be used?

I would = argue that the Web PKI, as practiced by browsers, is one example that is sp= ecific to the (publicly trusted CA) ecosystem. In this profile, all major i= mplementations but one (Firefox) allow for stapling an expired response. Wi= th the exception of Firefox, when such an expired response is received, the= y'll (if configured) go obtain a live response.

In this respect, PCT got it right - the certificate (and additional input= s, such as OCSP stapling) are inputs to a blackbox which yields a binary re= sponse. So, too, should it be for TLS - because in several major clients, t= hat's precisely what it's implemented/exposed as. That's not to= say you, for your use case, need to treat it as such. But it highlights th= e existing disagreement for which using the spec to 'force' clients= to a particular viewpoint isn't productive, nor does it meaningfully i= mprove security.=C2=A0
--f403045fc1a6588d64054e0154a3-- From nobody Tue Apr 25 10:57:44 2017 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 C132C1274D0; Tue, 25 Apr 2017 10:57:35 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com header.b=pYUSjlqf; dkim=pass (1024-bit key) header.d=verizon.com header.b=SJdbCI8P; dkim=pass (1024-bit key) header.d=verizon.com header.b=F7oCKYVA 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 Erfzc9O4mr8z; Tue, 25 Apr 2017 10:57:34 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED66131734; Tue, 25 Apr 2017 10:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1493143053; x=1524679053; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fYHzoZsuJR0PFToEAsYEE2efDg2zJctF25Voe3oVSN8=; b=pYUSjlqfXqQoQmPDAOqqK2EU7nifWA46+VrzBWbfsu/3IA1kqXnVsc97 v3faJgDw/1Hjeii/cLvzF4czsoswNQaxAHGi1GprS2/Ozl0ij0IoqWo3Z X9vL0T6amLOxDv2zaBwxQ3Ee6I6Cz3SP3tmuTGZgenlBYVF8uMfyzm0AE w=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe03.verizonbusiness.com with ESMTP; 25 Apr 2017 17:57:27 +0000 X-IronPort-AV: E=Sophos;i="5.37,250,1488844800"; d="scan'208";a="339166651" Received: from rogue-10-255-192-101.rogue.vzwcorp.com (HELO atlantis.verizonwireless.com) ([10.255.192.101]) by fldsmtpi03.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2017 17:56:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1493143013; x=1524679013; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fYHzoZsuJR0PFToEAsYEE2efDg2zJctF25Voe3oVSN8=; b=SJdbCI8PHO+eQd6tf77W8CDs/MDqpPVzK1LL7V1RLhRRLDAT27LznsTf ha7Bxqv+S+aZUdg82JQGF5EbNXRBmc5CdzEXbq4hj000DvLmwZRjRvOdR 8UdN6VSGLWCg+1/4kSAGn6klMJr6pMojZUpuuBeIaK61aS2SUgYcWY5ia 0=; Received: from ranger.odc.vzwcorp.com (HELO mercury.verizonwireless.com) ([10.255.240.27]) by atlantis.verizonwireless.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2017 13:56:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1493143013; x=1524679013; h=to:cc:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:from; bh=fYHzoZsuJR0PFToEAsYEE2efDg2zJctF25Voe3oVSN8=; b=F7oCKYVAUoy1cq2ekBQtlOMnORAQTut2Vt79D+SJeRyvvOxLED93BOac RC9G4v7gpTIjKT0ybmEYxtl9Ks2Roo4NqKA/3T95SbFKdNxZrYkTV7I48 EwhlizTUvznnbqtpykNKUMMG8h6lR19K3YUVdv1cm0YxgU8zLdRXOEZYk Y=; From: sanjay.mishra@verizon.com X-Host: ranger.odc.vzwcorp.com Received: from gaalpexhub1.uswin.ad.vzwcorp.com ([10.191.138.195]) by mercury.verizonwireless.com with ESMTP/TLS/AES256-SHA; 25 Apr 2017 17:56:53 +0000 Received: from OMZP1LUMXCA05.uswin.ad.vzwcorp.com (144.8.22.175) by GAALPEXHUB1.uswin.ad.vzwcorp.com (10.191.138.195) with Microsoft SMTP Server (TLS) id 8.3.406.0; Tue, 25 Apr 2017 13:56:52 -0400 Received: from OMZP1LUMXCA08.uswin.ad.vzwcorp.com (144.8.22.181) by OMZP1LUMXCA05.uswin.ad.vzwcorp.com (144.8.22.175) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 25 Apr 2017 12:56:51 -0500 Received: from OMZP1LUMXCA08.uswin.ad.vzwcorp.com ([144.8.22.181]) by OMZP1LUMXCA08.uswin.ad.vzwcorp.com ([144.8.22.181]) with mapi id 15.00.1263.000; Tue, 25 Apr 2017 12:56:51 -0500 To: Sean Turner , "" CC: "lurk@ietf.org" Thread-Topic: [E] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts Thread-Index: AQHSs8NjdltynQ2yEkOLi1/Q6O7xoqHWbl0g Date: Tue, 25 Apr 2017 17:56:51 +0000 Message-ID: <52a24cbdc02947d8948be0d66e493736@OMZP1LUMXCA08.uswin.ad.vzwcorp.com> References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> In-Reply-To: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.144.60.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [E] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2017 17:57:36 -0000 I have reviewed the draft and I support adoption of this draft. Agree that = both the short-lived certificate and subcerts are addressing a similar issu= e and perhaps tradeoffs can be considered.=20 Thanks Sanjay -----Original Message----- From: Lurk [mailto:lurk-bounces@ietf.org] On Behalf Of Sean Turner Sent: Wednesday, April 12, 2017 3:31 PM To: Cc: lurk@ietf.org Subject: [E] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts All, At our IETF 98 session, there was support in the room to adopt draft-rescor= la-tls-subcerts [0]. We need to confirm this support on the list so please= let the list know whether you support adoption of the draft and are willin= g to review/comment on the draft before 20170429. If you object to its ado= ption, please let us know why. Clearly, the WG is going to need to work through the trade-offs between sho= rt-lived certificates and sub-certs because both seem, to some, to be addre= ssing the same problem.=20 Cheers, J&S [0] https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= .org_doc_html_draft-2Drescorla-2Dtls-2Dsubcerts&d=3DDwICAg&c=3DudBTRvFvXC5D= hqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3D9a_L6t5TdnDThojv7KBKmqsZzTGM6YylS2wfbAO= 9KK0&m=3DjR4l13smzl6mjhJNFZzBEcBkfCAl-bHE1ztPqmR8cSU&s=3D1-VoLJ98RM8Ke0Zyp2= Qad4rw9aXhVeIkqqMVEhfGtuw&e=3D=20 _______________________________________________ Lurk mailing list Lurk@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_lurk&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3D9a_L6t5TdnDThojv7KBKmqsZzTGM6YylS2wfbAO9KK0&m=3DjR4l13smzl6mjhJNFZzBEcBk= fCAl-bHE1ztPqmR8cSU&s=3DpquB3m1OmFta3X4qksEg1egdeKwrUVL4c5W4YFgkSu0&e=3D=20 From nobody Tue Apr 25 14:50:47 2017 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 C5842128BB6 for ; Tue, 25 Apr 2017 14:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham 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 KZj6J3jIoiG3 for ; Tue, 25 Apr 2017 14:50:43 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 E6C471252BA for ; Tue, 25 Apr 2017 14:50:42 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l18so43126790ywh.3 for ; Tue, 25 Apr 2017 14:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AaQ/CR2TnGwgYhU0J+S/xaIIvoFJQ34vRgqXnwTDcyM=; b=ZrDWL1G7e08aLyt4ymDQmVl84p/7yipR4VwpcaGaWbHIwv1Wq5YrXOW9KByCpt4Jl0 ALSJur6AxBtlPhpsJTksKTpWFnRQwDoXj+lT/bwA8Rkyx+xUHWbywTql/CY4naqx8Y2j RjWg5b92wzBuyKLzJAxgAAoKuQiaIAIwSe2BakCbPdAKODn9p9DQt+wXYkVkv/lMOSRh HybB9wZ9DSf2H06aZGeWH5z14sIVDqUztV9xlLRqNyCgKhE+B9ZNCVxoToPzdHQImn/R Gr+bM0q4t99cBxCLJgvVt+6ZvdXBT4s93uotxjhXPhtSIEx26qu4SbDkYNBafdRFL7FQ kZdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AaQ/CR2TnGwgYhU0J+S/xaIIvoFJQ34vRgqXnwTDcyM=; b=IrLHkYd6YlRWXsqwfKVH6RR0L41MGVv15+S9qJqj3iJxA0qwgnpRG8tOTQJfQhEMtq 0zhxGfqMmRWaqcTvtitlXRMYBq3c8pytBhhObwmpMKUVCX5jedJ1l1vdf7vIFz6XZsVF Xw2e1fRG9uoVi6i9nKDwom7r/CotaSpyzhIiToV74tvxKmfVWyT38VI0CLbnpMrZd4Ro FVLYVvaa/fiaPrhaJonQ883rvC8fNMJq0UF+wAGyiTrA8lGHATWXgyR/kcc9XXzEWXPI OzfR08I7ET9sUGbn06I81dTm6+yvwy1nQhwbwDS0aPx0FNmm9qZ9R9X+iUMPrzUTMqxw pM/A== X-Gm-Message-State: AN3rC/41KAFvgvHeFNzuc0QWzLmPmtlRta0EPXFU7v7mA9duZKx/Qx+l PxPBTr059ckbW+GS7ZuZ5wqVpkkByQ== X-Received: by 10.129.51.131 with SMTP id z125mr11554785ywz.87.1493157042211; Tue, 25 Apr 2017 14:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 25 Apr 2017 14:50:01 -0700 (PDT) In-Reply-To: References: <201704242108.54252.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 25 Apr 2017 14:50:01 -0700 Message-ID: To: Dave Garrett Cc: "tls@ietf.org" , Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1142165c18b616054e04b7c6 Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2017 21:50:45 -0000 --001a1142165c18b616054e04b7c6 Content-Type: text/plain; charset=UTF-8 PR here: https://github.com/tlswg/tls13-spec/pull/977 On Mon, Apr 24, 2017 at 8:12 PM, Eric Rescorla wrote: > > > On Mon, Apr 24, 2017 at 6:08 PM, Dave Garrett > wrote: > >> On Monday, April 24, 2017 07:21:13 pm Eric Rescorla wrote: >> > Hence, the following proposal for the complete label, where the longest >> > string is 18 bytes. >> > >> > 16 tls13 ext binder # was external psk binder key >> > 16 tls13 res binder # was resumption psk binder key >> > 17 tls13 c e traffic # was client early traffic secret >> > 18 tls13 e exp master # was early exporter master secret >> > 18 tls13 c hs traffic # was client handshake traffic secret >> > 18 tls13 s hs traffic # was server handshake traffic secret >> > 18 tls13 c ap traffic # was client application traffic secret >> > 18 tls13 s ap traffic # was server application traffic secret >> > 16 tls13 exp master # was exporter master secret >> > 16 tls13 res master # was resumption master secret >> > 9 tls13 key # was key >> > 8 tls13 iv # was iv >> > 14 tls13 finished # was finished >> > 17 tls13 traffic upd # was application traffic secret >> > 14 tls13 exporter # was exporter >> > 13 tls13 derived # was derived >> > >> > Further bikeshedding? >> >> I think "tls13 c e traffic" is the only one that could be tweaked to be a >> little more obvious. Abbreviating "early data" as "ed", instead of just >> "early" as "e", would still fit and follow the same pattern as the other >> traffic labels. >> > > Unfortunately this woud explode tls13 e exp master. > > -Ekr > > Other than that, this sounds fine. >> >> >> Dave >> > > --001a1142165c18b616054e04b7c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
PR here:

On Mon, Apr 24, = 2017 at 8:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:


<= div class=3D"gmail_quote">On Mon, Apr 24, 2017 at 6:08 PM,= Dave Garrett <davemgarrett@gmail.com> wrote:
On Monday, April 24, 2017 07:21:13 pm Eric R= escorla wrote:
> Hence, the following proposal for the complete label, where the longes= t
> string is 18 bytes.
>
> 16 tls13 ext binder=C2=A0 =C2=A0 #=C2=A0 was external psk binder key > 16 tls13 res binder=C2=A0 =C2=A0 #=C2=A0 was resumption psk binder key=
> 17 tls13 c e traffic=C2=A0 =C2=A0 #=C2=A0 was client early traffic sec= ret
> 18 tls13 e exp master=C2=A0 =C2=A0 #=C2=A0 was early exporter master s= ecret
> 18 tls13 c hs traffic=C2=A0 =C2=A0 #=C2=A0 was client handshake traffi= c secret
> 18 tls13 s hs traffic=C2=A0 =C2=A0 #=C2=A0 was server handshake traffi= c secret
> 18 tls13 c ap traffic=C2=A0 =C2=A0 #=C2=A0 was client application traf= fic secret
> 18 tls13 s ap traffic=C2=A0 =C2=A0 #=C2=A0 was server application traf= fic secret
> 16 tls13 exp master=C2=A0 =C2=A0 #=C2=A0 was exporter master secret > 16 tls13 res master=C2=A0 =C2=A0 #=C2=A0 was resumption master secret<= br> > 9 tls13 key=C2=A0 =C2=A0 #=C2=A0 was key
> 8 tls13 iv=C2=A0 =C2=A0 #=C2=A0 was iv
> 14 tls13 finished=C2=A0 =C2=A0 #=C2=A0 was finished
> 17 tls13 traffic upd=C2=A0 =C2=A0 #=C2=A0 was application traffic secr= et
> 14 tls13 exporter=C2=A0 =C2=A0 #=C2=A0 was exporter
> 13 tls13 derived=C2=A0 =C2=A0 #=C2=A0 was derived
>
> Further bikeshedding?

I think "tls13 c e traffic" is the only one that could be = tweaked to be a little more obvious. Abbreviating "early data" as= "ed", instead of just "early" as "e", would = still fit and follow the same pattern as the other traffic labels.

Unfortunately this woud explode tls13 e = exp master.

-Ekr

Other than that, this sounds fine.


Dave


--001a1142165c18b616054e04b7c6-- From nobody Tue Apr 25 20:01:52 2017 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 65DCC124D68 for ; Tue, 25 Apr 2017 20:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.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 Zx-eoN573dJx for ; Tue, 25 Apr 2017 20:01:48 -0700 (PDT) Received: from asbsmtoutape02.symantec.com (asbsmtoutape02.symantec.com [155.64.138.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1AA312426E for ; Tue, 25 Apr 2017 20:01:48 -0700 (PDT) Received: from asbsmtmtaapi01.symc.symantec.com (asb1-f5-symc-ext-prd-snat8.net.symantec.com [10.90.75.8]) by asbsmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id B6.A0.55425.A9D00095; Wed, 26 Apr 2017 03:01:46 +0000 (GMT) X-AuditID: 0a5af81a-83de59a00000d881-e9-59000d9a7f99 Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat7.net.symantec.com [10.90.75.7]) by asbsmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 97.66.04315.79D00095; Wed, 26 Apr 2017 03:01:46 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 25 Apr 2017 20:01:42 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.128.10) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Tue, 25 Apr 2017 20:01:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4Ga4J204njp6QmPxQ9YzKkPYqFOHVe/rd+HqeI1J6Kw=; b=X2Ra4TRWwU0RetJrtY5o8qqFDIcSs9LplrXHZY67Z457NVyeumeJV92zSV5u713BGfhv9KbZE+ZxO5zGpE2fGn6e+7etX8ByFvpUEqvelRQnhJEyxruf2D80SP/2rKLFXZGY/kfz8ZQLIqx6STZJapuRGhmTxxQ/CWUlCDot2z4= Received: from DM5PR16MB1834.namprd16.prod.outlook.com (10.172.45.9) by DM5PR16MB1834.namprd16.prod.outlook.com (10.172.45.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Wed, 26 Apr 2017 03:01:41 +0000 Received: from DM5PR16MB1834.namprd16.prod.outlook.com ([10.172.45.9]) by DM5PR16MB1834.namprd16.prod.outlook.com ([10.172.45.9]) with mapi id 15.01.1047.019; Wed, 26 Apr 2017 03:01:40 +0000 From: Roelof Du Toit To: "tls@ietf.org" Thread-Topic: Alert after sending ServerHello Thread-Index: AQHSvjlr+zNFNWUWWk+l9HsX/u+t/g== Date: Wed, 26 Apr 2017 03:01:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=symantec.com; x-originating-ip: [24.112.242.116] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1834; 7:0cC2wFwLXJCqACtBwdHdF7lVeLDawNINYK3GcyMRrksAriTWwQmji55mA9PHA2kgdmCxH0lQW3d4fQHOouKNzzqNjfhh7JFYdDCas09QPaThNzdqyy0vnXCD9M+Z4EX5om7nNJr+rPsQ5FQ+ftXqyiliutMp9lllDGv4pFFUlQz2+Bnz5gd9Q+MFvk4G8fA3h/a0KhYVd/ge6KuKxyOMgA1kYfaa0PjR8b9ALoxBHLblkXrNnK8ubOeisyI0NON0+jUag7t0gBdpSa2aBwvZQfW6+M0BTeex1aQbm7lh97ch234LZ25/zChHrHz4F1WnHpgkBpeyn1ufcRpQ7IrPFA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39850400002)(36756003)(15650500001)(50986999)(2420400007)(2501003)(54356999)(3480700004)(6916009)(7736002)(80792005)(7110500001)(189998001)(8936002)(81166006)(8676002)(66066001)(1730700003)(86362001)(122556002)(110136004)(38730400002)(53936002)(25786009)(6486002)(77096006)(6506006)(2906002)(10710500007)(6306002)(54896002)(99286003)(6512007)(33656002)(6436002)(102836003)(6116002)(3846002)(5640700003)(10290500003)(82746002)(2351001)(83716003)(3660700001)(3280700002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1834; H:DM5PR16MB1834.namprd16.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: f4a27225-6aa7-4365-76ae-08d48c508fc1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1834; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DM5PR16MB1834; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1834; x-forefront-prvs: 0289B6431E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EAF9D3D6A87D450DBCFB36F8CDC8B14Fsymanteccom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 03:01:40.0803 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1834 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Se0hTYRT3271zd6vR51x5WPlaDyzxidFLSojIWi+KSKWo67zkULexTUnB ssSazsp0oG7NpS1CjaLoYSoUEwWVfPTANAuWZlpg5h8+KK3d3Qn+8/E7v9/vHM4536EIyXO+ jFKpDYxOTWfKfUWkKEVBRVjEPsnR1u8B26d7S1ACSnQ45nnHUIooPo3JVOUwuqjd50TpzsJw rfHkheraZl4B+nS8BAkpwHFww1KFSpCIkuDfCBxXfxFLgrnRSXDCLIIfFXXeoB3BdE0hYl0S PIGgzaVlBRIXEzA781XAuSp48PJjGckFTgSFzhoBm+KLY2D+dTmfxVIcCk0fTG6eovxxGDzu VXN0BFSaqwmWluJIKJk6zdIk3gil9VYei8V4D7Q3NniaQHgNzHY98PAEDoChUTuPGwGDo7XX O85qmBhZ5LPtIGxC8Kz1FeIEOXS1FZAcDoS3dpNnGYBLCbg/aSW5oIMP1xu+eMsehkUXtwzA NxGMW23eUhnQ+K5KwGEFvOga8Gb388B4a47PzgN4Hdx9c4b1+GMZfH5fjMpQuGVZ6xxWwk9T vQeLsR90Vo+SFnc2gTfDo+YozhIKZpNLwOEwKLpt8+JE6Km1k8s9dxDVgEJofao+y6DJNtBa Jjo2Up+bpWQf2n1LykilJusJ8lzTnKwJjQ4fciJMIflKcbrQJ1nCp3PcTvcvUoRcKu53/EuS iNPo3DxGpzmry85k9E60liLlAeLhmqEkCT5PG5gMhtEyuiWVRwllBWiTFSW3REGcaptEf8rh UnT3NXd39zy0LPTMGBcGw+8Fnbg8vm9yw9bozolY9cwq/qDcHLe+I2Fn1bcrLTphXzYKtk3u Nx6tE408XZEfStsCU3zj63cMBEcUKeYS/KaCFHtVi5pLvdK+2ANjY5VH7Kn5QbsOGv4oyy+G XMuT/02Tk/p0OmYLodPT/wHctwPjSQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsXCFeXNrjuLlyHS4ONNDotP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcahZu6AjtGLmwl1MDYy3g7oYOTkkBEwkpqw+xNzFyMUhJPCd UeLV5EVQzlFGiU/zmhlBqoQEXjJKHH5YAJJgEehklvj+7RE7RNVkJomdNyawQDiHGCWaD81j B2lhEzCU+HlgEiuILSKgKLHjajdQnINDWEBDYuP5PIiwrsT0KTOZQcIiAnoSXR9iQMIsAqoS PStnM4HYvAL2EkdXrwI7glFATOL7qTVgcWYBcYlbT+YzQbwgILFkz3lmCFtU4uXjf6wg5zAK dDNKbN2znxEioSRx6nADC4QtK3FpfjcjSJGEQA+zxPJ3s1kgnGOsEr2r7kGN9ZX49xASGBIC /YwSL2bPhRqVLbH68gx2CNtbYvup61DdF5kkOib+YAX5R0JARmLx2ViQGmEBKYm7VzoZIWwZ iRd39rJC/JAs8bp7JdMERvVZSF6ahSQ1CxwEghInZz5hmQU0lVlAU2L9Ln2IEkWJKd0P2SFs DYnWOXOhbA+JcwvnsyCrWcDIsYpRIbE4qTi3JLckMbEg08BQr7gyNxlEJAKTUrJecn7uJkZw YvottoPxwB+fQ4wCHIxKPLwNHAyRQqyJZUCVhxilOViUxHmX/7wVISSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoGRJ+Gg6d5rvSG6KdEzE1KEl6WXqfZ95DC7fz7zYFpOQnmG+du7ZwXXNXGw ZR4/FC76Yaf03t7PkhnuIcorS1782urjsy++LfNjnp2aVZ8c0413fuc5S9UfuMS8/yNr63Kp L3bb0pwQyfz43tbTWhGzo+ZKyOaeiVvbnpXF2q8Umf3ZyX6quBJLcUaioRZzUXEiAHnwC1Yt AwAA X-CFilter-Loop: ASB03 Archived-At: Subject: [TLS] Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 03:01:50 -0000 --_000_EAF9D3D6A87D450DBCFB36F8CDC8B14Fsymanteccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RHVyaW5nIGludGVyb3AgdGVzdGluZyB3aXRoIGFuIG9wZW4tc291cmNlIHN0YWNrIEkgcmFuIGlu dG8gdGhlIGZvbGxvd2luZzoNCkNIIC0tLS0+DQo8LS0tLSBTSCx7RUUsQ2VydCxDVixGaW59DQph bGVydCAtLS0tPg0KDQpUaGUgYWxlcnQgd2FzIGR1ZSB0byBhIGRlY29kZSBlcnJvciBvbiBDViwg YW5kIHRoZSBzdGFjayBpbiBxdWVzdGlvbiBzZW50IHRoZSBhbGVydCBpbiBhIHBsYWludGV4dCBy ZWNvcmQuDQoNClRoZSBjdXJyZW50IGRyYWZ0IHNwZWNpZmljYXRpb24gaGFzIHRoZSBmb2xsb3dp bmcgdGV4dCBpbiBzZWN0aW9uIDY6DQoiTGlrZSBvdGhlciBtZXNzYWdlcywgYWxlcnQgbWVzc2Fn ZXMgYXJlIGVuY3J5cHRlZCBhcyBzcGVjaWZpZWQgYnkgdGhlIGN1cnJlbnQgY29ubmVjdGlvbiBz dGF0ZS4iDQouLiBhbmQgdGhlIGZvbGxvd2luZyBpbiBzZWN0aW9uIDUuMToNCiJPbmNlIHJlY29y ZCBwcm90ZWN0aW9uIGhhcyBzdGFydGVkLCBUTFNQbGFpbnRleHQgcmVjb3JkcyBhcmUgcHJvdGVj dGVkIg0KDQpJIGV4cGVjdGVkIHRoZSBhbGVydCBhYm92ZSB0byBiZSBzZW50IGluIGEgY2lwaGVy dGV4dCByZWNvcmQsIGJ1dCBJIGNhbiBhbHNvIHNlZSB0aGUgY2xpZW50IHNlbmRpbmcgcGxhaW50 ZXh0IGFsZXJ0cyBmb3IgU2VydmVySGVsbG8gZGVjb2RlIGZhaWx1cmVzLg0KTXkgY29uY2x1c2lv biBpcyB0aGF0IHRoZSBUTFMgMS4zIHJlY29yZCBsYXllciBvbiB0aGUgc2VydmVyIHNpZGUgc2hv dWxkIHN1cHBvcnQgcmVjZWl2aW5nIGJvdGggY2lwaGVydGV4dCBhbmQgcGxhaW50ZXh0IHJlY29y ZHMgYWZ0ZXIgU2VydmVySGVsbG8gaGFzIGJlZW4gc2VudC4NCg0KT25lIHdheSBmb3IgdGhlIHNl cnZlciB0byBoYW5kbGUgdGhlIHNjZW5hcmlvIGFib3ZlIGlzIHRvIGRlZmVyIHVzaW5nIGNsaWVu dF9oYW5kc2hha2VfdHJhZmZpY19zZWNyZXQgdW50aWwgdGhlIGZpcnN0IGFwcF9kYXRhIHJlY29y ZCBpcyByZWNlaXZlZC4gICBUaGF0IGlkZWEgZmFsbHMgZmxhdCB3aGVuIHRoZSBjbGllbnQgaXMg YWxzbyBzZW5kaW5nIGVhcmx5IGRhdGEgYW5kIHRoZSBzZXJ2ZXIgd2FudHMgdG8gaWdub3JlIHRo ZSBlYXJseSBkYXRhIHVzaW5nIHRyaWFsIGRlY3J5cHQgd2l0aCBjbGllbnRfaGFuZHNoYWtlX3Ry YWZmaWNfc2VjcmV0Og0KDQpDSCAtLS0tPg0KKGVkKSAtLS0tLVggKGRpc2NhcmQpDQogICAgICAg Li4uLS0tLSBTSA0KKGVkKSAtLS0tWCAodHJpYWwgZGVjcnlwdCArIGRpc2NhcmQpDQo8LS0tLi4u DQphbGVydCAtLS0tPg0KDQpBbm90aGVyIHdheSB0aGlzIGNvdWxkIHdvcmsgaXMgaWYgdGhlIHNl cnZlciBhbGxvd3Mgb25lIChhbmQgb25seSBvbmUpIHBsYWludGV4dCByZWNvcmQgKHdpdGggQ29u dGVudFR5cGUgPSBhbGVydCkgZnJvbSB0aGUgY2xpZW50IGR1cmluZyB0aGUgd2luZG93IHdoZXJl IGl0IGhhcyBzZW50IHRoZSBTSCx7RUUsQ2VydCxDVixGaW59IHNlcXVlbmNlIGFuZCBpcyB3YWl0 aW5nIGZvciB0aGUgY2xpZW50J3MgZmlyc3QgZW5jcnlwdGVkIGhhbmRzaGFrZSBtZXNzYWdlLg0K DQpJIHdvdWxkIGFwcHJlY2lhdGUgYSByZWNvbW1lbmRhdGlvbiBpbiBvcmRlciB0byBhdm9pZCBm dXR1cmUgaW50ZXJvcCBpc3N1ZXMuDQoNCi0tUm9lbG9mDQoNCg== --_000_EAF9D3D6A87D450DBCFB36F8CDC8B14Fsymanteccom_ Content-Type: text/html; charset="utf-8" Content-ID: <5DEBB2BBC27C9E49ABBE15CE77E991BF@namprd16.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OkNvdXJpZXI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJp Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 Q291cmllcjt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EdXJpbmcgaW50ZXJvcCB0ZXN0aW5nIHdpdGggYW4gb3Bl bi1zb3VyY2Ugc3RhY2sgSSByYW4gaW50byB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPkNIIC0tLS0mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q291cmllciI+Jmx0Oy0tLS0gU0gse0VFLENlcnQsQ1YsRmlufTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPmFsZXJ0IC0tLS0mZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgYWxlcnQgd2FzIGR1ZSB0byBhIGRlY29kZSBl cnJvciBvbg0KPGI+Q1Y8L2I+LCBhbmQgdGhlIHN0YWNrIGluIHF1ZXN0aW9uIHNlbnQgdGhlIGFs ZXJ0IGluIGEgPGI+cGxhaW50ZXh0PC9iPiByZWNvcmQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5UaGUgY3VycmVudCBkcmFmdCBzcGVjaWZpY2F0aW9uIGhhcyB0 aGUgZm9sbG93aW5nIHRleHQgaW4gc2VjdGlvbiA2OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mcXVv dDtMaWtlIG90aGVyIG1lc3NhZ2VzLCBhbGVydCBtZXNzYWdlcyBhcmUgZW5jcnlwdGVkIGFzIHNw ZWNpZmllZCBieSB0aGUgY3VycmVudCBjb25uZWN0aW9uIHN0YXRlLiZxdW90OzxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Li4gYW5kIHRoZSBmb2xsb3dpbmcgaW4gc2VjdGlvbiA1LjE6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiZxdW90O09uY2UgcmVjb3JkIHByb3RlY3Rpb24gaGFzIHN0YXJ0ZWQsIFRM U1BsYWludGV4dCByZWNvcmRzIGFyZSBwcm90ZWN0ZWQmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGV4cGVjdGVkIHRoZSBhbGVydCBhYm92ZSB0 byBiZSBzZW50IGluIGEgY2lwaGVydGV4dCByZWNvcmQsIGJ1dCBJIGNhbiBhbHNvIHNlZSB0aGUg Y2xpZW50IHNlbmRpbmcgcGxhaW50ZXh0IGFsZXJ0cyBmb3IgU2VydmVySGVsbG8gZGVjb2RlIGZh aWx1cmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NeSBjb25jbHVzaW9uIGlzIHRoYXQgdGhlIFRMUyAx LjMgcmVjb3JkIGxheWVyIG9uIHRoZSBzZXJ2ZXIgc2lkZSBzaG91bGQgc3VwcG9ydCByZWNlaXZp bmcgYm90aCBjaXBoZXJ0ZXh0IGFuZCBwbGFpbnRleHQgcmVjb3JkcyBhZnRlciBTZXJ2ZXJIZWxs byBoYXMgYmVlbiBzZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+T25lIHdheSBmb3IgdGhlIHNlcnZlciB0byBoYW5kbGUgdGhlIHNjZW5hcmlvIGFib3ZlIGlz IHRvIGRlZmVyIHVzaW5nIGNsaWVudF9oYW5kc2hha2VfdHJhZmZpY19zZWNyZXQgdW50aWwgdGhl IGZpcnN0IGFwcF9kYXRhIHJlY29yZCBpcyByZWNlaXZlZC4mbmJzcDsmbmJzcDsgVGhhdCBpZGVh IGZhbGxzIGZsYXQgd2hlbiB0aGUgY2xpZW50IGlzIGFsc28gc2VuZGluZyBlYXJseQ0KIGRhdGEg YW5kIHRoZSBzZXJ2ZXIgd2FudHMgdG8gaWdub3JlIHRoZSBlYXJseSBkYXRhIHVzaW5nIHRyaWFs IGRlY3J5cHQgd2l0aCBjbGllbnRfaGFuZHNoYWtlX3RyYWZmaWNfc2VjcmV0OjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5DSCAt LS0tJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPihlZCkgLS0tLS1Y IChkaXNjYXJkKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy4uLi0tLS0gU0g8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4oZWQpIC0tLS1YICh0cmlhbCBkZWNyeXB0ICYjNDM7 IGRpc2NhcmQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jmx0Oy0tLS4u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPmFsZXJ0IC0tLS0mZ3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Bbm90aGVyIHdheSB0aGlz IGNvdWxkIHdvcmsgaXMgaWYgdGhlIHNlcnZlciBhbGxvd3Mgb25lIChhbmQgb25seSBvbmUpIHBs YWludGV4dCByZWNvcmQgKHdpdGggQ29udGVudFR5cGUgPSBhbGVydCkgZnJvbSB0aGUgY2xpZW50 IGR1cmluZyB0aGUgd2luZG93IHdoZXJlIGl0IGhhcyBzZW50IHRoZSBTSCx7RUUsQ2VydCxDVixG aW59IHNlcXVlbmNlIGFuZCBpcw0KIHdhaXRpbmcgZm9yIHRoZSBjbGllbnQncyBmaXJzdCBlbmNy eXB0ZWQgaGFuZHNoYWtlIG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5JIHdvdWxkIGFwcHJlY2lhdGUgYSByZWNvbW1lbmRhdGlvbiBpbiBvcmRlciB0 byBhdm9pZCBmdXR1cmUgaW50ZXJvcCBpc3N1ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4tLVJvZWxvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EAF9D3D6A87D450DBCFB36F8CDC8B14Fsymanteccom_-- From nobody Tue Apr 25 21:41:29 2017 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 89011127071 for ; Tue, 25 Apr 2017 21:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 DM4OAwxYUhUf for ; Tue, 25 Apr 2017 21:41:27 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD2B120046 for ; Tue, 25 Apr 2017 21:41:27 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 95C3E496C09; Wed, 26 Apr 2017 04:41:26 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 7FC21496C01; Wed, 26 Apr 2017 04:41:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493181686; bh=GE4OeEJrQy5unD+IyUk0wAgBKxndjkosIZMsNEac3cI=; l=2870; h=To:References:From:Date:In-Reply-To:From; b=sFrVy2VNjaoywHA9D1sJ4IZtJADVPeAWL5ZnoK8n/RAlaKPwaGviafWybPYt3Lq9F 3LCjMv75qnZuc1s7zbYHSOdtpw7x5RWXQDN+0a5me2V7jFKfHl6HBEde0jpfr3idcJ AImijiet0vm3l/Tf7qrDFBVYpRn2Xll/coTOf7qY= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 30D211E0AE; Wed, 26 Apr 2017 04:41:26 +0000 (GMT) To: Roelof Du Toit , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <04f698b6-1f95-132e-06d9-4a69507bd297@akamai.com> Date: Tue, 25 Apr 2017 23:41:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F479BC03339982CC0CAD45BA" Archived-At: Subject: Re: [TLS] Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 04:41:28 -0000 This is a multi-part message in MIME format. --------------F479BC03339982CC0CAD45BA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/25/2017 10:01 PM, Roelof Du Toit wrote: > > During interop testing with an open-source stack I ran into the following: > > CH ----> > > <---- SH,{EE,Cert,CV,Fin} > > alert ----> > > > > The alert was due to a decode error on *CV*, and the stack in question > sent the alert in a *plaintext* record. > > > You could say which open-source stack you were using. I know that OpenSSL, at least, still has: /* * TODO(TLS1.3): This actually causes a problem. We don't yet know * whether the next record we are going to receive is an unencrypted * alert, or an encrypted handshake message. We're going to need * something clever in the record layer for this. */ but I don't think I looked at what the sending side does, yet. -Ben --------------F479BC03339982CC0CAD45BA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/25/2017 10:01 PM, Roelof Du Toit wrote:

During interop testing with an open-source stack I ran into the following:

CH ---->

<---- SH,{EE,Cert,CV,Fin}

alert ---->

 

The alert was due to a decode error on CV, and the stack in question sent the alert in a plaintext record.

 


You could say which open-source stack you were using.

I know that OpenSSL, at least, still has:

        /*
         * TODO(TLS1.3): This actually causes a problem. We don't yet know
         * whether the next record we are going to receive is an unencrypted
         * alert, or an encrypted handshake message. We're going to need
         * something clever in the record layer for this.
         */

but I don't think I looked at what the sending side does, yet.

-Ben
--------------F479BC03339982CC0CAD45BA-- From nobody Tue Apr 25 23:19:57 2017 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 34AD312F251 for ; Tue, 25 Apr 2017 23:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 5yDe-5ks17PG for ; Tue, 25 Apr 2017 23:19:54 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8A912F24E for ; Tue, 25 Apr 2017 23:19:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id A82EC40783; Wed, 26 Apr 2017 09:19:51 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id iJsJ5ylNT7UX; Wed, 26 Apr 2017 09:19:51 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 6F36C21C; Wed, 26 Apr 2017 09:19:51 +0300 (EEST) Date: Wed, 26 Apr 2017 09:19:49 +0300 From: Ilari Liusvaara To: Roelof Du Toit Cc: "tls@ietf.org" Message-ID: <20170426061949.GC28395@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 06:19:57 -0000 On Wed, Apr 26, 2017 at 03:01:40AM +0000, Roelof Du Toit wrote: > During interop testing with an open-source stack I ran into the following: > CH ----> > <---- SH,{EE,Cert,CV,Fin} > alert ----> > > The alert was due to a decode error on CV, and the stack in question > sent the alert in a plaintext record. > > The current draft specification has the following text in section 6: > "Like other messages, alert messages are encrypted as specified by > the current connection state." and the following in section 5.1: > "Once record protection has started, TLSPlaintext records are > protected" > > I expected the alert above to be sent in a ciphertext record, but I > can also see the client sending plaintext alerts for ServerHello > decode failures. My conclusion is that the TLS 1.3 record layer on > the server side should support receiving both ciphertext and > plaintext records after ServerHello has been sent. Yes, that's the way the library I'm writing does it: The first record received after ServerHello is sent can be cleartext alert for the case where client chokes on ServerHello, or it can be encrypted record. It does not support 0-RTT (insufficient understanding of the actual security properties, need to design API properly). One can easily tell unencrypted alert and encrypted record from envelope type (unencrypted alert has 21, encrypted alert or client returning handshake is 23). > One way for the server to handle the scenario above is to defer > using client_handshake_traffic_secret until the first app_data > record is received. That idea falls flat when the client is > also sending early data and the server wants to ignore the early > data using trial decrypt with client_handshake_traffic_secret: If you ever receive envelope-type-21 record, you know that the connection has failed. All those are fatal errors. The difference is really the error (illegal record type vs. received alert). -Ilari From nobody Tue Apr 25 23:36:11 2017 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 194D212785F for ; Tue, 25 Apr 2017 23:36:10 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 wURR8tCeKJfc for ; Tue, 25 Apr 2017 23:36:08 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 2E8A413184F for ; Tue, 25 Apr 2017 23:35:34 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id 88so102297972lfr.0 for ; Tue, 25 Apr 2017 23:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7U4k2/+3hc225LY/iJdJ69M9b90UVCH35a20RdnAmYU=; b=CqnZQTP0AdqVumq5XJ7+nSCKSW/N7Ane6c1jzNcW//rjLZSfZenGbQkH5qZgUGrHXQ Yk3D/SY5eP8EqfiGD1Rx8Xb4KnKnaPziglhkaHooOy8nUyK9nPFgcgE2jKaJUCr8xJGl Rg52hPsvwFUI1tcNwsErr8tMDQy51IImSi2gCNWcnRcAjX5uAg9Gfh4gJ6vvP9wWNUmC xc8QkqBPN4USP/7C304PrrTh+ZT6u2s8xByZdUTiCq2kTPmOVFBhyBG34RrKKWBqM6J8 wqFL6n0C1JcQt1Pd8rZq0fLyDZBFEk1asbrk4rkamEHq8s8TmDJt7qb5JWynQ0nJ8/vj Ql1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7U4k2/+3hc225LY/iJdJ69M9b90UVCH35a20RdnAmYU=; b=mzMRt6sW47NkKW9e2zSeS4Heq8FFzUmDWSZ4/dW9hg7H5qC5/udMmbMHw7R3C6IWEu F5e0VB4pDvxieOuheIaXW/P06woSv+xW9i7GYvrHRQvzNIu/Ryhr7vuwDAQ0PRA20F7A WRuLBMiMHoQOPul2GQtODbCbR+SX2lgWdVY6Q8fXhPuxdMc0wBRbwzzTuO2iUvMiN+Zh rA/qbAOvgOKqyK4qaZPeD/yLui9thNaVXnm5lMIThjqm7jAILREVDJxkBxm5qY+LKZDG OPd1qGgsXqU2EGvJqHuKxKiBOHow8cl/GpE3bosRynTCZjnig9ETH459p1ccMzhBXcrq vl0g== X-Gm-Message-State: AN3rC/5GtzrfJPk2gvWV2kO8/n9f03OhHQsBh+qlzZw6Kzl6WGF9MjrE MCiKiORm43w4mKt16ptKZBng07l7xA== X-Received: by 10.25.212.19 with SMTP id l19mr1487985lfg.169.1493188532350; Tue, 25 Apr 2017 23:35:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 25 Apr 2017 23:35:31 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 26 Apr 2017 16:35:31 +1000 Message-ID: To: Roelof Du Toit Cc: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 06:36:10 -0000 You are allowed to out NSS. We know that it's not ideal. I wrote that code and it's unencrypted for what I think is a good reason (others very much disagree). In part, it has to do with 0-RTT. In 0-RTT, we want to ensure that the client is able to continue sending 0-RTT until the entire server flight is received. Thus, we don't change out the keys until we receive and process the server Finished. The same code is used in 1-RTT. I think that we have a bug in that the alerts are 0-RTT encrypted; it might be better to send them in the clear as well. In effect, we assume that the entire flight is processed atomically and generate errors based on that. Only when the entire flight is processed cleanly do we install keys and respond. This is a pain for us, we don't have the code that Ilari talks about, so some of our tests end up hitting decode errors on the server, but it's been manageable thus far. On 26 April 2017 at 13:01, Roelof Du Toit wrote: > During interop testing with an open-source stack I ran into the following: > > CH ----> > > <---- SH,{EE,Cert,CV,Fin} > > alert ----> > > > > The alert was due to a decode error on CV, and the stack in question sent > the alert in a plaintext record. > > > > The current draft specification has the following text in section 6: > > "Like other messages, alert messages are encrypted as specified by the > current connection state." > > .. and the following in section 5.1: > > "Once record protection has started, TLSPlaintext records are protected" > > > > I expected the alert above to be sent in a ciphertext record, but I can also > see the client sending plaintext alerts for ServerHello decode failures. > > My conclusion is that the TLS 1.3 record layer on the server side should > support receiving both ciphertext and plaintext records after ServerHello > has been sent. > > > > One way for the server to handle the scenario above is to defer using > client_handshake_traffic_secret until the first app_data record is received. > That idea falls flat when the client is also sending early data and the > server wants to ignore the early data using trial decrypt with > client_handshake_traffic_secret: > > > > CH ----> > > (ed) -----X (discard) > > ...---- SH > > (ed) ----X (trial decrypt + discard) > > <---... > > alert ----> > > > > Another way this could work is if the server allows one (and only one) > plaintext record (with ContentType = alert) from the client during the > window where it has sent the SH,{EE,Cert,CV,Fin} sequence and is waiting for > the client's first encrypted handshake message. > > > > I would appreciate a recommendation in order to avoid future interop issues. > > > > --Roelof > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Apr 25 23:51:46 2017 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 D4F62131906 for ; Tue, 25 Apr 2017 23:51:44 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 wUdyokbUt48g for ; Tue, 25 Apr 2017 23:51:38 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 D7BA61318F6 for ; Tue, 25 Apr 2017 23:51:03 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id 75so102400281lfs.2 for ; Tue, 25 Apr 2017 23:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jcI64Y2XfA3l6k50d1VlJgXSQLovyQZRgvmzCmP+IjU=; b=XyMKrG14spPUS42Ix8Z9YOhYCcmmESZVBHEStRyK5r4kttqBwoXgqrGb+cErROCphH +2wMEPLqdyfsZpOyJIaWdhTgRfJjQQpaut4ArdwhJreZf6GYGGRreh1mJJmplE3+viVT VpP4PJ2yp0eMPZW1IEbPlCDUMQihA6CZ5dPwbzpfB9HqRUTCaOqR51a8UsNSm+zww1CC h6SlaVLkillSk3Z5MWJilDp5Ct2RC/YJr/x2JFtuKnsrm02kCffAoS6gVT6GGlcWdWex T1sL4Xgo9Q5jIPtHqd7HMgOAPfWVyAPFDd7BVmZOAB9DQOZnwLfAQwCc9oT5WU4jqTJc KMiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jcI64Y2XfA3l6k50d1VlJgXSQLovyQZRgvmzCmP+IjU=; b=ApDyEkx6No2ahaFDAAurQjuG5evFCaMTWZve1PA4SFFqV2NxfC3ucK8BqEMP/L3Seq vt7dAMuiTac3IMTUJr4nFiYhVCc04gMrP+1yAAHyQI/dymAtKtvJMfb29LJ+GK/iIZn0 LgeeqQ549GkRnL9zxSlxyCfgzMlRdjgnRWGTOOoTJa9ZofJQ1SneWt6ddaARvdvLM6LX xLEbqN37X6MAxK5bMIRzBLR7tlqLr7Oy6Zm4KeG/6gBYQEZ9Lt2yi+QRUg21HkRhII0Q TbJ84hfiYCXZI8QgHmdujWDW0sBrRT9IDpSRMmxH5yQsqf4Yma41rf+7iQ0wAHpvEapH MNiA== X-Gm-Message-State: AN3rC/6+MbsAUAfcnbxnQpcnpy7Oonu5TjlRFNFrfls8YMziPID5XxRj 1zcuGWfNKVS1oE2/itfjVb+Qz4jUCQ== X-Received: by 10.25.213.130 with SMTP id m124mr11533877lfg.50.1493189462073; Tue, 25 Apr 2017 23:51:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 25 Apr 2017 23:51:01 -0700 (PDT) In-Reply-To: References: <201704242108.54252.davemgarrett@gmail.com> From: Martin Thomson Date: Wed, 26 Apr 2017 16:51:01 +1000 Message-ID: To: Eric Rescorla Cc: Dave Garrett , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 06:51:45 -0000 Unsurprisingly, this was easy to implement. If anyone else is tracking this closely, I can share a version of NSS that includes this change (and pretends to be an implementation of -20). On 26 April 2017 at 07:50, Eric Rescorla wrote: > PR here: > https://github.com/tlswg/tls13-spec/pull/977 > > On Mon, Apr 24, 2017 at 8:12 PM, Eric Rescorla wrote: >> >> >> >> On Mon, Apr 24, 2017 at 6:08 PM, Dave Garrett >> wrote: >>> >>> On Monday, April 24, 2017 07:21:13 pm Eric Rescorla wrote: >>> > Hence, the following proposal for the complete label, where the longest >>> > string is 18 bytes. >>> > >>> > 16 tls13 ext binder # was external psk binder key >>> > 16 tls13 res binder # was resumption psk binder key >>> > 17 tls13 c e traffic # was client early traffic secret >>> > 18 tls13 e exp master # was early exporter master secret >>> > 18 tls13 c hs traffic # was client handshake traffic secret >>> > 18 tls13 s hs traffic # was server handshake traffic secret >>> > 18 tls13 c ap traffic # was client application traffic secret >>> > 18 tls13 s ap traffic # was server application traffic secret >>> > 16 tls13 exp master # was exporter master secret >>> > 16 tls13 res master # was resumption master secret >>> > 9 tls13 key # was key >>> > 8 tls13 iv # was iv >>> > 14 tls13 finished # was finished >>> > 17 tls13 traffic upd # was application traffic secret >>> > 14 tls13 exporter # was exporter >>> > 13 tls13 derived # was derived >>> > >>> > Further bikeshedding? >>> >>> I think "tls13 c e traffic" is the only one that could be tweaked to be a >>> little more obvious. Abbreviating "early data" as "ed", instead of just >>> "early" as "e", would still fit and follow the same pattern as the other >>> traffic labels. >> >> >> Unfortunately this woud explode tls13 e exp master. >> >> -Ekr >> >>> Other than that, this sounds fine. >>> >>> >>> Dave >> >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Apr 26 00:20:13 2017 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 B5D19131977 for ; Wed, 26 Apr 2017 00:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 t-FoZ59dl2zC for ; Wed, 26 Apr 2017 00:20:05 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id E2C3313196C for ; Wed, 26 Apr 2017 00:19:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 941BB366D8; Wed, 26 Apr 2017 10:19:54 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id bwSPmepTcw-c; Wed, 26 Apr 2017 10:19:54 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4D71D27B; Wed, 26 Apr 2017 10:19:54 +0300 (EEST) Date: Wed, 26 Apr 2017 10:19:52 +0300 From: Ilari Liusvaara To: Martin Thomson Cc: Roelof Du Toit , "tls@ietf.org" Message-ID: <20170426071952.GA29159@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 07:20:13 -0000 On Wed, Apr 26, 2017 at 04:35:31PM +1000, Martin Thomson wrote: > You are allowed to out NSS. We know that it's not ideal. > > I wrote that code and it's unencrypted for what I think is a good > reason (others very much disagree). In part, it has to do with 0-RTT. > > In 0-RTT, we want to ensure that the client is able to continue > sending 0-RTT until the entire server flight is received. Thus, we > don't change out the keys until we receive and process the server > Finished. The same code is used in 1-RTT. I think that we have a bug > in that the alerts are 0-RTT encrypted; it might be better to send > them in the clear as well. AFAIK, the only situations where client can abort sending 0-RTT data is noticing lack of server EarlyData extension (so server isn't listening anyway), or if the entiere handshake is aborted.. Doing it in other situations leads to subtle race conditions. Of course, EarlyData is in EncryptedExtensions, so one must use the Server Handshake keys to decrypt it. Which means processing ServerHello without installing Client Handshake Keys (since one is still encrypting 0-RTT). > In effect, we assume that the entire flight is processed atomically > and generate errors based on that. Only when the entire flight is > processed cleanly do we install keys and respond. My implementation processes message-by-message. So it installs the client handshake keys after ServerHello. > This is a pain for us, we don't have the code that Ilari talks about, > so some of our tests end up hitting decode errors on the server, but > it's been manageable thus far. The code I was talking about was handling the special case that the server might receive either encrypted or unencrypted alert in response to its flight. And the difference it makes is just what error is declared as abort reason. -Ilari From nobody Wed Apr 26 00:22:07 2017 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 5261E131986 for ; Wed, 26 Apr 2017 00:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 OE1IfkFSo8hf for ; Wed, 26 Apr 2017 00:22:03 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBF113197C for ; Wed, 26 Apr 2017 00:21:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 3AC27409E4; Wed, 26 Apr 2017 10:21:51 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id wJTr3vmkzhY5; Wed, 26 Apr 2017 10:21:51 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 146D021C; Wed, 26 Apr 2017 10:21:51 +0300 (EEST) Date: Wed, 26 Apr 2017 10:21:48 +0300 From: Ilari Liusvaara To: Martin Thomson Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20170426072148.GB29159@LK-Perkele-V2.elisa-laajakaista.fi> References: <201704242108.54252.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Issue #964: Shortened HKDF labels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 07:22:06 -0000 On Wed, Apr 26, 2017 at 04:51:01PM +1000, Martin Thomson wrote: > Unsurprisingly, this was easy to implement. If anyone else is > tracking this closely, I can share a version of NSS that includes this > change (and pretends to be an implementation of -20). Not very hard, altough I had to do some refactoring in order to semi- cleanly support multiple versions at once (I have a branch that does -17 to -20, with "-20" being -19 + this label change. -Ilari From nobody Wed Apr 26 05:00:26 2017 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 56106129B49 for ; Wed, 26 Apr 2017 05:00:24 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 mTVQT5APHoJS for ; Wed, 26 Apr 2017 05:00:23 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 A4A1C129B6A for ; Wed, 26 Apr 2017 05:00:22 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id t144so106614076lff.1 for ; Wed, 26 Apr 2017 05:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W5M6GpUByhIz9K4ytxOozY32qY19rhXVoJhaLsleoOA=; b=dT6HfaZDj0s4soEdifjwTEf3csDwDZ+EoVMmOmL9y6ClDTpudUo17svpD39l7rIi10 ctB99yOTPJ5D8PaWFoXjaaOhDVWOFJj4OMZfiFJ4c8JiveU/UmD/gtv+XJ09dRjqsz5J c9YNpkdxAEXUxxEj2AOICsRu+H8pOmJzuP1N5Rwtia7E42wwpNbQ+gQDzMp1h7V0uV6W AZchVlZHRppHC83x0byyU9oLd5I9csN6j2HoQ3BT5+LhJ+ynqY36a6t84qjip1ISyIzE LLNyC9oPz0HokVh5k8UD+/4c88ulDI017K9qo1LLqldWlqbBxCvBdu5WAUxX5loGp+dL Ezhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W5M6GpUByhIz9K4ytxOozY32qY19rhXVoJhaLsleoOA=; b=W1XgJN0iGXgh8JZGMwOnpr3dr7p8iLAx8uQCCNH0i10sy1CwhkUWKyJ/zaNRzabyQI tyjIZz7dhbYnCxqbTQkVVzxWIQdntMG4QVI5MGv/BJ1IPIwRTNOqW5iq05iH67ldpODH Z3LFxdAh3s3pq/1lZkRTFfu9Fv6TXqaI+wA2ts6jhOlMYMvKruGdRChuQD7y0+B7izs9 eroPgDqvX70Vpx/lmYpUi9dBZ7mLGbO45TinxMTQQlis/Sbn//L7af7U0uhPjiI0m0xW IDdZjsGON3+KV6AnCSzq7L0XJvnxd3SPPF25ovp1hSTL++bJNzrQpjUsOed0EIFk+37I /tVQ== X-Gm-Message-State: AN3rC/6o9TupI0opj3IVv/hpOxfgbeCBnqvH4nU/ENubQ4KtPS2Dk3hi frzjvK0I/Lbnyrg+AOojsYML1a3pmw== X-Received: by 10.25.79.27 with SMTP id d27mr10594383lfb.76.1493208020534; Wed, 26 Apr 2017 05:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 26 Apr 2017 05:00:19 -0700 (PDT) In-Reply-To: <20170426071952.GA29159@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170426071952.GA29159@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Wed, 26 Apr 2017 22:00:19 +1000 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 12:00:24 -0000 On 26 April 2017 at 17:19, Ilari Liusvaara wrote: > AFAIK, the only situations where client can abort sending 0-RTT data > is noticing lack of server EarlyData extension (so server isn't > listening anyway), or if the entiere handshake is aborted.. Doing it > in other situations leads to subtle race conditions. NSS stops sending 0-RTT as soon as it processes EncryptedExtensions. It also stops if it receives a HelloRetryRequest. In both cases you know that the server is trial decrypting and so it will correctly handle more 0-RTT data, but there is no point sending more if you know that it is junk. >> In effect, we assume that the entire flight is processed atomically >> and generate errors based on that. Only when the entire flight is >> processed cleanly do we install keys and respond. > > My implementation processes message-by-message. So it installs the > client handshake keys after ServerHello. NSS processes message-by-message, but the we just delay installing the client handshake keys. This allows us to get the most out of 0-RTT, but has this small downside. >> This is a pain for us, we don't have the code that Ilari talks about, >> so some of our tests end up hitting decode errors on the server, but >> it's been manageable thus far. > > The code I was talking about was handling the special case that the > server might receive either encrypted or unencrypted alert in response > to its flight. And the difference it makes is just what error is > declared as abort reason. Yeah, it's totally manageable, but there are a few small warts in the tests (which match the sent alert on one side with the received alert on the other side in the normal case). From nobody Wed Apr 26 05:25:40 2017 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 29D8F129B6F for ; Wed, 26 Apr 2017 05:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 klnsFLfh8fNL for ; Wed, 26 Apr 2017 05:25:36 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31540129B71 for ; Wed, 26 Apr 2017 05:25:36 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3wCfRy2MkMz26sF; Wed, 26 Apr 2017 14:25:34 +0200 (CEST) X-purgate-ID: 152705::1493209534-00002B31-C6141706/0/0 X-purgate-size: 1478 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3wCfRx1zT2zGprM; Wed, 26 Apr 2017 14:25:33 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 34A0D1A698; Wed, 26 Apr 2017 14:25:33 +0200 (CEST) In-Reply-To: <20170426071952.GA29159@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara Date: Wed, 26 Apr 2017 14:25:33 +0200 (CEST) CC: Martin Thomson , Roelof Du Toit , "tls@ietf.org" Reply-To: mrex@sap.com X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20170426122533.34A0D1A698@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 12:25:38 -0000 Ilari Liusvaara wrote: >> In effect, we assume that the entire flight is processed atomically >> and generate errors based on that. Only when the entire flight is >> processed cleanly do we install keys and respond. > > My implementation processes message-by-message. So it installs the > client handshake keys after ServerHello. > >> This is a pain for us, we don't have the code that Ilari talks about, >> so some of our tests end up hitting decode errors on the server, but >> it's been manageable thus far. > > The code I was talking about was handling the special case that the > server might receive either encrypted or unencrypted alert in response > to its flight. And the difference it makes is just what error is > declared as abort reason. Up to TLSv1.2 there was no confusion about whether a TLS record was encrypted or not: everything before "ChangeCipherSpec" is cleartext, everything thereafter is encrypted. Easy and straightforward solution would be to add the (meta-)information whether the Contents of a TLSv1.3 record are encrypted or not into the outer ContentType field, i.e. define an additional "encrypted Alert" content type and ensure that Alerts ContentTypes are always visible in the traditional TLS record header (rather than the bogus/futile attempt to hide this information). Having to do heuristics on something that can be easily deterministically tagged as one or the other, seems a little odd. -Martin From nobody Wed Apr 26 05:42:30 2017 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 21707129B7D for ; Wed, 26 Apr 2017 05:42:29 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 45ie55QeQdm0 for ; Wed, 26 Apr 2017 05:42:27 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 377F71296CF for ; Wed, 26 Apr 2017 05:42:27 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id c80so107048814lfh.3 for ; Wed, 26 Apr 2017 05:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QNr0BCnp6fQ+IrxTke7dTciNb1LS11w3nKt3NthZ8oc=; b=ltnzx1FqWsj1IU8oGFdj5Yr+R0X7OSvmXW6xdxe08cXTxQGo0LCze8toXAaNbr7me9 Vev0QHWXojRreYqnowpVQkgYAlUDQx4rbKjwbvBgjMEwjtDyvaC+h5OD9NyAnzqREaSw DTUTLSDnmHW7xHIUL4Oc/VhTRgjW24cnTntA6W3BEPD4CN232L6GrhNoRX4lLWNY7T4a BRL41Hw/ACRs5JuB5xZruOtkW92iJC3/cU5nnW7kaht3fe8IBUti9C3tKCp8Xbb6dHIm aL93++a2RZdSnHi/KQrq8/YUwJYHcI8dDgagNfgUhyWpZsj/7A5bXbrxWNV7IbwjZLHX i+Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QNr0BCnp6fQ+IrxTke7dTciNb1LS11w3nKt3NthZ8oc=; b=tAUPILOSPD8pGj55A6hYUaLumTmcybtc9zvXZMgHx1rAxWSk6mmV5SyckMq9D5JRDF Pr28O5Seu9tcQmmTQyoS1OBkhsWxl4w2Y3nk5linbBtisaSUF/OeajzZxsPqz7IoLrv4 1x4Hi/MOHHIfA48S8tqYSWPbIak3hWqRLuWSgFS02f/M/EPOCcaH5achTgt6hrz+57Rt KMsRcDKHCB6GC01ft2iqbJ0g7v/f7IsaJmGPxTOJ/vPW7S4dpcADFx47a5SEhgUVR9B9 NCDD/WMH5J0K5H0MWe41yiTD4XssddtGMe8xEKXzyfADEY1GoTbVDpEwnAXutGDUrlrV MFag== X-Gm-Message-State: AN3rC/6F+IWZ7Z7iiGWTh3UJDAn2i/qQHub756MpN6DkxX1NO6694Ti1 EXGug7OuZFk1RVrG0dnhvcYPyWU6MQ== X-Received: by 10.46.0.70 with SMTP id 67mr13762525lja.113.1493210545430; Wed, 26 Apr 2017 05:42:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 26 Apr 2017 05:42:24 -0700 (PDT) In-Reply-To: <20170426122533.34A0D1A698@ld9781.wdf.sap.corp> References: <20170426071952.GA29159@LK-Perkele-V2.elisa-laajakaista.fi> <20170426122533.34A0D1A698@ld9781.wdf.sap.corp> From: Martin Thomson Date: Wed, 26 Apr 2017 22:42:24 +1000 Message-ID: To: "mrex@sap.com" Cc: Ilari Liusvaara , Roelof Du Toit , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 12:42:29 -0000 On 26 April 2017 at 22:25, Martin Rex wrote: >> The code I was talking about was handling the special case that the >> server might receive either encrypted or unencrypted alert in response >> to its flight. And the difference it makes is just what error is >> declared as abort reason. > > Up to TLSv1.2 there was no confusion about whether a TLS record > was encrypted or not: everything before "ChangeCipherSpec" is cleartext, > everything thereafter is encrypted. That's not a problem here either. It's trivial to tell between an encrypted record and an unencrypted one. The question - if there is any - is when to start encrypting if there happens to be an error. From nobody Wed Apr 26 06:24:05 2017 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 08801129B9D for ; Wed, 26 Apr 2017 06:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 WtRMAXniaeK0 for ; Wed, 26 Apr 2017 06:24:01 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F62129B95 for ; Wed, 26 Apr 2017 06:24:00 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3wCglL24tjz26rW; Wed, 26 Apr 2017 15:23:58 +0200 (CEST) X-purgate-ID: 152705::1493213038-00002B31-A4D2BEA5/0/0 X-purgate-size: 4596 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3wCglL0SkczGnt2; Wed, 26 Apr 2017 15:23:58 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 06FA71A698; Wed, 26 Apr 2017 15:23:58 +0200 (CEST) In-Reply-To: <926e3b6b-5f0c-e00a-5ba3-9a2cfcdc4e8f@drh-consultancy.co.uk> To: Dr Stephen Henson Date: Wed, 26 Apr 2017 15:23:57 +0200 (CEST) CC: Benjamin Kaduk , tls@ietf.org Reply-To: mrex@sap.com X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20170426132358.06FA71A698@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 13:24:04 -0000 Dr Stephen Henson wrote: > On 25/04/2017 15:36, Benjamin Kaduk wrote: >> >> RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA- >> PSS [RFC3447 ] with mask generation function 1. The digest used in >> the mask generation function and the digest being signed are both >> the corresponding hash algorithm as defined in [SHS ]. When used >> in signed TLS handshake messages, the length of the salt MUST be >> equal to the length of the digest output. This codepoint is also >> defined for use with TLS 1.2. >> >> >> Is the concern that this is insufficiently clearly indicated as placing >> requirements on signatures of certificates as opposed to signatures of >> TLS data structures? > > Yes that's my concern. Supporting PSS signatures on certificates is > a mandatory requirement and I think we should be very clear about the > parameters we permit. > > The above paragraph says nothing about salt length limitations on > signatures on certificates. We could have a situation where one > implementation enforces the salt length to be equal to the digest length > (and rejects everything else) and another will allow any valid length. It has always been a terribly stupid bug that TLS started talking about signatures on certificates when negotiating TLS protocol properties, and it resulted in a few painfully broken TLSv1.2 implementations getting shipped (such as Microsoft Windows7/2008R2 through 8.1/2012R2). Please ensure that TLSv1.3 is cleaned from bogus references about requirements on signature algorithms for certificates. Signatures on certificates are created by CAs, rather than TLS endpoints, so any implementation that uses TLS protocol parameters (about TLS signature algorithms) for more than a mere cert selection hint, is actively creating interop problems while providing *NO* value. Many TLS peers will have just one suitable certificate anyway, so not even looking at certificate signatures will be the easiest to implement, most robust and perfectly secure behaviour anyway. The issue with RSA-PSS digital signatures is that they were defined with additional (unnecessary) parameters that are encoded (=hidden) in the ASN.1 AlgorithmIdentifier, and that are therefore unspecified when RSA-PSS is requested as (rsa-pss,sha-256) rather than with an ASN.1 AlgorithmIdentifier. The additional, unnecessary parameters are "saltLen" and "MaskGenerationFunction" (MGF), and the commonly-used MaskGenerationFunction (mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash). In theory there is another additional, unnecessary parameter "TrailerField", which appears in the ASN.1 AlgorithmIdentifier parameter list (and in the XMLdsig encoding for RSA-PSS), but PKCS#1 v2.1 (rfc3447) essentially hardwires the Trailerfield to option TrailerfieldBC(1), internal value 0xbc. The definition of "implied" RSA-PSS parameters applies only to the "digitally-signed" signature blobs using inside the TLS protocol because these do not come with an ASN.1 AlgorithmIdentifier tag. The implied RSA-PSS paramters for TLS' digitally-signed are unrelated to RSA-PSS signatures on certificates (certificates come with explicit RSA-PSS parameters encoded in an ASN.1 AlgorithmIdentifer): Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } The original RSA-PSS AlgorithmIdentifer specification also defines a hierarchical policy concept, that is supposed to limit the kinds of signatures that can be created (verified) with a so-tagged public RSA key, and this policy is supposed to work/apply from the RootCA cert *downwards* to the leaf / end-entity cert. It seems silly trying to apply implied RSA-PSS parameter selections from the digitally-signed TLS protocol transform to the signature on the TLS end-entity cert (or worse, even to certs up the cert chain), because that would be the wrong/invalid direction. What should be spelled out, whether and how any RSA-PSS policy in the subjectPublicKeyInfo AlgorithmIdentifier of the end-entity certificate interacts with implied RSA-PSS parameters used by the TLS digitally-signed transform. In any case, the decision whether to accept a certificate should be _with_the_receiver_ (verifier / RP), and *NEVER* with the sender. -Martin From nobody Wed Apr 26 06:42:25 2017 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 4DB7F128799 for ; Wed, 26 Apr 2017 06:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 MlMbaP7KT6Xd for ; Wed, 26 Apr 2017 06:42:17 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8A75D129BAA for ; Wed, 26 Apr 2017 06:41:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 0F39940673; Wed, 26 Apr 2017 16:41:43 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id CqQy-E978yo6; Wed, 26 Apr 2017 16:41:42 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id B6FDCC4; Wed, 26 Apr 2017 16:41:42 +0300 (EEST) Date: Wed, 26 Apr 2017 16:41:40 +0300 From: Ilari Liusvaara To: Martin Rex Cc: Dr Stephen Henson , tls@ietf.org Message-ID: <20170426134140.GA29859@LK-Perkele-V2.elisa-laajakaista.fi> References: <926e3b6b-5f0c-e00a-5ba3-9a2cfcdc4e8f@drh-consultancy.co.uk> <20170426132358.06FA71A698@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170426132358.06FA71A698@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 13:42:19 -0000 On Wed, Apr 26, 2017 at 03:23:57PM +0200, Martin Rex wrote: > > Signatures on certificates are created by CAs, rather than TLS endpoints, > so any implementation that uses TLS protocol parameters (about TLS signature > algorithms) for more than a mere cert selection hint, is actively creating > interop problems while providing *NO* value. Many TLS peers will have > just one suitable certificate anyway, so not even looking at certificate > signatures will be the easiest to implement, most robust and perfectly secure > behaviour anyway. What my implementation does with certificate signatures: - There actually are signature algorithms with no known TLS code, e.g. ECDSA-SHA3 signatures. These are known but can not be advertised. - The built-in server-side certificate selection code never selects certificate containing algorithm client didn't advertise. - The server side certificate chain checking interlocks on unknown signature algorithms, but not unadvertised signature algorithms. So custom certificate selector can overrule the client advertisment, but not known algorithm check. - On client side, all known algorithms (other than PKCS#1/SHA-1, which is treated specially) are treated as valid for certificates. Advertised or not. All others are just ignored (which violates a MUST in spec) and path building never builds through those.. - Regarding RSA-PSS, only the 3 variants that TLS defines are supported). > The issue with RSA-PSS digital signatures is that they were defined > with additional (unnecessary) parameters that are encoded (=hidden) in the > ASN.1 AlgorithmIdentifier, and that are therefore unspecified when > RSA-PSS is requested as (rsa-pss,sha-256) rather than with an ASN.1 > AlgorithmIdentifier. TLS 1.3 specifies what values those parameters have for various SignatureSchemes. > The additional, unnecessary parameters are "saltLen" and > "MaskGenerationFunction" (MGF), and the commonly-used MaskGenerationFunction > (mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash). Also specified. > In theory there is another additional, unnecessary parameter "TrailerField", > which appears in the ASN.1 AlgorithmIdentifier parameter list (and in the > XMLdsig encoding for RSA-PSS), but PKCS#1 v2.1 (rfc3447) essentially > hardwires the Trailerfield to option TrailerfieldBC(1), internal value 0xbc. So this also counts as specified. > > The definition of "implied" RSA-PSS parameters applies only to the > "digitally-signed" signature blobs using inside the TLS protocol > because these do not come with an ASN.1 AlgorithmIdentifier tag. > The implied RSA-PSS paramters for TLS' digitally-signed are unrelated > to RSA-PSS signatures on certificates (certificates come with explicit > RSA-PSS parameters encoded in an ASN.1 AlgorithmIdentifer): > > Certificate ::= SEQUENCE { > tbsCertificate TBSCertificate, > signatureAlgorithm AlgorithmIdentifier, > signatureValue BIT STRING } > > The original RSA-PSS AlgorithmIdentifer specification also defines > a hierarchical policy concept, that is supposed to limit the kinds > of signatures that can be created (verified) with a so-tagged public > RSA key, and this policy is supposed to work/apply from the RootCA cert > *downwards* to the leaf / end-entity cert. I don't think it appiles that way, only per-key. ExtendedKeyUsage is *not* supposed to be hierarchial, but doesn't prevent many libraries from handling it that way. > It seems silly trying to apply implied RSA-PSS parameter selections > from the digitally-signed TLS protocol transform to the signature > on the TLS end-entity cert (or worse, even to certs up the cert chain), > because that would be the wrong/invalid direction. The SignatureScheme selections only mean those schemes are supported, not that other RSA-PSS schemes can't be supported in CA signatures (however, there is no way to advertise those). > What should be spelled out, whether and how any RSA-PSS policy in the > subjectPublicKeyInfo AlgorithmIdentifier of the end-entity certificate > interacts with implied RSA-PSS parameters used by the TLS digitally-signed > transform. In any case, the decision whether to accept a certificate > should be _with_the_receiver_ (verifier / RP), and *NEVER* with the sender. AFAIK, the only place there is any impiled interaction is when the end- entity key is RSA-PSS-only. And there the rules are usual matching rules versus the key. -Ilari From nobody Wed Apr 26 06:43:56 2017 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 55D47129BAC for ; Wed, 26 Apr 2017 06:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.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 IyVezJ3gSHyJ for ; Wed, 26 Apr 2017 06:43:51 -0700 (PDT) Received: from tussmtoutape02.symantec.com (tussmtoutape02.symantec.com [155.64.38.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE179129BB5 for ; Wed, 26 Apr 2017 06:43:51 -0700 (PDT) Received: from tussmtmtaapi02.symc.symantec.com (tus3-f5-symc-ext-prd-snat1.net.symantec.com [10.44.130.1]) by tussmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id 85.1E.57663.414A0095; Wed, 26 Apr 2017 13:43:51 +0000 (GMT) X-AuditID: 0a2c7e32-effff7000000e13f-79-5900a4141034 Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat2.net.symantec.com [10.44.130.2]) by tussmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 4A.2E.58529.414A0095; Wed, 26 Apr 2017 13:43:48 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 26 Apr 2017 06:43:47 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.128.2) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Wed, 26 Apr 2017 06:43:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O/8Xtepn44lnN4JOyFwLYgmTp1c24SfyFBfF9+Q8xqA=; b=lhZ1paiVj4nbbI/xi9sn6cMRxg+q5etD8KamRLCBY37xfRkrIZTStUoB9YK9w/cCbUN7AqOMkJZ0Z4ft/Eaw9WwWaLwLWM+0xvlF4N7ZY3Ya1uBcxDXZFpB2abkreeya4Xl6BQo2lB9Paz0XrOA15r/gYxWSsgYynWOfZ+ORKyU= Received: from DM5PR16MB1834.namprd16.prod.outlook.com (10.172.45.9) by DM5PR16MB1835.namprd16.prod.outlook.com (10.172.45.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Wed, 26 Apr 2017 13:43:46 +0000 Received: from DM5PR16MB1834.namprd16.prod.outlook.com ([10.172.45.9]) by DM5PR16MB1834.namprd16.prod.outlook.com ([10.172.45.9]) with mapi id 15.01.1047.019; Wed, 26 Apr 2017 13:43:45 +0000 From: Roelof Du Toit To: Martin Thomson , "mrex@sap.com" , "tls@ietf.org" , Ilari Liusvaara Thread-Topic: [EXT] Re: [TLS] Alert after sending ServerHello Thread-Index: AQHSvjlr+zNFNWUWWk+l9HsX/u+t/qHXMieAgAAMZACAAFVogIAABLUA///OFQA= Date: Wed, 26 Apr 2017 13:43:45 +0000 Message-ID: References: <20170426071952.GA29159@LK-Perkele-V2.elisa-laajakaista.fi> <20170426122533.34A0D1A698@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=symantec.com; x-originating-ip: [72.23.5.194] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1835; 7:prG3g5QaTQtMcopJnups0semvsQ1Ee69agbLfilJatBQh32okwabU0rGPuUjSZZDBSUJS6JHMYGWg0kWW4KbQQq3BoqTAEtcH8InNvNY5oDAoZEheksFhSrmo3NkjgvFSHkhPZkPmV6uI6i4BrZsPx53Dq7r2ALCt+voFzxQSYQ2CFXMyDgPUgxBWtvaIk1R+B3jEIgCS0oqIdKi/Tq2awpJq0Tsw4+1fizeC/amqESpKc97AosTnyJYtmm0hazMpXhMAftx72g13wSrn43DF5pxy2+wAFFeSD243H5NZY6jfsJWgBx+AGES5+hEkwC8cvfZqQ9Kz8S6VMIzrGjsxg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(24454002)(52544003)(377454003)(54356999)(6486002)(76176999)(50986999)(77096006)(122556002)(7110500001)(189998001)(81166006)(8676002)(99286003)(2900100001)(80792005)(8936002)(38730400002)(2501003)(33656002)(3846002)(54896002)(6116002)(10290500003)(6306002)(6512007)(102836003)(3280700002)(3660700001)(236005)(39060400002)(66066001)(2906002)(82746002)(10710500007)(53936002)(83716003)(25786009)(7736002)(2420400007)(15650500001)(2201001)(6246003)(8656002)(6506006)(36756003)(5660300001)(2950100002)(229853002)(6436002)(86362001)(53546009); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1835; H:DM5PR16MB1834.namprd16.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 6062a6be-557c-4eda-955d-08d48caa426a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DM5PR16MB1835; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(55761251573089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201703061421075)(201703161042150)(6072148)(6042181); SRVR:DM5PR16MB1835; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1835; x-forefront-prvs: 0289B6431E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D9728A8826894E7D94D6820F83A49AB9symanteccom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 13:43:45.0711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1835 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe3fO3HE6el3WHrSbC0MlrxQJWUlgLUxJ+6Im6NKTivPCNjX7 IFIqOLNimuLylqzEShyipZmXJMtsJgYuLywLJ1gJNi+Zhtp2zgS/HH7v8/z/5/8857wUITRw XaiUdCUtT5fKxHZ8kn/sFvIWaXdF++mmRYELXZVkoEG/iQJL/3UQgYsjKhRMSjo1Rp5Eq13j SMqX2pFkqqTa7jIZww9KpGUp2bTc90w8P/lPwXsicyj0RtngvF0+6rqoQvYU4ONgrryNVIhP CfEigiLdFGe7sTXxmGdlIf6LwNDlxooGEDRtNHLZwxyCztEWxk7iYgL032q5rKWcA9Nj8Sz3 I2heCbGyHfaHtT4143bGVQg0DT+ZvD04CCrbR5k8Z3wayjbmSJbDwdxitjBlSXAH/Ru+tSzA Z2G4oYZgp+hDsGBoJKwNexwBanUF40V4H6wOPWfeT2ARTJrqbLth0L4eIVjeCz9mNpmBEC5F oH2wymUbh2B69iNi+QB8rith1gR8h4D66l7bwcSFjfE+HqsKg9a2JltEHkwNqG0RqaB9MWar X4XN2S0ea57kgKFdR9xH3podI7KcABttT7gaZlcn+FBlIjWWT0BgT2h55ctK3KC85DuPZQ8o rK6xsQSGywZ4OzX1iHqKDiuzFIo0ZUaWUppJ+wX4KHLTEqwPqeWuJfgkZKS1Iua25QV0oEXd pX6EKSR2FCyV7YoWcqXZFqXlP1KE2FmwUmMpCRKluTdpeUacPEtGK/qRK0WKRYLJ2skoIU6S KulUms6k5dtdDmXvko9En3rO/ZofcX02k/NW5hhMRsYVq3r1Dh7yxXeD10McZCZVWGyuIYmy d1reWib0J472txal5ix/nQjZOrU+7lkQW79yrfnhye57ksGYI0k9Md3hv6ONLw+Wj3F3X9hf WFuRlWz0Ul7pjnMPPT8VsVp1l9e65tc3+8UcSZuNj2A9SkwqkqX+XoRcIf0P24irvmkDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA02SfSzUcRzH+97vd3c/V+rbEZ8Oi1OkebpmdW0qW2tdIdU/VCq/zhVzJ+6O arUyy5anTUfM5fLQYaymRJGGbrMkQuXoZGpham1SCdPR3f3uj/757vV5eH8/D/tQBL+VLaAS k9UyZTItF3J4JM8/kxXgrF91PLi4XSyeaSshxcbeZSTOX2ohxD/7c1AYKWnVjnElev0iS1L0 qxlJRnPLOEfIE7zQeJk8MV2mDNoTx0v4c+MlkdITfqmw+zsnA7UdzEEOFOAQWPlQzbUyHy8g MLZ55SCehbsQ1Jlr2YwxjaB1sAFZDRJnE9D76S6bkRSxYHwojmEDggdz+63MwSJY7NTY1M64 FIG26hvLGnDCoVDSPGir54x3Q6F5mmT4MMw2zFqYslTYAr0veFa3I94LfVU6gumiE8GMsZaw BhzwUdBoim1ahF1gvue+7X8Cu4JpopzFzIZB/7yfYHgDfP2ybGsI4XwE+tvzbCawCcYnXyOG PeBtea5tTMB5BFSUddiNCTaYRzq5TFYkNDbV2Utcg9Eujb1EEuifDNn9J2F5coXLiE0sMDY/ JKyzAXaHe32nmFUIYOx9NipAftr/OmdYCuamGrbWtoL18Kp0gtRa1AT2g4ZnQUyKFxTlfuYy vBWyynR2lkBfYRf3/5wKRNUjT3WaSqVQK9Q0nZIYvD1QdVkhtT605dKkgdILikZku7V9G1uQ 4W+EAWEKCdc4SoZXYvhsOt2SaUBuFCl0daxdNMXw8XlaLUuSyVJkyjPKNLlMZUAsykGQgajY j1mctccGPG8iH07/QLLHI3lBgElxNnXEuTb6R7T3pEEXHrs01z4luOJCrzN1reY5eddXVHXL nRbCT+96M3Ug8hD2dgu5mKkSVYp+++T5X/eNStOyzjUN3erzWWwN2BGRKn08fCc+Kerp5tGd voHlOndljSA9TN5R2Wi++q5aSKoSaNE2Qqmi/wFCylFvTAMAAA== X-CFilter-Loop: TUS02 Archived-At: Subject: Re: [TLS] [EXT] Re: Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 13:43:54 -0000 --_000_D9728A8826894E7D94D6820F83A49AB9symanteccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJIGFncmVlIHRoYXQgdGhlIHByb2JsZW0gaXMgZXJyb3IgaGFuZGxpbmcuICBJIGdldCB0 aGF0IGl0IGlzIHRyaXZpYWwgdG8gZGlzdGluZ3Vpc2ggZW5jcnlwdGVkIGZyb20gdW5lbmNyeXB0 ZWQsIGJ1dCBJIHdvdWxkIGFwcHJlY2lhdGUgaXQgaWYgdGhlIHNwZWMgY291bGQgY2xhcmlmeSB0 aGUgYXBwcm9wcmlhdGUgYWN0aW9ucyBpbiB0aGUgc2NlbmFyaW8gd2hlcmUgYW4gdW5lbmNyeXB0 ZWQgKG5vbi1hcHBkYXRhKSByZWNvcmQgaXMgcmVjZWl2ZWQgYWZ0ZXIga2V5cyBoYXZlIGJlZW4g aW5zdGFsbGVkIGluIHRoZSBjb25uZWN0aW9uIHN0YXRlLiAgSXQgd291bGQgYmUgc3RyYW5nZSB0 byBzZW5kIGFuIGFsZXJ0IGluIHJlc3BvbnNlIHRvIGFuIGFsZXJ0Lg0KDQpQUzogSSB3YXMgdGVz dGluZyB3aXRoIE9wZW5TU0wgd2hlbiBJIGhpdCB0aGUgaW50ZXJvcCBpc3N1ZS4NCg0KRnJvbTog TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NCkRhdGU6IFdlZG5lc2Rh eSwgQXByaWwgMjYsIDIwMTcgYXQgODo0MiBBTQ0KVG86ICJtcmV4QHNhcC5jb20iIDxtcmV4QHNh cC5jb20+DQpDYzogSWxhcmkgTGl1c3ZhYXJhIDxpbGFyaWxpdXN2YWFyYUB3ZWxoby5jb20+LCBS b2Vsb2YgRHUgVG9pdCA8Um9lbG9mX0R1dG9pdEBzeW1hbnRlYy5jb20+LCAidGxzQGlldGYub3Jn IiA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogW0VYVF0gUmU6IFtUTFNdIEFsZXJ0IGFmdGVyIHNl bmRpbmcgU2VydmVySGVsbG8NCg0KT24gMjYgQXByaWwgMjAxNyBhdCAyMjoyNSwgTWFydGluIFJl eCA8bXJleEBzYXAuY29tPG1haWx0bzptcmV4QHNhcC5jb20+PiB3cm90ZToNClRoZSBjb2RlIEkg d2FzIHRhbGtpbmcgYWJvdXQgd2FzIGhhbmRsaW5nIHRoZSBzcGVjaWFsIGNhc2UgdGhhdCB0aGUN CnNlcnZlciBtaWdodCByZWNlaXZlIGVpdGhlciBlbmNyeXB0ZWQgb3IgdW5lbmNyeXB0ZWQgYWxl cnQgaW4gcmVzcG9uc2UNCnRvIGl0cyBmbGlnaHQuIEFuZCB0aGUgZGlmZmVyZW5jZSBpdCBtYWtl cyBpcyBqdXN0IHdoYXQgZXJyb3IgaXMNCmRlY2xhcmVkIGFzIGFib3J0IHJlYXNvbi4NCg0KVXAg dG8gVExTdjEuMiB0aGVyZSB3YXMgbm8gY29uZnVzaW9uIGFib3V0IHdoZXRoZXIgYSBUTFMgcmVj b3JkDQp3YXMgZW5jcnlwdGVkIG9yIG5vdDogZXZlcnl0aGluZyBiZWZvcmUgIkNoYW5nZUNpcGhl clNwZWMiIGlzIGNsZWFydGV4dCwNCmV2ZXJ5dGhpbmcgdGhlcmVhZnRlciBpcyBlbmNyeXB0ZWQu DQoNClRoYXQncyBub3QgYSBwcm9ibGVtIGhlcmUgZWl0aGVyLiAgSXQncyB0cml2aWFsIHRvIHRl bGwgYmV0d2VlbiBhbg0KZW5jcnlwdGVkIHJlY29yZCBhbmQgYW4gdW5lbmNyeXB0ZWQgb25lLiAg VGhlIHF1ZXN0aW9uIC0gaWYgdGhlcmUgaXMNCmFueSAtIGlzIHdoZW4gdG8gc3RhcnQgZW5jcnlw dGluZyBpZiB0aGVyZSBoYXBwZW5zIHRvIGJlIGFuIGVycm9yLg0KDQo= --_000_D9728A8826894E7D94D6820F83A49AB9symanteccom_ Content-Type: text/html; charset="utf-8" Content-ID: <563CDE764E6C1C46B9A81C87B5416A5D@namprd16.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlllcywgSSBhZ3JlZSB0aGF0IHRoZSBwcm9ibGVtIGlzIGVycm9yIGhhbmRsaW5n LiZuYnNwOyBJIGdldCB0aGF0IGl0IGlzIHRyaXZpYWwgdG8gZGlzdGluZ3Vpc2ggZW5jcnlwdGVk IGZyb20gdW5lbmNyeXB0ZWQsIGJ1dCBJIHdvdWxkIGFwcHJlY2lhdGUgaXQgaWYgdGhlIHNwZWMg Y291bGQgY2xhcmlmeSB0aGUgYXBwcm9wcmlhdGUNCiBhY3Rpb25zIGluIHRoZSBzY2VuYXJpbyB3 aGVyZSBhbiB1bmVuY3J5cHRlZCAobm9uLWFwcGRhdGEpIHJlY29yZCBpcyByZWNlaXZlZCBhZnRl ciBrZXlzIGhhdmUgYmVlbiBpbnN0YWxsZWQgaW4gdGhlIGNvbm5lY3Rpb24gc3RhdGUuJm5ic3A7 IEl0IHdvdWxkIGJlIHN0cmFuZ2UgdG8gc2VuZCBhbiBhbGVydCBpbiByZXNwb25zZSB0byBhbiBh bGVydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5QUzogSSB3YXMgdGVzdGluZyB3aXRoIE9w ZW5TU0wgd2hlbiBJIGhpdCB0aGUgaW50ZXJvcCBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZy b206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJs YWNrIj5NYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEFwcmlsIDI2LCAyMDE3IGF0IDg6NDIgQU08YnI+DQo8 Yj5UbzogPC9iPiZxdW90O21yZXhAc2FwLmNvbSZxdW90OyAmbHQ7bXJleEBzYXAuY29tJmd0Ozxi cj4NCjxiPkNjOiA8L2I+SWxhcmkgTGl1c3ZhYXJhICZsdDtpbGFyaWxpdXN2YWFyYUB3ZWxoby5j b20mZ3Q7LCBSb2Vsb2YgRHUgVG9pdCAmbHQ7Um9lbG9mX0R1dG9pdEBzeW1hbnRlYy5jb20mZ3Q7 LCAmcXVvdDt0bHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+W0VYVF0gUmU6IFtUTFNdIEFsZXJ0IGFmdGVyIHNlbmRpbmcgU2VydmVySGVs bG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ T24gMjYgQXByaWwgMjAxNyBhdCAyMjoyNSwgTWFydGluIFJleCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1yZXhAc2FwLmNvbSI+bXJleEBzYXAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43 NXB0O21hcmdpbi1yaWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FV T1RFIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj QjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0 O21hcmdpbi1yaWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ VGhlIGNvZGUgSSB3YXMgdGFsa2luZyBhYm91dCB3YXMgaGFuZGxpbmcgdGhlIHNwZWNpYWwgY2Fz ZSB0aGF0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnNlcnZlciBtaWdodCByZWNlaXZlIGVpdGhl ciBlbmNyeXB0ZWQgb3IgdW5lbmNyeXB0ZWQgYWxlcnQgaW4gcmVzcG9uc2U8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj50byBpdHMgZmxpZ2h0LiBBbmQgdGhlIGRpZmZlcmVuY2UgaXQgbWFrZXMgaXMganVz dCB3aGF0IGVycm9yIGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ZGVjbGFyZWQgYXMgYWJvcnQgcmVh c29uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPlVwIHRvIFRMU3YxLjIgdGhlcmUgd2FzIG5vIGNvbmZ1c2lvbiBhYm91dCB3aGV0 aGVyIGEgVExTIHJlY29yZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPndhcyBlbmNyeXB0ZWQgb3Igbm90 OiBldmVyeXRoaW5nIGJlZm9yZSAmcXVvdDtDaGFuZ2VDaXBoZXJTcGVjJnF1b3Q7IGlzIGNsZWFy dGV4dCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5ldmVyeXRoaW5nIHRoZXJlYWZ0ZXIgaXMgZW5jcnlw dGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPlRoYXQncyBub3QgYSBwcm9ibGVtIGhlcmUgZWl0aGVyLiZuYnNwOyZuYnNwO0l0 J3MgdHJpdmlhbCB0byB0ZWxsIGJldHdlZW4gYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5lbmNyeXB0 ZWQgcmVjb3JkIGFuZCBhbiB1bmVuY3J5cHRlZCBvbmUuJm5ic3A7Jm5ic3A7VGhlIHF1ZXN0aW9u IC0gaWYgdGhlcmUgaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hbnkgLSBpcyB3aGVuIHRvIHN0YXJ0 IGVuY3J5cHRpbmcgaWYgdGhlcmUgaGFwcGVucyB0byBiZSBhbiBlcnJvci48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_D9728A8826894E7D94D6820F83A49AB9symanteccom_-- From nobody Wed Apr 26 06:45:01 2017 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 4A64E129BAC for ; Wed, 26 Apr 2017 06:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 DxWt2NIGJAs8 for ; Wed, 26 Apr 2017 06:44:59 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA10129BB2 for ; Wed, 26 Apr 2017 06:44:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 75EB0408C8; Wed, 26 Apr 2017 16:44:58 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id QINyTo2JCM5b; Wed, 26 Apr 2017 16:44:58 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 4ACCCC4; Wed, 26 Apr 2017 16:44:58 +0300 (EEST) Date: Wed, 26 Apr 2017 16:44:56 +0300 From: Ilari Liusvaara To: Martin Thomson Cc: "tls@ietf.org" Message-ID: <20170426134456.GB29859@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170426071952.GA29159@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 13:45:00 -0000 On Wed, Apr 26, 2017 at 10:00:19PM +1000, Martin Thomson wrote: > On 26 April 2017 at 17:19, Ilari Liusvaara wrote: > > AFAIK, the only situations where client can abort sending 0-RTT data > > is noticing lack of server EarlyData extension (so server isn't > > listening anyway), or if the entiere handshake is aborted.. Doing it > > in other situations leads to subtle race conditions. > > NSS stops sending 0-RTT as soon as it processes EncryptedExtensions. > It also stops if it receives a HelloRetryRequest. In both cases you > know that the server is trial decrypting and so it will correctly > handle more 0-RTT data, but there is no point sending more if you know > that it is junk. Oh yeah, there is also HelloRetryRequest that aborts 0-RTT data. But stopping on receiving EncryptedExtensions with EarlyData extension is racy. -Ilari From nobody Wed Apr 26 07:16:56 2017 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 620DD12EB82 for ; Wed, 26 Apr 2017 07:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01] 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 7CepUqkSWgSw for ; Wed, 26 Apr 2017 07:16:47 -0700 (PDT) Received: from claranet-outbound-smtp07.uk.clara.net (claranet-outbound-smtp07.uk.clara.net [195.8.89.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5EB12EB8C for ; Wed, 26 Apr 2017 07:10:38 -0700 (PDT) Received: from host86-133-145-70.range86-133.btcentralplus.com ([86.133.145.70]:24561 helo=[192.168.1.64]) by relay07.mail.eu.clara.net (relay.clara.net [81.171.239.37]:10465) with esmtpa (authdaemon_plain:drh) id 1d3NeJ-0006Wn-Mv (return-path ); Wed, 26 Apr 2017 14:10:33 +0000 To: Ilari Liusvaara , Martin Rex References: <926e3b6b-5f0c-e00a-5ba3-9a2cfcdc4e8f@drh-consultancy.co.uk> <20170426132358.06FA71A698@ld9781.wdf.sap.corp> <20170426134140.GA29859@LK-Perkele-V2.elisa-laajakaista.fi> Cc: tls@ietf.org From: Dr Stephen Henson Message-ID: Date: Wed, 26 Apr 2017 15:10:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170426134140.GA29859@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 14:16:54 -0000 On 26/04/2017 14:41, Ilari Liusvaara wrote: > On Wed, Apr 26, 2017 at 03:23:57PM +0200, Martin Rex wrote: >> >> The issue with RSA-PSS digital signatures is that they were defined >> with additional (unnecessary) parameters that are encoded (=hidden) in the >> ASN.1 AlgorithmIdentifier, and that are therefore unspecified when >> RSA-PSS is requested as (rsa-pss,sha-256) rather than with an ASN.1 >> AlgorithmIdentifier. > > TLS 1.3 specifies what values those parameters have for various > SignatureSchemes. > >> The additional, unnecessary parameters are "saltLen" and >> "MaskGenerationFunction" (MGF), and the commonly-used MaskGenerationFunction >> (mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash). > > Also specified. > For TLS message signatures yes. For signatures on certificates I think it is far less clear. For salt lengths the spec says: "When used in signed TLS handshake messages, the length of the salt MUST be equal to the length of the digest output." It says nothing about salt length restrictions (if any) on certificates. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Wed Apr 26 10:04:13 2017 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 9ED49131518 for ; Wed, 26 Apr 2017 10:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 cAGMbOczopVp for ; Wed, 26 Apr 2017 10:04:07 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61B13151A for ; Wed, 26 Apr 2017 10:03:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 86F34277D4; Wed, 26 Apr 2017 20:03:53 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 3kILYml3mUvv; Wed, 26 Apr 2017 20:03:53 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 4B87D2317; Wed, 26 Apr 2017 20:03:53 +0300 (EEST) Date: Wed, 26 Apr 2017 20:03:51 +0300 From: Ilari Liusvaara To: Andrei Popov Cc: David Benjamin , "tls@ietf.org" Message-ID: <20170426170351.GA30439@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160904105637.sjl4wmr2hc2mito6@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] CertficateRequest extension encoding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 17:04:10 -0000 On Mon, Sep 05, 2016 at 09:46:51PM +0000, Andrei Popov wrote: > > Do we need to make it this flexible? The idea was to avoid adding > complexity to the certificate filtering code in the TLS stack, and > instead filter by OIDs in the PKI library. PKI libraries already > inspect and match OID values, so this should be a relatively small > change for them. Haven't found an answer to this yet... How are the OIDs encoded exactly? Does the value of 'certificate_extension_oid' include redundant OBJECT IDENTIFIER tag and length, or not? That is, is id-pe-nsa [1.3.6.1.5.5.7.1.23] (just to pick an example) in certificate_extension_oid field encoded as: 1) 2B 06 01 05 05 07 01 17 (no tag/length) 2) 06 08 2B 06 01 05 05 07 01 17 (tag/length included). ? -Ilari From nobody Wed Apr 26 12:03:41 2017 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 111151286B1 for ; Wed, 26 Apr 2017 12:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 ZksI8Ca6yuDl for ; Wed, 26 Apr 2017 12:03:37 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0134.outbound.protection.outlook.com [104.47.34.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF82C128B8D for ; Wed, 26 Apr 2017 12:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3s+2gSHbY3S/dvkyZza0cyhn0SOfF808gV7IJ9+ra+c=; b=XB02bfbAWs0NEmFkelxOWVKQZEN6fHxgvbt207uDYsNvtzmQG5KSTSBuTXr7Hk3xQ2vwALqf/9STF8G+MOzp88gPZ9LF0PSpKNqiNC6VhlWmRBRxGIS70BiSyq1lkTStOZ/L+C/V4ukQMtBZcupECSkWEUjRJdZMaRRElSnk4vs= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0089.namprd21.prod.outlook.com (10.161.141.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.4; Wed, 26 Apr 2017 19:03:35 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.1061.008; Wed, 26 Apr 2017 19:03:35 +0000 From: Andrei Popov To: "ilariliusvaara@welho.com" CC: David Benjamin , "tls@ietf.org" Thread-Topic: [TLS] CertficateRequest extension encoding Thread-Index: AQHSBpsXZcombga0NEGFs2xYmfILPaBpmgGAgAAAfICAAc2xcIFt6MOAgAAgapA= Date: Wed, 26 Apr 2017 19:03:34 +0000 Message-ID: References: <20160904105637.sjl4wmr2hc2mito6@LK-Perkele-V2.elisa-laajakaista.fi> <20170426170351.GA30439@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170426170351.GA30439@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0089; 7:Xa/4vCyLNxumE5vmCrNkryVPminCt51sVCGsJ5+v2ZBb6XV0SZWwuHAB6GnRh7++4E05bc4gJj6Of2jV9p5DujUzl2Z0rMh3Ijt3snt1gN1IJeM/Od1F7fGrsOeCEoo4nZ5rZcjv1OsbG+q5b08Y1U8WvUxEDFrgCHcdkD9cz3BRxadnvc+nrrxchXp8J7KDD8HJHZTTuCxVzFaltoJyx59U+Z/oMyiXKnkQV9XL12e8qhG3h0hHkFVncXBKOw6nX7yiA0oSoTDS7cFNpgcNbS1935tpxjMP1kvGW1x7MAxfXHMK0rtzg8YiZ9cXG4zk9MVOqvm1Kr0eyXZRSvhkUfqIVDuYdfQ1W4BSWu0fQmQ= x-ms-office365-filtering-correlation-id: 9857b1ce-8f2c-4d82-5a8e-08d48cd6f0aa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR21MB0089; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:DM2PR21MB0089; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0089; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39860400002)(39450400003)(39840400002)(39850400002)(57704003)(13464003)(24454002)(377454003)(3660700001)(53936002)(54356999)(76176999)(50986999)(74316002)(10090500001)(122556002)(9686003)(2900100001)(6916009)(2950100002)(189998001)(4326008)(54906002)(10290500003)(99286003)(77096006)(8990500004)(2501003)(2906002)(6246003)(33656002)(3280700002)(6436002)(2351001)(55016002)(229853002)(102836003)(6116002)(6506006)(8936002)(7696004)(8676002)(1730700003)(81166006)(53546009)(25786009)(5005710100001)(7736002)(305945005)(93886004)(86362001)(110136004)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0089; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 19:03:34.9874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0089 Archived-At: Subject: Re: [TLS] CertficateRequest extension encoding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 26 Apr 2017 19:03:39 -0000 SGkgSWxhcmksDQoNCkkgZG9uJ3QgaGF2ZSB0aGlzIGltcGxlbWVudGVkIHlldCwgYnV0IHllcywg dGFnL2xlbmd0aCBzaG91bGQgYmUgaW5jbHVkZWQuIFNhbWUgYXMgaW4gdGhlIGFjdHVhbCBjZXJ0 Lg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogaWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tIFttYWlsdG86aWxhcmlsaXVzdmFhcmFAd2VsaG8u Y29tXSANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjYsIDIwMTcgMTA6MDQgQU0NClRvOiBBbmRy ZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IERhdmlkIEJlbmphbWlu IDxkYXZpZGJlbkBjaHJvbWl1bS5vcmc+OyB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExT XSBDZXJ0ZmljYXRlUmVxdWVzdCBleHRlbnNpb24gZW5jb2RpbmcNCg0KT24gTW9uLCBTZXAgMDUs IDIwMTYgYXQgMDk6NDY6NTFQTSArMDAwMCwgQW5kcmVpIFBvcG92IHdyb3RlOg0KPiANCj4gRG8g d2UgbmVlZCB0byBtYWtlIGl0IHRoaXMgZmxleGlibGU/IFRoZSBpZGVhIHdhcyB0byBhdm9pZCBh ZGRpbmcgDQo+IGNvbXBsZXhpdHkgdG8gdGhlIGNlcnRpZmljYXRlIGZpbHRlcmluZyBjb2RlIGlu IHRoZSBUTFMgc3RhY2ssIGFuZCANCj4gaW5zdGVhZCBmaWx0ZXIgYnkgT0lEcyBpbiB0aGUgUEtJ IGxpYnJhcnkuIFBLSSBsaWJyYXJpZXMgYWxyZWFkeSANCj4gaW5zcGVjdCBhbmQgbWF0Y2ggT0lE IHZhbHVlcywgc28gdGhpcyBzaG91bGQgYmUgYSByZWxhdGl2ZWx5IHNtYWxsIA0KPiBjaGFuZ2Ug Zm9yIHRoZW0uDQoNCkhhdmVuJ3QgZm91bmQgYW4gYW5zd2VyIHRvIHRoaXMgeWV0Li4uDQoNCg0K SG93IGFyZSB0aGUgT0lEcyBlbmNvZGVkIGV4YWN0bHk/IERvZXMgdGhlIHZhbHVlIG9mICdjZXJ0 aWZpY2F0ZV9leHRlbnNpb25fb2lkJyBpbmNsdWRlIHJlZHVuZGFudCBPQkpFQ1QgSURFTlRJRklF UiB0YWcgYW5kIGxlbmd0aCwgb3Igbm90Pw0KDQpUaGF0IGlzLCBpcyBpZC1wZS1uc2EgWzEuMy42 LjEuNS41LjcuMS4yM10gKGp1c3QgdG8gcGljayBhbiBleGFtcGxlKSBpbiBjZXJ0aWZpY2F0ZV9l eHRlbnNpb25fb2lkIGZpZWxkIGVuY29kZWQgYXM6DQoNCjEpIDJCIDA2IDAxIDA1IDA1IDA3IDAx IDE3ICAobm8gdGFnL2xlbmd0aCkNCjIpIDA2IDA4IDJCIDA2IDAxIDA1IDA1IDA3IDAxIDE3ICAo dGFnL2xlbmd0aCBpbmNsdWRlZCkuDQoNCj8NCg0KDQotSWxhcmkNCg== From nobody Wed Apr 26 17:45:29 2017 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 86B95129AD5 for ; Wed, 26 Apr 2017 17:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QNP2arl09awB for ; Wed, 26 Apr 2017 17:45:26 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 1074412940F for ; Wed, 26 Apr 2017 17:45:26 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id 88so9185160lfr.0 for ; Wed, 26 Apr 2017 17:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9LgeLVU6zsLF6LOcjCbiXUdILmJugmgR91HN4/v2tYw=; b=W5821i1trkdwdw6lqo7ic0YUdbQX/3da/OfJFY/KyLIehWKZmJd2zozwUyJJ4bFbsP AnnypBV3bNqWhirSZGD8wTPg2XR6YoArwmO2Uuy6UjwprLbTfv3oExRPWVwoThmT4eA8 n3YhOR3uaHyorGN/NzRWA/TX1Gxg4PhBziekTpwbg0wo1RZMuIVGLlqvXSOAe8H3ADeP aEitX0p2UdEav3VRp+vSWB+JTSYyF7ZvZ2SkUzmVh6Ya7Afr5UboNOS/FsgdNw39LhdN hWLulHdLA+gG80hGIrCD0B3XBhAojAObSsQBjhUptFLWN6rV52YOapLp9XbBJQXWHZFt YO6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9LgeLVU6zsLF6LOcjCbiXUdILmJugmgR91HN4/v2tYw=; b=A6OP6Ebc9CKbj0JglMxcsrEbNAxhX+ZRleAvoKAetubu8FZANQ1gY3IbsE0nODfotg qMFcDkDf8P0lIqnWiRmrILuW0W/TnDX+36WjKz470rclmhFFAzIdge0jcAmUdBNVi7lG y7FyrMbz0IwBO+Ob8Fu/9PzhFakPENOlrxVmNL0/l4KkZWmRdiV7gY2c35r1ZG1Oetie +ohlEokSNxbauhz/g9X8gzLB4dAcYA6ZK381DvoI1dHhzilDQm8HSgPcaPRBJCbclGxK 9lTsWud5odByagjQ41zIWWPROPPryfPVayAV7yMXBplY+LTJExWMddlDXg2o6AwIDqPm pKag== X-Gm-Message-State: AN3rC/7a9tK0uE3zZFzMpPQ9Fzsb0Wi9f1sM08CVAjZ3Dlg6W/qFfyYr FWvFNQgoXQ/ndrSHRiVECCCebxeJ+g1m X-Received: by 10.25.79.27 with SMTP id d27mr879665lfb.76.1493253924364; Wed, 26 Apr 2017 17:45:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 26 Apr 2017 17:45:23 -0700 (PDT) In-Reply-To: <20170426134456.GB29859@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170426071952.GA29159@LK-Perkele-V2.elisa-laajakaista.fi> <20170426134456.GB29859@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Thu, 27 Apr 2017 10:45:23 +1000 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Alert after sending ServerHello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 27 Apr 2017 00:45:27 -0000 On 26 April 2017 at 23:44, Ilari Liusvaara wrote: > But stopping on receiving EncryptedExtensions with EarlyData extension > is racy. How so? From nobody Fri Apr 28 05:51:02 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F1D12940E; Fri, 28 Apr 2017 05:51:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149338386123.2854.6422145758540267467@ietfa.amsl.com> Date: Fri, 28 Apr 2017 05:51:01 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 12:51:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : D/TLS IANA Registry Updates Authors : Joe Salowey Sean Turner Filename : draft-ietf-tls-iana-registry-updates-01.txt Pages : 13 Date : 2017-04-28 Abstract: This document changes the IANA registry policy for a number of registries related to DTLS and TLS, renames some of the registries for consistency, and adds notes to many of the registries. As a result, this document updates many RFCs (see updates header). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 28 06:03:31 2017 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 EBC4912948A for ; Fri, 28 Apr 2017 06:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 RqMyslN-Z61t for ; Fri, 28 Apr 2017 06:03:28 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 E65DB129C3D for ; Fri, 28 Apr 2017 06:00:15 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id m36so49257141qtb.0 for ; Fri, 28 Apr 2017 06:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=XVG44GIkT+zk4poc7B4fI9kOmV5rjCxF1j9Ylw6j7fc=; b=WSQ/HZXfkdZ8S5hlb0LrEghQUOTqbWXdX4TSo4BCDb695Xh9eah+EjUVlCYQXs+ULn D0kcJBbFvf4x2EQhnlho6rFfwsDxV4zOo9Kt4GHDdn2mV0OPDd9AQfa8d3RKajSu0Hrs ngLOUr1Iz1DrMUEbb3loC7mTdRyVmrfBbQgeE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=XVG44GIkT+zk4poc7B4fI9kOmV5rjCxF1j9Ylw6j7fc=; b=XpAyK6JXsVPrVHJKvYaYNZi/KIl9p/dczsgnHYdAjfg3XWGCnajUZ7Rpoztlwz9ZCI jZqgBO4aLEvepxj+LSIXITTtwpag9dzDh2fsmYRu/vesC/U0vc5nWW3CyKWZ08da6zCr y5RF1RazRtkezdEB9QTrOmj5TscIviPjsVo/rPFX/kcN5xrJZdVxaZRIj8kygM3E97xi 55yV7G1FLj8U16VfcTvPLpaPM8IVsLRHvDnorvlI6+idZmfyO82qQPQ/QJY12pP00Fr6 D1b9GujTA8UZsE5ITKgqUCvUQI0Z3UpJtcERjcYOKi4CBctx+j6BQchpCEC7FWXCr+vY 9jmA== X-Gm-Message-State: AN3rC/4zZP4xvhgOSZ4sZEL5QcWasaJ0ghv8tUITzCxc2J80Mnl/h4zZ yo9X43i4ou6AHTvs6jk= X-Received: by 10.237.62.253 with SMTP id o58mr9476359qtf.152.1493384414682; Fri, 28 Apr 2017 06:00:14 -0700 (PDT) Received: from [172.16.0.18] ([96.231.229.219]) by smtp.gmail.com with ESMTPSA id u49sm3576118qte.44.2017.04.28.06.00.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 06:00:13 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 28 Apr 2017 09:00:12 -0400 References: <149338386123.2854.6422145758540267467@ietfa.amsl.com> To: "" In-Reply-To: <149338386123.2854.6422145758540267467@ietfa.amsl.com> Message-Id: <08DF1D59-2255-4E85-B748-D97159F0EF14@sn3rd.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 13:03:30 -0000 All, Joe and I updated the draft. GH repo is @: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates Note that I=E2=80=99d to rewrite the introduction to be briefer and move = the rationale for the changes to the section where the change is = suggested. I think this will make it easier to review, i.e., there will = be less scrolling around trying to remember why the change was made. And, I=E2=80=99ll need to fix the non-wrapping notes :/ After these two changes, I think this one will be ready for WGLC. spt > On Apr 28, 2017, at 08:51, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security of the IETF. >=20 > Title : D/TLS IANA Registry Updates > Authors : Joe Salowey > Sean Turner > Filename : draft-ietf-tls-iana-registry-updates-01.txt > Pages : 13 > Date : 2017-04-28 >=20 > Abstract: > This document changes the IANA registry policy for a number of > registries related to DTLS and TLS, renames some of the registries > for consistency, and adds notes to many of the registries. As a > result, this document updates many RFCs (see updates header). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-01 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates= -01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updates-0= 1 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Apr 28 09:35:39 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C22D12EABA; Fri, 28 Apr 2017 09:35:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149339733821.2963.2565052977577512706@ietfa.amsl.com> Date: Fri, 28 Apr 2017 09:35:38 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-20.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 16:35:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-20.txt Pages : 137 Date : 2017-04-28 Abstract: This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-20 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 28 09:41:46 2017 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 006D01279EB for ; Fri, 28 Apr 2017 09:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham 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 O0PbSW3uYr70 for ; Fri, 28 Apr 2017 09:41:43 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 B432912751F for ; Fri, 28 Apr 2017 09:38:17 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id p143so16741112yba.2 for ; Fri, 28 Apr 2017 09:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=gDl2wQpLrPZRgA/G9QQonrx7iJFDG3ZMABV+ryD3S40=; b=oIv3X+kR9oToC//xL+0SCd63L4lf9O8H6cMHPDX9XqQlRghh+zekjEiG+nJ4wyqXd4 aZ4S88nyvAI+ggacJz34+6LlhvvExIiOEIi+W9g02U1ojhIQWLLPdkjOyRlrYvXE6tVs aGVqWHHHslloXjEKyY/E4qXWV3lWgZAoKbTOHWtx3HX9N58hE6GRXmx5I3zRs1gtmxG/ 9sk9kP8Mq8z3YjIEPq67pjfTQn9usADQqdXxsNgEC6dQ36VaFEiI5q5Dp+RTpZ0Y/Kxj g1VNARZDc3ktFiejL0G76uuPe4ZhCdvLaWY1YFuOJb37rZH2V1QZaMCyw3dQsAvY2N8O B4YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gDl2wQpLrPZRgA/G9QQonrx7iJFDG3ZMABV+ryD3S40=; b=iB0JxNyZRdsNuD0Qp6Qs1Q3A2qmor0/SbvrRPpxf1kROwljYNI8qJPmJEXzGuiCjbo wsDLNCVlGt+Opl1YMTEdUpXI+pEZfsFtLpwLgutE7/83ISam2nBIwRclZKAajPgvajHm LqOm2pyRnj3SMKWP6kvPHYUajD63wV/Fsmh3yvCbnM2q8JPebhUZoYmAcNtjVrax8cWT mbfK21IKzO59OXxfXlQHriLiWAMYQtmjIjUxBmHmBdr5EwH+3JyWwnCDEry10wlf00om TAempHnq0DS3iF8epT8QgnXteDAQzCZGD+VymbrFU8+KgU/IRm4AHcBBDlA9bPwj4kJD wjBg== X-Gm-Message-State: AN3rC/7rUvb/7K3RPMerGdl63lBe/J6ecN5/eHBMraEt7rBULXx+uv7I 9O1q15cTRORFLMv3+oC/SXfOzP3n7io19Vs= X-Received: by 10.37.174.24 with SMTP id a24mr9971643ybj.50.1493397496703; Fri, 28 Apr 2017 09:38:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Fri, 28 Apr 2017 09:37:36 -0700 (PDT) From: Eric Rescorla Date: Fri, 28 Apr 2017 09:37:36 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f403045da3584cce06054e3cb372 Archived-At: Subject: [TLS] draft-ietf-tls-tls13-20 is up X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 16:41:45 -0000 --f403045da3584cce06054e3cb372 Content-Type: text/plain; charset=UTF-8 This version incorporates the WGLC feedback and discussions in Chicago. Changes in -20: - Add "post_handshake_auth" extension to negotiate post-handshake authentication (*). - Shorten labels for HKDF-Expand-Label so that we can fit within one compression block (*). - Define how RFC 7250 works (*). - Re-enable post-handshake client authentication even when you do PSK. The previous prohibition was editorial error. - Remove cert_type and user_mapping, which don't work on TLS 1.3 anyway. - Added the no_application_protocol alert from {{RFC7301}} to the list of extensions. - Added discussion of traffic analysis and side channel attacks. -Ekr --f403045da3584cce06054e3cb372 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This version incorporates the WGLC feedback and discussion= s in Chicago.

Changes in -20:

<= div>- Add "post_handshake_auth" extension to negotiate post-hands= hake authentication
=C2=A0 (*).

- Shorte= n labels for HKDF-Expand-Label so that we can fit within one
=C2= =A0 compression block (*).

- Define how RFC 7250 w= orks (*).

- Re-enable post-handshake client authen= tication even when you do PSK.
=C2=A0 The previous prohibition wa= s editorial error.

- Remove cert_type and user_map= ping, which don't work on TLS 1.3 anyway.

- Ad= ded the no_application_protocol alert from {{RFC7301}} to the list
=C2=A0 of extensions.

- Added discussion of traf= fic analysis and side channel attacks.


<= /div>
-Ekr

--f403045da3584cce06054e3cb372-- From nobody Fri Apr 28 09:49:24 2017 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12557129C66; Fri, 28 Apr 2017 09:49:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149339815903.2911.5046716687842789581@ietfa.amsl.com> Date: Fri, 28 Apr 2017 09:49:19 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 16:49:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla Hannes Tschofenig Nagendra Modadugu Filename : draft-ietf-tls-dtls13-00.txt Pages : 36 Date : 2017-04-28 Abstract: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls13-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 28 09:54:26 2017 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 A8ECC1294C5 for ; Fri, 28 Apr 2017 09:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 KWWcwhH-VUxl for ; Fri, 28 Apr 2017 09:54:20 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 3CA151292AE for ; Fri, 28 Apr 2017 09:50:52 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l18so33750053ywh.3 for ; Fri, 28 Apr 2017 09:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kkAWyT6XkrWyUbqcRPZ5XYqx6+WKIghF1HYFf22Pc2w=; b=xLDfYbT2RzT/oe+nhaIwSlO7eMk7pDdzfdg2ltPyKQ/DQjNGoHY0eaJM+W+e/kuvl6 yJyMoHjP7CSfMxm2Ml9QUDAm4Its0YPCZNMBwMITqxlUmEFYiNh3CSEEOQryOn1xXMWn rfjsHvIR/a6AIDmpsYZ+yLUP44zMq5shXEQFK4nACxyyuxhwGioOQlfrvCYYcvNkjsfh S4RaKY+ge8QGzUHxboJYtEuomPIg7UpofJETp4t3XYKSKNxX/iyZLQLd6k1dJL1pKM7h jkv7whl95HTCGLS2vebrYGGIL/ic60A78/mOxEugF2RZgVBLpTwP1HF716wHTIBdHSWc Z9Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kkAWyT6XkrWyUbqcRPZ5XYqx6+WKIghF1HYFf22Pc2w=; b=QejhxxiwKzZrWVhBVA7Q5g1KnuhGq3jjXZ6OJYpU9WlDdMk7OAigbXPgOncp8EI7Fg 23OQbfuxy1GAGbeZacnC/kmZtdcHGkjproHo+H0JUt5qkIgAEPd8JGhZYvkUtJwvX1GE 1yfC7hBm1o4O/1lzL3/y59HQKGoKKx1LmrfIJg2GThPKFR+xUHUl/bS49/aCDJMhKyTb HlPsbkwYUAgPNCnizRQHKGq5NAzlT9/uyeRThBKxSyEiLCZMSeDBBhYoEQmHZ/Vt/oY+ NHV1qlplh0Mhn6z4tBdb1g2VGSfD3epv7Bj6Y6cauoXvbPiEcjGP1qosxlj9M0/hIFQ1 sP1A== X-Gm-Message-State: AN3rC/4mqSDxeAjkjFSCR8nxOhDOA2tAsT4N53S3g2BpcjpH1ylYq15I wli+4uc4NCk1rBJ6Uom5qL4mP55XmQ== X-Received: by 10.129.52.141 with SMTP id b135mr9924609ywa.85.1493398251485; Fri, 28 Apr 2017 09:50:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Fri, 28 Apr 2017 09:50:11 -0700 (PDT) In-Reply-To: References: <4CBA4B06-411F-4B87-B664-D451260F8C25@sn3rd.com> From: Eric Rescorla Date: Fri, 28 Apr 2017 09:50:11 -0700 Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary=001a114089844a114e054e3ce0aa Archived-At: Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-dtls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 16:54:22 -0000 --001a114089844a114e054e3ce0aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Draft submitted (it should be identical to the individual submission) -Ekr On Fri, Apr 7, 2017 at 2:14 PM, Sean Turner wrote: > It=E2=80=99s now the 7th so the call for adoption is complete. Though Be= n was the > only commenter on list (and thanks Ben) there was definitely support for > adopting this draft at the Chicago session. This bit of administrivia is > complete so authors feel free to submit a WG version at your leisure. I= =E2=80=99ve > pre-approved "draft-ietf-tls-dtls13" as the draft's name and created a > github repo: https://github.com/tlswg/dtls13-spec. > > spt > > > On Mar 22, 2017, at 18:50, Sean Turner wrote: > > > > All, > > > > -00 of draft-rescorla-tls-dtls13 [0][1] was discussed at IETF 97 [2]. > It=E2=80=99s now at version -01 and GH issues are slowly rolling in. It= =E2=80=99s also on > our agenda again at IETF 98, and DTLS a chartered work item, so it seems > like it=E2=80=99s time to get the WG adoption process started for this in= dividual > draft. Please let the list know whether you support adoption of the draf= t > and are willing to review/comment on the draft before 20170406. If you > object to its adoption, please let us know why. > > > > Cheers, > > > > J&S > > > > [0] https://github.com/ekr/dtls13-spec > > [1] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-dtls13 > > [2] https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-dtls-13-01.pdf > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114089844a114e054e3ce0aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Draft submitted (it should be identical to the individual = submission)

-Ekr


On Fri, Apr 7, 2017 at 2:14 PM= , Sean Turner <sean@sn3rd.com> wrote:
It=E2=80=99s now the 7th so the call for adoption is complete.=C2= =A0 Though Ben was the only commenter on list (and thanks Ben) there was de= finitely support for adopting this draft at the Chicago session.=C2=A0 This= bit of administrivia is complete so authors feel free to submit a WG versi= on at your leisure.=C2=A0 I=E2=80=99ve pre-approved "draft-ietf-tls-dt= ls13" as the draft's name and created a github repo: ht= tps://github.com/tlswg/dtls13-spec.

spt

> On Mar 22, 2017, at 18:50, Sean Turner <sean@sn3rd.com> wrote:
>
> All,
>
> -00 of draft-rescorla-tls-dtls13 [0][1] was discussed at IETF 97 [2].= =C2=A0 It=E2=80=99s now at version -01 and GH issues are slowly rolling in.= =C2=A0 It=E2=80=99s also on our agenda again at IETF 98, and DTLS a charter= ed work item, so it seems like it=E2=80=99s time to get the WG adoption pro= cess started for this individual draft.=C2=A0 Please let the list know whet= her you support adoption of the draft and are willing to review/comment on = the draft before 20170406.=C2=A0 If you object to its adoption, please let = us know why.
>
> Cheers,
>
> J&S
>
> [0] https://github.com/ekr/dtls13-spec
> [1] https://datatracker.ietf.org= /doc/html/draft-rescorla-tls-dtls13
> [2] https://www.ietf.org= /proceedings/97/slides/slides-97-tls-dtls-13-01.pdf

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114089844a114e054e3ce0aa-- From nobody Fri Apr 28 11:22:25 2017 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 27BA91273B1 for ; Fri, 28 Apr 2017 11:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vz0Z4RBFFJmd for ; Fri, 28 Apr 2017 11:22:21 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A15012950B for ; Fri, 28 Apr 2017 11:20:58 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 65C277A330A for ; Fri, 28 Apr 2017 18:20:39 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 28 Apr 2017 14:20:38 -0400 To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] Session ticket (re-)use in multi-process applications? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 18:22:24 -0000 Unlike many/most browsers, Postfix makes each TLS connection from a = separate smtp(8) client process. TLS session reuse is supported via a shared service process tlsmgr(8) = which maintains a cache of saved sessions for peer destinations that have provided session = resumption data (session tickets, or just a session id). Once a session is saved into the session database, it is used by = multiple clients until it expires (with TLS <=3D 1.2, resumption typically does not create a new = session, and the same session remains in the cache). How should this change with TLS 1.3? The draft says: Clients SHOULD attempt to use each ticket no more than once, with more recent tickets being used first. What does this mean in practice? What happens if Postfix continues to = use the same ticket multiple times anyway? Will servers somehow invalidate the = ticket after first use? Are the consequences of reuse more severe than with = TLS 1.2? To avoid re-use, it would seem that tlsmgr(8) would have to delete the = ticket from the cache after vending it to an smtp(8) client. For the cache to = work at all well, with sessions consistently resumed after an initial = ramp-up, it would seem that the cache would now need to store a list of tickets, = rather than just a single ticket for each destination. If so, that's = considerable new complexity. :-( I'd need to prepend tickets to the cache slot, rather than replace the = cache slot, and trim tickets from the end if the list of available tickets = grows too long. Then when a client asks for a ticket, pop the first entry of = the list. This design would have to coexist with the existing support for TLS <=3D = 1.2 session resumption. So some cache slots would be single-instance = multi-use, and others multi-instance single-use. When resuming with a TLS 1.3 peer, what happens if the peer is behind a = load balancer, and some of the nodes are still TLS 1.2? Does the handshake = fail, or we somehow end-up doing a full TLS 1.2 handshake? (Postfix will in many cases "see through" load-balancers, because = STARTTLS is preceded by the peer's SMTP banner and EHLO response which include a notional remote server name, and when that's server-specific, I use a separate cache entry for each server). I'll also need to figure out how all of this plays out in the new = OpenSSL 1.1.1 code and its "new session" callbacks. Unlike most other TLS 1.3 changes, this one is not going to be = particularly transparent to the application, unless ignoring the "SHOULD" and just reusing session tickets works against peer servers and within the = updated OpenSSL "new session" callback implementation. Obviously, the OpenSSL-specific issues I'll be hashing out elsewhere, = just mentioning that there are API implications to changes in how resumption = is to be handled... --=20 Viktor.= From nobody Fri Apr 28 11:30:09 2017 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 6C94B126B6D for ; Fri, 28 Apr 2017 11:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 5tRZQLz_xSMY for ; Fri, 28 Apr 2017 11:30:05 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 A50F51242F5 for ; Fri, 28 Apr 2017 11:30:05 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id u70so35020751ywe.2 for ; Fri, 28 Apr 2017 11:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=DeOV6UL5K01HvYY7Lb1K48vePF1m/CkN0RVmnhsMjh4=; b=hekByE+KN4s66CI7tce2q+NRVGTrPmriZJ8i/2JEztREl+YUoXGgVgNyfmYR0BCnbn uHfJrXLPabQ1NpHl2puxBMEmFQ9C9Z3zmTH/zrVBngVvEkRPcO7X7hH32z6UWsm4MoLP lpU5R8OafMrRvAJPh7D3qvzINhHoFxjDiA4D5SoDYC3JD8REHL/lrSyD3PJz1QU+FwGE K4XY/CdRNU9m6BtBshZ//1xIo7TeiAkxVKBITm+5skM/U5C/xuN3WdZ7Oq9BjOZWTN+g 9TUZ5Cta68PF2C/PxVrYoKItNl1Bxuj07m2ABpOMl/w0PDbYwiulCwOWxlafytFoRyM9 VurQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=DeOV6UL5K01HvYY7Lb1K48vePF1m/CkN0RVmnhsMjh4=; b=rTaj0NIm+IXo4qj2Cm2wf7NmiMAKFJ0WRTJHWHN3931wYJV7UjXjVfgdPXPIJGr8lD KxTDeerJXraclihtxMkQ+UgccIfq2Di3Pap1hMwKE4PRYMze5OQxP8pHGvhLhEzYhnOI N2vsic/QncvcWFEPciyHTGHbnXlfsuH1JLNcYuvvfkaq+DnQScncfbvNa48bF7TVM3ka /AuJFUJIXBMFxXY4m5p4LN5WPRmdC8e3JtY6mCtPz88webo3MfvKNXsd2tyrEbNKTM0G J3GAsBrKS478VST5SZuDYWDKAHdP/xgUkm8kh+Vc7K7qFvQf47ijJETF3SGXo5eI2Cqf xWag== X-Gm-Message-State: AN3rC/7LRow1i9fsKD26Qdig6LIusDemtzvfEBPFj67kud1kvOobSGky gYyPOP/XYExFUYlBiu5mkjeNgdT0bxXZ X-Received: by 10.13.212.65 with SMTP id w62mr9925627ywd.24.1493404204763; Fri, 28 Apr 2017 11:30:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Fri, 28 Apr 2017 11:29:24 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 28 Apr 2017 11:29:24 -0700 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary=001a114fc7d821f5a1054e3e4337 Archived-At: Subject: Re: [TLS] Session ticket (re-)use in multi-process applications? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 18:30:07 -0000 --001a114fc7d821f5a1054e3e4337 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 28, 2017 at 11:20 AM, Viktor Dukhovni wrote: > > Unlike many/most browsers, Postfix makes each TLS connection from a > separate smtp(8) client process. > > TLS session reuse is supported via a shared service process tlsmgr(8) > which maintains a cache of > saved sessions for peer destinations that have provided session resumption > data (session tickets, > or just a session id). > > Once a session is saved into the session database, it is used by multiple > clients until it > expires (with TLS <= 1.2, resumption typically does not create a new > session, and the same > session remains in the cache). > > How should this change with TLS 1.3? The draft says: > > Clients SHOULD attempt to use each > ticket no more than once, with more recent tickets being used first. > > What does this mean in practice? What happens if Postfix continues to use > the > same ticket multiple times anyway? Will servers somehow invalidate the > ticket > after first use? Are the consequences of reuse more severe than with TLS > 1.2? > Shouldn't be. Mostly, it allows attackers to correlate multiple sessions from the same client, which sounds like it's not an issue in your case. To avoid re-use, it would seem that tlsmgr(8) would have to delete the > ticket > from the cache after vending it to an smtp(8) client. For the cache to > work > at all well, with sessions consistently resumed after an initial ramp-up, > it > would seem that the cache would now need to store a list of tickets, rather > than just a single ticket for each destination. If so, that's considerable > new complexity. :-( > Well, the idea is that the server gives you a new ticket on each handshake, so that you don't have to reuse. When resuming with a TLS 1.3 peer, what happens if the peer is behind a load > balancer, and some of the nodes are still TLS 1.2? Does the handshake > fail, > or we somehow end-up doing a full TLS 1.2 handshake? > You should get a TLS 1.2 handshake, modulo bugs. -Ekr --001a114fc7d821f5a1054e3e4337 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 28, 2017 at 11:20 AM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:

Unlike many/most browsers, Postfix makes each TLS connection from a separat= e smtp(8) client process.

TLS session reuse is supported via a shared service process tlsmgr(8) which= maintains a cache of
saved sessions for peer destinations that have provided session resumption = data (session tickets,
or just a session id).

Once a session is saved into the session database, it is used by multiple c= lients until it
expires (with TLS <=3D 1.2, resumption typically does not create a new s= ession, and the same
session remains in the cache).

How should this change with TLS 1.3?=C2=A0 The draft says:

=C2=A0 =C2=A0Clients SHOULD attempt to use each
=C2=A0 =C2=A0ticket no more than once, with more recent tickets being used = first.

What does this mean in practice?=C2=A0 What happens if Postfix continues to= use the
same ticket multiple times anyway?=C2=A0 Will servers somehow invalidate th= e ticket
after first use?=C2=A0 Are the consequences of reuse more severe than with = TLS 1.2?

Shouldn't be. Mostly, it a= llows attackers to correlate multiple sessions from the same
clie= nt, which sounds like it's not an issue in your case.


To avoid re-use, it would seem that tlsmgr(8) would have to delete the tick= et
from the cache after vending it to an smtp(8) client.=C2=A0 For the cache t= o work
at all well, with sessions consistently resumed after an initial ramp-up, i= t
would seem that the cache would now need to store a list of tickets, rather=
than just a single ticket for each destination.=C2=A0 If so, that's con= siderable
new complexity. :-(

Well, the idea is t= hat the server gives you a new ticket on each handshake, so that
= you don't have to reuse.


When resuming with a TLS 1.3 peer, what happens if the peer is behind a loa= d
balancer, and some of the nodes are still TLS 1.2?=C2=A0 Does the handshake= fail,
or we somehow end-up doing a full TLS 1.2 handshake?
<= br>
You should get a TLS 1.2 handshake, modulo bugs.
-Ekr

--001a114fc7d821f5a1054e3e4337-- From ivanov@eldos.com Fri Apr 28 11:40:58 2017 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 3B30C1293FB for ; Fri, 28 Apr 2017 11:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.374 X-Spam-Level: *** X-Spam-Status: No, score=3.374 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIMEOLE_DIRECT_TO_MX=0.381, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=no 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 OtQm8qademav for ; Fri, 28 Apr 2017 11:40:56 -0700 (PDT) Received: from widernetics.com (mail.eldos.com [198.50.222.230]) by ietfa.amsl.com (Postfix) with ESMTP id 585BF1293EE for ; Fri, 28 Apr 2017 11:40:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=86.137.1.107; Message-ID: <24DAECF17FE0434CA3111200D77E1911@WhiteBox> From: "Ken Ivanov" To: Date: Fri, 28 Apr 2017 19:41:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Authenticated-User: ivanov@widernetics.com Archived-At: Subject: [TLS] Key update routine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 18:51:07 -0000 Hi Eric and everyone, Glad to meet you all here in this group. I've been working my way through the latest TLS 1.3 draft (the 20th), and I hope you wouldn't mind me putting in my 2p about the key update routine. While section 4.6.3 (Key and IV update) provides good insight as to what the implementations should do if everything goes right, it is unclear on what they should do if something goes wrong. Specifically, while the spec instructs the party that receives a KeyUpdate with its request_update set to update_requested to respond with its own KeyUpdate with request_update set to update_not_requested, there are no provisions as to what the originator of the key update should do if it never receives the requested KeyUpdate response from the remote party (or does not receive it within a reasonable time scope). As, following the spec, the originator will be prepared to, I'm going to quote it here, 'receive an arbitrary number of messages between sending a KeyUpdate with request_update set to update_requested and receiving the peer’s KeyUpdate, because those messages may already be in flight,' I am afraid this might lead to various implementation mistakes where the implementations will simply wait for the KeyUpdate response to come in infinitely, thus creating a security flaw (the inbound key may never get actually updated). I guess we need clearer rules here, for the sabotage of the remote party to participate in the key update routine wasn't tolerated. We probably also need a well-defined cap on how many key update requests are allowed to be sent within a given time frame, as excessive key update requests from clients may consume valuable server resources. Such cap will also be helpful against buggy implementations which will always be responding to the other's KeyUpdate messages with their own request_update set to update_requested, effectively creating an endless loop of key updates. Hope this makes sense. Thanks in advance. Kind regards, Ken Ivanov EldoS Corporation From nobody Fri Apr 28 12:06:31 2017 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 31D5E129426 for ; Fri, 28 Apr 2017 12:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 sVd4cedSZm7n for ; Fri, 28 Apr 2017 12:06:18 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 301251293FF for ; Fri, 28 Apr 2017 12:03:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 23E6335C9B; Fri, 28 Apr 2017 22:03:26 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id JI-WMRK6UIP8; Fri, 28 Apr 2017 22:03:25 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DC0A621C; Fri, 28 Apr 2017 22:03:25 +0300 (EEST) Date: Fri, 28 Apr 2017 22:03:22 +0300 From: Ilari Liusvaara To: Ken Ivanov Cc: tls@ietf.org Message-ID: <20170428190322.GA3901@LK-Perkele-V2.elisa-laajakaista.fi> References: <24DAECF17FE0434CA3111200D77E1911@WhiteBox> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <24DAECF17FE0434CA3111200D77E1911@WhiteBox> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Key update routine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 19:06:30 -0000 On Fri, Apr 28, 2017 at 07:41:59PM +0100, Ken Ivanov wrote: > Hi Eric and everyone, > > Specifically, while the spec instructs the party that receives a KeyUpdate > with its request_update set to update_requested to respond with its own > KeyUpdate with request_update set to update_not_requested, there are no > provisions as to what the originator of the key update should do if it never > receives the requested KeyUpdate response from the remote party (or does not > receive it within a reasonable time scope). The problem is that any time bound would cause keyupdate to couple the directions, which is harmful from API standpoint. The KeyUpdate mechanism is explicitly designed for fully asynchronous operation. Which impiles there is no time bound. -Ilari From nobody Fri Apr 28 12:17:52 2017 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 2AC0E128BBB for ; Fri, 28 Apr 2017 12:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qmySEbcAbmK6 for ; Fri, 28 Apr 2017 12:17:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E561286B2 for ; Fri, 28 Apr 2017 12:17:49 -0700 (PDT) Received: from [10.90.231.238] (unknown [38.86.168.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id AE22A7A330A for ; Fri, 28 Apr 2017 19:17:48 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 28 Apr 2017 15:10:21 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <171B82DC-E3EF-4A49-B967-DA45F3FA81C8@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Session ticket (re-)use in multi-process applications? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 19:17:51 -0000 > On Apr 28, 2017, at 2:29 PM, Eric Rescorla wrote: >=20 >> What does this mean in practice? What happens if Postfix continues = to use the >> same ticket multiple times anyway? Will servers somehow invalidate = the ticket >> after first use? Are the consequences of reuse more severe than with = TLS 1.2? >=20 > Shouldn't be. Mostly, it allows attackers to correlate multiple = sessions from the same > client, which sounds like it's not an issue in your case. Well, the server 220 banner, client EHLO command and server 250 EHLO = response that precede STARTTLS pretty much take care of correlating sessions from the = same client. Also SMTP is not usually tunneled through proxies, and there is no issue = similar to identifying which HTTP pages a client is loading by correlating multiple = requests. Each message delivery is independent. Just the client and server IP addresses leak essentially all the data of = interest. The only thing not leaked by these is leaked via SNI and DNS MX lookups. So I take it that reuse would (in this case) be reasonably harmless. So I can use the "latest" tickets as often as it remains the "latest" ticket. And servers will likely cooperate? The only change might then be that I might see a much higher rate of = session updates as each handshake obtains another new ticket? Unless of course = whether to issue a new ticket, or let the current ticket stand is left to the = application. This raises an interoperability question: * Should SMTP servers always issue a new ticket when a client = resumes a session with an existing ticket? On the one hand, a lot of churn can be saved if the server can replace = only tickets that are close to expiring. On the other hand, if most clients follow the draft recommendation and = discard tickets on first use, then not issuing a replacement ticket each time = will mean that each session will be resumed just once, and 50% of connections will = incur the cost of a full handshake. Is the question of whether/when to issue new tickets expected to be part = of an "application profile"? Do we need a TLS 1.3 application profile for = SMTP? Or just issue a fresh ticket on every resumption? --=20 Viktor. From nobody Fri Apr 28 13:25:27 2017 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 0E565129C1C for ; Fri, 28 Apr 2017 13:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.317 X-Spam-Level: X-Spam-Status: No, score=0.317 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIMEOLE_DIRECT_TO_MX=0.381, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 GVq4J-tCLdol for ; Fri, 28 Apr 2017 13:25:23 -0700 (PDT) Received: from widernetics.com (mail.eldos.com [198.50.222.230]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDBA129B00 for ; Fri, 28 Apr 2017 13:23:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=86.137.1.107; Message-ID: <2E7FA29DD1ED40E7B3AD7D8B47DD2877@WhiteBox> From: "Ken Ivanov" To: "Ilari Liusvaara" Cc: References: <24DAECF17FE0434CA3111200D77E1911@WhiteBox> <20170428190322.GA3901@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170428190322.GA3901@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 28 Apr 2017 21:24:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Authenticated-User: ivanov@widernetics.com Archived-At: Subject: Re: [TLS] Key update routine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 20:25:25 -0000 Hi Ilari I see your point, thank you. Maybe we shall think about replacing the MUST (in 'then the receiver MUST send a KeyUpdate of its own') with SHOULD then, not to lead the originator into confusion about the mutual nature of the key update, and treat the 'request_update' parameter as a suggestion rather than a request? Besides taking the question of enforcing that MUST off the scene, this would level the things up and make each direction truly independent. Ken -----Original Message----- From: Ilari Liusvaara Sent: Friday, April 28, 2017 8:03 PM To: Ken Ivanov Cc: tls@ietf.org Subject: Re: [TLS] Key update routine On Fri, Apr 28, 2017 at 07:41:59PM +0100, Ken Ivanov wrote: > Hi Eric and everyone, > > Specifically, while the spec instructs the party that receives a KeyUpdate > with its request_update set to update_requested to respond with its own > KeyUpdate with request_update set to update_not_requested, there are no > provisions as to what the originator of the key update should do if it > never > receives the requested KeyUpdate response from the remote party (or does > not > receive it within a reasonable time scope). The problem is that any time bound would cause keyupdate to couple the directions, which is harmful from API standpoint. The KeyUpdate mechanism is explicitly designed for fully asynchronous operation. Which impiles there is no time bound. -Ilari From nobody Fri Apr 28 14:02:56 2017 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 3FC34129B01 for ; Fri, 28 Apr 2017 14:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 8KIahsB0tA_V for ; Fri, 28 Apr 2017 14:02:53 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 323DA129B76 for ; Fri, 28 Apr 2017 14:00:37 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id r185so3045246itd.1 for ; Fri, 28 Apr 2017 14:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=bxdPEuiKkd58jZxEKaZfSE7ukJkkvJvyK3VZ8zO/9ig=; b=bITLu6Sx+lVTsgQuCpgOsbj770jMNeitRG3kDkBFGhYNrGWZxDbkTaM5Glfuia6A94 5nOQ/+v7Fj1llTa3BOILExhYNYEEa5rnoWhKHOl/3F2ciWjpqCu0pRXV/fF9ra08fyFy ZhBVsJASs3GfuzXbLJZm0IDMWViFp5rGDOYzM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=bxdPEuiKkd58jZxEKaZfSE7ukJkkvJvyK3VZ8zO/9ig=; b=AWb0L7CGffohMWznRj4Jwo7xKGnMMPK0mUSAdUdEVMDaY2DVVJZaDnInUPu2c/2nuz 4MqBwAF8p8XKK32CAsGkj6RKF7Ps0kD4JjF9IYOe+OAEFeUdZFdyXTNZepqlM81ai2NI oEw1hq57T4wpktj8JEc52A9fJ3drI9J0oYRE54tJZJrsJhqO4ybE9BOleBmJ8OYoEnuV 53svPObX3q6huiHAYTxFBT3skkRVTfwVoUVIB4zraVkKAWyn7B0sJtPj58AWtll3uU94 in4cXgGH+aRQvQRm/JSVsNh7QIClotiBFyUAdg0gf8H6oQYWzJp3XuVcd+hf61x15KiR b6ig== X-Gm-Message-State: AN3rC/4hzxusWBlgSZa2pS9FYCWi5wjxmmQkj1wsgtm83388DVoZgEoR vp/UgEBlEXrkOXoINE0= X-Received: by 10.36.190.205 with SMTP id i196mr11984251itf.88.1493413236262; Fri, 28 Apr 2017 14:00:36 -0700 (PDT) Received: from [5.5.33.51] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id a10sm1514670itj.1.2017.04.28.14.00.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 14:00:35 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_19CFF863-883B-4755-B7BE-F0867E201A4A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <886724B5-7D4A-493A-9D8E-75A0A39B7A9E@sn3rd.com> References: <149341259318.2983.2602850409414765461.idtracker@ietfa.amsl.com> To: "" Date: Fri, 28 Apr 2017 17:00:33 -0400 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] Fwd: Publication has been requested for draft-ietf-tls-tls13-20 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 21:02:55 -0000 --Apple-Mail=_19CFF863-883B-4755-B7BE-F0867E201A4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Note that I=E2=80=99ve requested Kathleen begin her AD review. For those not in the know about IETF process, there=E2=80=99s still a = two-week IETF LC after Kathleen=E2=80=99s review so if anything earth = shattering gets uncovered we can still address it before it gets to the = IESG. spt > Begin forwarded message: >=20 > From: Sean Turner > Subject: Publication has been requested for draft-ietf-tls-tls13-20 > Date: April 28, 2017 at 16:49:53 EDT > To: > Cc: Sean Turner , iesg-secretary@ietf.org, = tls-chairs@ietf.org, sean@sn3rd.com >=20 > Sean Turner has requested publication of draft-ietf-tls-tls13-20 as = Proposed Standard on behalf of the TLS working group. >=20 > Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ >=20 --Apple-Mail=_19CFF863-883B-4755-B7BE-F0867E201A4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Note that I=E2=80=99ve requested Kathleen begin her AD = review.

For those = not in the know about IETF process, there=E2=80=99s still a two-week = IETF LC after Kathleen=E2=80=99s review so if anything earth shattering = gets uncovered we can still address it before it gets to the IESG.

spt

Begin forwarded message:

From: = Sean Turner <sean@sn3rd.com>
Subject: = Publication has = been requested for draft-ietf-tls-tls13-20
Date: = April 28, 2017 at 16:49:53 = EDT
To: = <Kathleen.Moriarty.ietf@gmail.com>
Cc: = Sean Turner <sean@sn3rd.com>, iesg-secretary@ietf.org, tls-chairs@ietf.org, = sean@sn3rd.com

Sean Turner has requested publication of = draft-ietf-tls-tls13-20 as Proposed Standard on behalf of the TLS = working group.

Please verify the document's = state at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/


= --Apple-Mail=_19CFF863-883B-4755-B7BE-F0867E201A4A-- From nobody Fri Apr 28 14:23:59 2017 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 8DFAB129444 for ; Fri, 28 Apr 2017 14:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 SQugiHLsi8Qg for ; Fri, 28 Apr 2017 14:23:56 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 E37B9129478 for ; Fri, 28 Apr 2017 14:22:02 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 70so50050768ita.0 for ; Fri, 28 Apr 2017 14:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=eUCApvWIME2Vl3tiNB9FaKMA+2dWrblGPmMN2KfG1vk=; b=LSsyjw/0tGB5gSKyC/aRi4W0ieqpdRug8Wwn7g3ed8Gr71aC7QG0SPthnE6FVeSBuM 7BTlinRwsiYsaesNyTk4BP7T6q3J3dCwr2YOV1i2oXL1nOv7SiIr3uLtdyDM/okUcb+M A5j69c+/p1gsKLlw89ppxmUN7NfsSjBoOrJFs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=eUCApvWIME2Vl3tiNB9FaKMA+2dWrblGPmMN2KfG1vk=; b=pIl5Zbm6xMQ/T7cC2nrCPgtOsbS4LKYgVd1i6XHrxE3CpXrYuDaTbyhEp8y3be+482 VX3KlODsJpIPesN+/sq5OyQ6NivTzI4KonYTW2NfSx5quNRuwuHQbVhWdkKYLz7bbjlq Oea6ZgNvu8ZFwJParvHdS6nZuIiTlmotdVXY8XhODJPlBThj6Dh+u/e9ky77fYD5y6CD xWxhBK4zoeO1VzbC4NqtppMm7aH+3rgtc6DUckkg1vnJevpuq0wXuO8Ub00Pqf5NN+Hn 7LzEY+b8K2FvYMI2zqAyGTKs/npXiVIimFlbDzYtHzP1vgmdQojuqEPPFSdFu/xI/8LE haWQ== X-Gm-Message-State: AN3rC/4dxcXAR/HQDzqry9lHuT5Gwy6QvR14bfH3ZI+dPCiLPrJ/EoRi IS5YwFOfQCLwkG615NY= X-Received: by 10.36.46.193 with SMTP id i184mr3909958ita.51.1493414521953; Fri, 28 Apr 2017 14:22:01 -0700 (PDT) Received: from [5.5.33.51] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id a68sm324056itd.30.2017.04.28.14.22.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 14:22:00 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 28 Apr 2017 17:21:56 -0400 References: To: "" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 21:23:57 -0000 Thanks to MT and Ben for their reviews. Joe and I have asked Kathleen = to progress this draft towards the =E2=80=9Capproved=E2=80=9D state. spt > On Apr 11, 2017, at 09:09, Sean Turner wrote: >=20 > All, >=20 > draft-ietf-tls-rfc4492bis has been revised since it left the WG and we = agree with Yoav=E2=80=99s statement at the mic in Chicago that the WG = should review the changes before we ask Kathleen (our newly appointed = AD) to continue progressing the draft. Please review the differences = from the -12 version that went through WGLC and the latest version [0] = and let us know by 20170426 whether there is anything that would stop = progression of the draft. >=20 > Thanks, >=20 > J&S >=20 > [0] = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-rfc4492bis-12&url2=3Ddr= aft-ietf-tls-rfc4492bis-16 From nobody Fri Apr 28 14:59:46 2017 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 AFA29129467 for ; Fri, 28 Apr 2017 14:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 Ugp5aoZKxGO5 for ; Fri, 28 Apr 2017 14:59:42 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 BCF06129AC6 for ; Fri, 28 Apr 2017 14:57:07 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 70so50427919ita.0 for ; Fri, 28 Apr 2017 14:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M/MB4RfKgCvzqeprh+67AXwHaUSUQEoReGdAWwy0rRM=; b=ipzUBWlpxvou2aibbsz1pV86WbKf5GpxFm6A71OQbSZf/DQpfVRtU2lvHarzoKmRQQ oePCa2/qO5w8yTYbfp0UzyjHTUd0crrXIQrVjNeO4+b2yjKY9duDM6A2XDh5aMeFuV/v hRaH1E5e2zxoc703JK2+RavspzeS3xxRRISYA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M/MB4RfKgCvzqeprh+67AXwHaUSUQEoReGdAWwy0rRM=; b=sXsoAUjmnZGmwRupuIMOmN+RY7LfTlEiLRoI3re7bdcz8jdZTKpzq5L7lNbXG4kFA2 2Rvda3wcOHmpaw8+2DB0cT+zist3uPqY4wgSCjvqvGCJndHSo17jC0eUy9klWFYx0qfd AVNFt/GTRsonUTIoLiy+lL5cKxiCTRNsmk/BAbzC1+7Zzp8svAAak20ra7Vg0D2eMQck Cq5zMhzvtvrvl9KOnGkGvjeolWPpi3J6g1Od5JAD059XM9gM9D0stLfZXwEk7HZnnqfl CgX1WQikLILwzFai0+sjZhv05S4Z1MEJL8l6AfxYulLZE6IQmRaN+TkeGJdLfpACf5ku 5+dg== X-Gm-Message-State: AN3rC/4Jve0xfTC94WIADY0fwSjSL6Hgcc0QjQYKI/VacPMonzOOkxgo MJM12Xo9kNfAQB+57Dc= X-Received: by 10.36.147.65 with SMTP id y62mr12232703itd.68.1493416627093; Fri, 28 Apr 2017 14:57:07 -0700 (PDT) Received: from [5.5.33.51] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id v66sm354020ith.18.2017.04.28.14.57.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 14:57:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Fri, 28 Apr 2017 17:57:02 -0400 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: <1F169304-68E1-4BCD-83DF-C40613A3DF45@sn3rd.com> References: <4CBA4B06-411F-4B87-B664-D451260F8C25@sn3rd.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] WG Call for adoption of draft-rescorla-tls-dtls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 21:59:45 -0000 Thanks! spt > On Apr 28, 2017, at 12:50, Eric Rescorla wrote: >=20 > Draft submitted (it should be identical to the individual submission) >=20 > -Ekr >=20 >=20 > On Fri, Apr 7, 2017 at 2:14 PM, Sean Turner wrote: > It=E2=80=99s now the 7th so the call for adoption is complete. Though = Ben was the only commenter on list (and thanks Ben) there was definitely = support for adopting this draft at the Chicago session. This bit of = administrivia is complete so authors feel free to submit a WG version at = your leisure. I=E2=80=99ve pre-approved "draft-ietf-tls-dtls13" as the = draft's name and created a github repo: = https://github.com/tlswg/dtls13-spec. >=20 > spt >=20 > > On Mar 22, 2017, at 18:50, Sean Turner wrote: > > > > All, > > > > -00 of draft-rescorla-tls-dtls13 [0][1] was discussed at IETF 97 = [2]. It=E2=80=99s now at version -01 and GH issues are slowly rolling = in. It=E2=80=99s also on our agenda again at IETF 98, and DTLS a = chartered work item, so it seems like it=E2=80=99s time to get the WG = adoption process started for this individual draft. Please let the list = know whether you support adoption of the draft and are willing to = review/comment on the draft before 20170406. If you object to its = adoption, please let us know why. > > > > Cheers, > > > > J&S > > > > [0] https://github.com/ekr/dtls13-spec > > [1] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-dtls13 > > [2] = https://www.ietf.org/proceedings/97/slides/slides-97-tls-dtls-13-01.pdf >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Fri Apr 28 15:01:39 2017 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 6935F129571 for ; Fri, 28 Apr 2017 15:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 gbtwBibXkYpG for ; Fri, 28 Apr 2017 15:01:34 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 53BDF129BA5 for ; Fri, 28 Apr 2017 14:58:57 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id p80so79149832iop.3 for ; Fri, 28 Apr 2017 14:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=YlwCX1d2hRoI8lkrNkmfy+gyI1fRqBZRnhKepv7Mcfs=; b=OkSBwCPvF9xF/o2Or+WTbvmg77/ICmSSYd37lwflhMq9hXehAsxIDznOlIYvsygCqY roZjZhq/lma50LHYROYt67bTpLtpXkcAQBQBIC8EtFLMFWHUo+qHfrOCsUKmOIQS1xpa em7Q12JThhkvQvpkJD2u3fYMVyvrC02Nzcj5Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=YlwCX1d2hRoI8lkrNkmfy+gyI1fRqBZRnhKepv7Mcfs=; b=PB6Bm5M6JqdSuZR/dVr4utGcs+GBRlvpVD1MXSJ6Zg+cdugDoSmFUJjGbyGCbRHvcl v4sSI3/K0wkTpB5304RIm4xIGW5oUnjBG0GtHi5fqRmhzRL4PNIuDWEnnFwIpFKuo5he RWvw+x2LexqoVxA4Ma9OFGPxN1dVl6llG6pltDgH78lhAXn3xyjjoqlBtKYb5PrRoZSC IzjcLGAIoY4/i9g8yRekhWwiAmsUEP4OcsYa5y+qcoxCnqyWNaDi+Oebm3Y+khCCoE7U voCLNpto/NGS/aHd+ERdRDi+rTnYtC4IYaUQrFNxqMKoa91kQhi2ZN64ZFGWa5z5SszP FZpA== X-Gm-Message-State: AN3rC/5nFtoUtJH99oNdxM7AgI+RukAIMJvleICS9n93Xgq3bNjpG6Q+ tO3vyGIim/RYXufbyxY= X-Received: by 10.107.183.72 with SMTP id h69mr13339053iof.119.1493416736461; Fri, 28 Apr 2017 14:58:56 -0700 (PDT) Received: from [5.5.33.51] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id s201sm283696ita.26.2017.04.28.14.58.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 14:58:55 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 28 Apr 2017 17:58:52 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] GH repo for draft-rescorla-tls-dtls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 22:01:37 -0000 We=E2=80=99ve created a GH rep for the DTLS1.3 draft @ = https://github.com/tlswg/dtls13-spec spt= From nobody Fri Apr 28 15:44:59 2017 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 9AAAA12941A for ; Fri, 28 Apr 2017 15:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.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 OPax64oWBoFe for ; Fri, 28 Apr 2017 15:44:54 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 4489F1293FD for ; Fri, 28 Apr 2017 15:42:04 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id e64so17040504pfd.1 for ; Fri, 28 Apr 2017 15:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xy6mZIqOBY8NBl2tUJVqCwmTMsoRvfjEAszg8vYMrnE=; b=IyBXzL6eH5VZQOHQ0sz0jO+nSvImTt5WbntlUugElE3vX5+20QOiX811CLcYj40Y5g z4mUZZJNR8l2hDc2mbP7TH4syLAKFMDHTr3jZ0NYbqIB39qtxX5eTqs2UJ9ubFg27EG9 2PrjkXZ0eHyAe00wd47ZOMhUZ3JWpY2THsKQJtoYH6VzGvefJarE2ynx+izi233Rmj/b gK9bcW3866G2Jj9afdbBOtg0f8pPeS7zrd0iPidWxhx7dcIw9xiAzrYWs2d/9y6jQEDo n6ItYYKPtT8imTCGNOO8OVHyVzbm2jVJs19U6U6IiL65JulWRZ62XuVuwXstHq8ag3+z yn2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xy6mZIqOBY8NBl2tUJVqCwmTMsoRvfjEAszg8vYMrnE=; b=lErKYrfFXf0670GSKDsf5uldDOexexBB8tikgGo5z1JrbRuC+hOeq4Iv/d2Uf/NKzx YFRXm8fSGoaiUShp8XDXG5cKnmXj9ytpMUb4G7jurLXGEK6sqQT+g/VQgHix1GQ/M6tL VeG9uTC7MiafGzP2MHBEWoGTBJ7VQOnpgqzb0vbW8wrOv/1xkvBWj7NtghGtkYbk8iKx TXjIWpHwgsrLfAH7X8TdaIGRCo04xk71uK7K5PU77UZ7AJ82xTbg4HGydAit2WtMnxv5 81tp4cUdvCub7H9ytVZwuzrFuEQuAKkLj7x3hkwGgyT0VukDaSC0jx7Ch9vLGx3xcBdm 6sUQ== X-Gm-Message-State: AN3rC/4HC0C4iVCuCH6Jz1cg3KB/TgVCvfpmyeX0nMCLCfpt5TAYq7DO JQ5J7r7yks9OEyQgKd+vtpmYeA3wFA== X-Received: by 10.98.194.69 with SMTP id l66mr14742810pfg.55.1493419323687; Fri, 28 Apr 2017 15:42:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.140.201 with HTTP; Fri, 28 Apr 2017 15:41:43 -0700 (PDT) In-Reply-To: References: From: Joseph Salowey Date: Fri, 28 Apr 2017 15:41:43 -0700 Message-ID: To: "tls@ietf.org" Cc: draft-ietf-tls-ecdhe-psk-aead@tools.ietf.org Content-Type: multipart/alternative; boundary=94eb2c0a43504a1afa054e41c8ff Archived-At: Subject: Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 22:44:58 -0000 --94eb2c0a43504a1afa054e41c8ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The chairs are forwarding this document to our AD to progress towards publication. Cheers, Joe On Tue, Apr 11, 2017 at 8:21 AM, Joseph Salowey wrote: > Hi Daniel, > > Please submit a revised draft with the changes below. > > Thanks, > > Joe > > > On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi, >> >> Thank you for the review and comments received. Given the discussion our >> understanding was that the consensus was to remove CCM-256 so that suite= s >> defined by the document apply both for TLS1.2 as well as for TLS1.3. The >> draft available on github [1 >> ] >> has been updated as follows: >> >> >> 1. Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead >> of SHA384 like the other 256 bit cipher suites? (From Russ Housley) >> >> MGLT: This was a mistake in the IANA section. The cypher suite was >> correct in the remaining text. However, the current version does not >> consider anymore CCM-256* which also solves this issue. >> >> 2. Since the security considerations mention passwords (human chosen >> secrets) it should mention dictionary attacks. (From Russ Housley) >> >> MGLT: The issue of human chosen passwords and dictionary attacks has bee= n >> mentioned in the security consideration with the following text: >> >> """ >> Use of Pre-Shared Keys of limited entropy may allow an active >> attacker attempts to connect to the server and tries different keys. >> For example, limited entropy may be provided by using short PSK in >> which case an attacker may perform a brute-force attack. Other >> example includes the use of a PSK chosen by a human and thus may be >> exposed to dictionary attacks. >> """ >> >> >> 3. Section 2 and 3 of the document contains more detail about TLS 1.3 >> than necessary. >> >> Section 2: This document only defines cipher suites for TLS 1.2, not TLS >> 1.2 or later. A subset of equivalent cipher suites is defined in the TL= S >> 1.3 specification. >> >> MGLT: CCM-256 has been removed from the specification so that suites can >> be defined for TLS 1.2 as well as TLS1.3. The following text is consider= ed. >> >> """ >> This document defines new cipher suites that provide Pre-Shared Key >> (PSK) authentication, Perfect Forward Secrecy (PFS), and >> Authenticated Encryption with Associated Data (AEAD). The cipher >> suites are defined for version 1.2 of the Transport Layer Security >> (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer >> Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS >> [I-D.ietf-tls-tls13]. >> """ >> >> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to >> section 4 that states: >> >> "TLS 1.3 and above name, negotiate and support a subset of these cipher >> suites in a different way." (TLS 1.3 does not support >> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256_CCM >> _8_SHA256) >> >> MGLT: As CCM-256 has been removed, we do not have to deal with the >> situation where TLS1.3 only considers a subset of the suites defined for >> TLS1.2. >> >> The following sentence in section 3 clarifies that codes points are only >> defined for TLS1.2: =E2=80=9C=E2=80=9D=E2=80=9DThe assigned code points = can only be used for TLS >> 1.2.=E2=80=9D=E2=80=9D=E2=80=9D. The description of the TLS1.3 negotiati= on has been limited in >> section 4 to the following sentence: =E2=80=9C=E2=80=9D=E2=80=9DTLS 1.3 = and above version, >> negotiate and support these cipher suites in a different way.=E2=80=9D= =E2=80=9D=E2=80=9D >> >> 4. Section 3 should contain a bit more detail about relationship to 4492 >> bis and RFC 4279: >> >> Something like the following may be enough. >> >> "This messages and pre-master secret construction in this document are >> based on [RFC4279]. The elliptic curve parameters used in in the >> Diffie-Hellman parameters are negotiated using extensions defined in >> [4492-bis]." >> >> MGLT: The sentence mentioned above has been added with [4492-bis] >> mentioned as normative. >> =E2=80=9C=E2=80=9D=E2=80=9D >> Messages and pre-master secret construction in this document are >> based on [RFC4279]. The elliptic curve parameters used in in the >> Diffie-Hellman parameters are negotiated using extensions defined in >> [I-D.ietf-tls-rfc4492bis]. >> =E2=80=9C=E2=80=9D=E2=80=9D >> >> [1] https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/m >> aster/draft-ietf-tls-ecdhe-psk-aead >> >> Yours, >> Daniel and John >> >> >> On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey wrote: >> >>> Here are the open issues for draft-ietf-tls-ecdhe-psk-aead >>> >>> 1. Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead >>> of SHA384 like the other 256 bit cipher suites? (From Russ Housley) >>> >>> 2. Since the security considerations mention passwords (human chosen >>> secrets) it should mention dictionary attacks. (From Russ Housley) >>> >>> 3. Section 2 and 3 of the document contains more detail about TLS 1.3 >>> than necessary. >>> >>> Section 2: This document only defines cipher suites for TLS 1.2, not TL= S >>> 1.2 or later. A subset of equivalent cipher suites is defined in the T= LS >>> 1.3 specification. >>> >>> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition t= o >>> section 4 that states: >>> >>> "TLS 1.3 and above name, negotiate and support a subset of these cipher >>> suites in a different way." (TLS 1.3 does not support >>> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256 >>> _CCM_8_SHA256) >>> >>> 4. Section 3 should contain a bit more detail about relationship to 449= 2 >>> bis and RFC 4279: >>> >>> Something like the following may be enough. >>> >>> "This messages and pre-master secret construction in this document are >>> based on [RFC4279]. The elliptic curve parameters used in in the >>> Diffie-Hellman parameters are negotiated using extensions defined in >>> [4492-bis]." >>> >>> Thanks, >>> >>> Joe >>> >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> > --94eb2c0a43504a1afa054e41c8ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The chairs are forwarding this document to our AD to progr= ess towards publication. =C2=A0

Cheers,

Joe

O= n Tue, Apr 11, 2017 at 8:21 AM, Joseph Salowey <joe@salowey.net> wrote:
Hi Daniel,
Please submit a revised draft with the changes below.
=

Thanks,

Joe


On Tue, Mar 21, 2017 at 11:08 AM, Daniel= Migault <daniel.migault@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hi,

Thank y= ou for the review and comments received. Given the discussion our understan= ding was that the consensus was to remove CCM-256 so that suites defined by= the document apply both for TLS1.2 as well as for TLS1.3. The draft availa= ble on github [1]=C2= =A0 has been updated as follows:=C2=A0


1.=C2=A0 Why does = TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead of SHA384 l= ike the other 256 bit cipher suites? (From Russ Housley)

MGLT= : This was a mistake in the IANA section. The cypher suite was correct in t= he remaining text. However, the current version does not=C2=A0 consider any= more CCM-256* which also solves this issue.
=C2=A0
2.=C2=A0 Sin= ce the security considerations mention passwords (human chosen secrets) it = should mention dictionary attacks. (From Russ Housley)
=C2=A0
= MGLT: The issue of human chosen passwords and dictionary attacks has been m= entioned in the security consideration with the following text:

&quo= t;""
=C2=A0=C2=A0 Use of Pre-Shared Keys of limited entropy m= ay allow an active
=C2=A0=C2=A0 attacker attempts to connect to the serv= er and tries different keys.
=C2=A0=C2=A0 For example, limited entropy m= ay be provided by using short PSK in
=C2=A0=C2=A0 which case an attacker= may perform a brute-force attack.=C2=A0 Other
=C2=A0=C2=A0 example incl= udes the use of a PSK chosen by a human and thus may be
=C2=A0=C2=A0 exp= osed to dictionary attacks.
"""

=C2=A0
3= .=C2=A0 Section 2 and 3 of the document contains more detail about TLS 1.3 = than necessary.=C2=A0
=C2=A0
Section 2: This document only defines c= ipher suites for TLS 1.2, not TLS 1.2 or later.=C2=A0 A subset of equivalen= t cipher suites is defined in the TLS 1.3 specification.=C2=A0
=C2=A0MGLT: CCM-256 has been removed from the specification so that suit= es can be defined for TLS 1.2 as well as TLS1.3. The following text is cons= idered.

"""
=C2=A0=C2=A0 This document defines n= ew cipher suites that provide Pre-Shared Key
=C2=A0=C2=A0 (PSK) authenti= cation, Perfect Forward Secrecy (PFS), and
=C2=A0=C2=A0 Authenticated En= cryption with Associated Data (AEAD).=C2=A0 The cipher
=C2=A0=C2=A0 suit= es are defined for version 1.2 of the Transport Layer Security
=C2=A0=C2= =A0 (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer=C2=A0=C2=A0 Security (DTLS) protocol [RFC6347], as well as version 1.3 o= f TLS
=C2=A0=C2=A0 [I-D.ietf-tls-tls13].
"""
= =C2=A0
Section 3 and 4: Maybe replace the last 2 paragraphs with an addi= tion to section 4 that states:
=C2=A0
"TLS 1.3 and above name, n= egotiate and support a subset of these cipher suites in a different way.&qu= ot;=C2=A0 (TLS 1.3 does not support TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA= 384 and TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256)
=C2=A0
M= GLT: As CCM-256 has been removed, we do not have to deal with the situation= where TLS1.3 only considers a subset of the suites defined for TLS1.2.
The following sentence in section 3 clarifies that codes points are on= ly defined for TLS1.2: =E2=80=9C=E2=80=9D=E2=80=9DThe assigned code points = can only be used for TLS 1.2.=E2=80=9D=E2=80=9D=E2=80=9D. The description o= f the TLS1.3 negotiation has been limited in section 4 to the following sen= tence: =E2=80=9C=E2=80=9D=E2=80=9DTLS 1.3 and above version, negotiate and = support these cipher suites in a different way.=E2=80=9D=E2=80=9D=E2=80=9D<= span>
=C2=A0
4. Section 3 should contain a bit more detail about rela= tionship to 4492 bis and RFC 4279:
=C2=A0
Something like the followin= g may be enough.=C2=A0

"This messages and pre-master secret co= nstruction in this document are based on [RFC4279].=C2=A0 The elliptic curv= e parameters used in in the Diffie-Hellman parameters are negotiated using = extensions defined in [4492-bis]."
=C2=A0
MGLT: The sente= nce mentioned above has been added with [4492-bis] mentioned as normative.<= br>=E2=80=9C=E2=80=9D=E2=80=9D
=C2=A0=C2=A0=C2=A0 Messages and pre-maste= r secret construction in this document are
=C2=A0=C2=A0 based on [= RFC4279].=C2=A0 The elliptic curve parameters used in in the
=C2=A0=C2= =A0 Diffie-Hellman parameters are negotiated using extensions defined in=C2=A0=C2=A0 [I-D.ietf-tls-rfc4492bis].
=E2=80=9C=E2=80=9D=E2=80= =9D

[1] https://= github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/master/draft-i= etf-tls-ecdhe-psk-aead

Yours,
Daniel and Jo= hn


On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey <joe@salowey.= net> wrote:
Here are the open issues for= =C2=A0draft-ietf-tls-ecdhe-psk-aead

1.=C2=A0 Why do= es=C2=A0TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead of SH= A384 like the other 256 bit cipher suites? (From Russ Housley)
=

2.=C2=A0 Since = the security considerations mention passwords (human chosen secrets) it sho= uld mention dictionary attacks. (From Russ Housley)

3.=C2=A0 Section 2 and 3 of the document contains more detail about TLS 1= .3 than necessary. =C2=A0

Section 2: This document= only defines cipher suites for TLS 1.2, not TLS 1.2 or later.=C2=A0 A subs= et of equivalent cipher suites is defined in the TLS 1.3 specification. =C2= =A0

Section 3 and 4: Maybe replace the last 2 para= graphs with an addition to section 4 that states:

= "TLS 1.3 and above name, negotiate and support a subset of these ciphe= r suites in a different way." =C2=A0(TLS 1.3 does not support=C2=A0TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and=C2=A0TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256)
<= div>
4. Section 3 should contain a bit more detail about rela= tionship to 4492 bis and RFC 4279:

Something like = the following may be enough. =C2=A0

"This messages and pre-master secret construction in this= document are based on [RFC4279].=C2=A0 The elliptic curve parameters used = in in the Diffie-Hellman parameters are negotiated using extensions defined= in [4492-bis]."

Thanks,

Joe




_______________________________________________<= br> TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls




--94eb2c0a43504a1afa054e41c8ff--