[IPP] Fwd: [TLS] Minutes from IETF 104
Ira McDonald via ipp <ipp@pwg.org> Mon, 01 April 2019 21:00 UTC
Return-Path: <ipp-bounces@pwg.org>
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2BE1200FB for <ietfarch-ipp-archive@ietfa.amsl.com>; Mon, 1 Apr 2019 14:00:17 -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_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 J8iCR4_fyPaZ for <ietfarch-ipp-archive@ietfa.amsl.com>; Mon, 1 Apr 2019 14:00:14 -0700 (PDT)
Received: from www.pwg.org (mail.pwg.org [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 83A71120033 for <ipp-archive2@ietf.org>; Mon, 1 Apr 2019 14:00:14 -0700 (PDT)
Received: by www.pwg.org (Postfix, from userid 1002) id 362863F50; Mon, 1 Apr 2019 21:00:14 +0000 (UTC)
Received: from www.pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 5332A3F35; Mon, 1 Apr 2019 21:00:05 +0000 (UTC)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: by www.pwg.org (Postfix, from userid 1002) id D8C743F37; Mon, 1 Apr 2019 21:00:03 +0000 (UTC)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by www.pwg.org (Postfix) with ESMTPS id EEFA31C9D for <ipp@pwg.org>; Mon, 1 Apr 2019 21:00:01 +0000 (UTC)
Received: by mail-yb1-xb31.google.com with SMTP id r2so4082348ybl.5 for <ipp@pwg.org>; Mon, 01 Apr 2019 14:00:01 -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=sT221j5AlN+Mqd2GQ9xeJwfpu456Z+z6kfOBy0uTbsw=; b=kXtnpT3TLBx4NSXodcbDbgvg0dnzJhbdsbEmDzurMlIel6KcGYtntiZBpCdiL1R4g6 oPzZuYGHQ+f9HuUfaV8+D2JORdyIJuAKGAEqZOiDgdUMqQP86EJ080S2qN02DTQgDQvQ SuF4aasB1sGvQkORAp0e+jWirnS3u5qG29E7iBGXsmsZETCPMEgRVfnyg0aLE3WBTYnn N5X7iafnAH9KLk14ER7/oci7iUdopxgFNLS8yphzgFSB5utnWp7aClLv9+ZghFBRQ30Q gt6gSxA7SEBzXiIc1kAuqhJSjNxEwKRnxxSVuARt3qBpq2SPIoQyhHJec+OypPR3P9ty ZR8w==
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=sT221j5AlN+Mqd2GQ9xeJwfpu456Z+z6kfOBy0uTbsw=; b=rMzG7br87jjCYJBR4xSidHv6QVZVNR43A0x7apLGGIKuU1McYecyyOF2kOnWKJnEFl TnECtikv32qvAFv3T21ImX0ZVgOeH22WBv3MIHZux17GssWaTSEclrhd+/cFJV888vLN qbHn8ekjwGMj9QZU0bZnYit2A92gxU0zEYWOMBtGGAzGKXu6KDEmjj7XUWHa4xbQ0437 q4RlP0Jbi0oIcClZWgf3kRf5snZfq1LBa1UynGUlUlQXhNNRH0OVx58cU0ZNLbEhuIX/ +r40+TlbuTQsBX2WWAkP8XXLirammx4CARcC0BsyfRVd8oeRNsmRTVnhyBDpiwz0WzQO 6uow==
X-Gm-Message-State: APjAAAV3MvubHsSbHLgfzJU7aEdqlhOIgBF1Fgqmjp2DtqCaOKSYbNCS rNrbMewFbY/ugMnuoyXeXwFN5m7Ko0nEOcUuxko=
X-Google-Smtp-Source: APXvYqz933c4mSqf1J4nA8NQ6eAGROxDJphQ3JNcyoer4nxwZ2XTPO8jyP3zNcV1M2Jl7xFA7gMV2Ps1EAhgi2eLUUs=
X-Received: by 2002:a25:6088:: with SMTP id u130mr53481223ybb.235.1554152401100; Mon, 01 Apr 2019 14:00:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAO8oSXk8RX6-jCP19WTijXY_w6cYFRbO2GTdYu=i1MX0ep44Tg@mail.gmail.com>
In-Reply-To: <CAO8oSXk8RX6-jCP19WTijXY_w6cYFRbO2GTdYu=i1MX0ep44Tg@mail.gmail.com>
Date: Mon, 01 Apr 2019 16:59:48 -0400
Message-ID: <CAN40gSu6FPP6QB08RXFDTyq3AmoPZ=WUaQgvx2RfumpRWkk1=w@mail.gmail.com>
To: tms_wg@trustedcomputinggroup.org, MPWG <mobilewg@trustedcomputinggroup.org>, neteq@trustedcomputinggroup.org, tnc@trustedcomputinggroup.org, "iot-sg@trustedcomputinggroup.org" <iot-sg@trustedcomputinggroup.org>, "ipp@pwg.org" <ipp@pwg.org>, Ira McDonald <blueroofmusic@gmail.com>
Subject: [IPP] Fwd: [TLS] Minutes from IETF 104
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ISTO-PWG Internet Printing Protocol workgroup discussion forum <ipp.pwg.org>
List-Unsubscribe: <https://www.pwg.org/mailman/options/ipp>, <mailto:ipp-request@pwg.org?subject=unsubscribe>
List-Archive: <http://www.pwg.org/pipermail/ipp/>
List-Post: <mailto:ipp@pwg.org>
List-Help: <mailto:ipp-request@pwg.org?subject=help>
List-Subscribe: <https://www.pwg.org/mailman/listinfo/ipp>, <mailto:ipp-request@pwg.org?subject=subscribe>
From: Ira McDonald via ipp <ipp@pwg.org>
Reply-To: Ira McDonald <blueroofmusic@gmail.com>
Content-Type: multipart/mixed; boundary="===============3613627595031972019=="
Errors-To: ipp-bounces@pwg.org
Sender: ipp <ipp-bounces@pwg.org>
---------- Forwarded message --------- From: Christopher Wood <christopherwood07@gmail.com> Date: Mon, Apr 1, 2019 at 9:05 AM Subject: [TLS] Minutes from IETF 104 To: <tls@ietf.org> <tls@ietf.org> Minutes from last week's TLS meetings in Prague are now online [1]. They're also copied at the end of this message. Please have a look and send any issues to the list. Many thanks to Richard Barnes and Robin Wilton for taking notes! Best, Chris, Joe, and Sean [1] https://datatracker.ietf.org/doc/minutes-104-tls/ ----- TLS working Group IETF 104 Monday, 25 March, 2019 Prague, CZ # Working Group Drafts ## TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key - Russ Housley - Draft defines an extension to the TLS handshake, adding an optional parameter allowing the External PSK to be combined with EC(DHE) as secret inputs to the key schedule. - Watson Ladd: does this enable the sending of early data? - RH: No; explicitly stated to be out of scope in the draft. - ANO: formal review would be desirable. - Ekr: don’t think we should pass this until someone has implemented it. - RH: as the first slide notes, this is experimental. - one hand in response to question about implementations. - * Next Steps: additional review (probably WGLC). # Individual Drafts ## TLS Resumption across Server Name Indications for TLS 1.3 - Erik Sy - TLS 1.3 recommends against, but doesn’t give a good indication of what criteria to consider, or a signalling mechanism to say if the server supports Resumption. - Performance benefits, CPU time and elapsed time improvements may be valid criteria - TLS extension would be needed to signal that this option is available, e.g, a simple flag. - Privacy impact could be reduced by enforcing shorter session lengths. - Ekr: where should the extension go? - in the EE. Needs to be made clearer in the doc. - Ekr: should also be clear about whether resumption should require a fresh DNS request - Ekr: is a 1-bit flag really sufficient? - yes, otherwise would need to specify a list of values for which Resumption is OK, and that would make implementation harder. - Ekr: should TLS, in principle, define a general-purpose extension space rather than a bunch of specific flags? - Yoav Nir: 1-bit flag may introduce address space/scope clashes at the server, and different servers might have different requirements. Not a good idea to allow reconnection to “any server”. - Server identification could be aided by reference to the X.509 cert. - Viktor: recommends using a session ticket extension for this, not the handshake itself. - Viktor: shortening the acceptable resumption period, as proposed, is rational, but privacy implications probably need further examination. - 10 muinutes is a figure of merit. - Nick Sullivan: Where an X.509 cert has broad scope (across multiple servers), additional parameters may be needed to ensure Yoav’s concern isn’t an issue. Relying only on the -.509 cert makes unreasonable assumptions. ## Importing External PSKs for TLS - Christopher Wood - TLS 1.3 imposes restriction on PSK usage with hash functions; TLS 1.2 did not impose this restriction - so the resulting incompatibility (and potential for inappropriate use of PSKs) must be handled (ideally) without changing the key schedule. - Christian Huitema: working on a draft that generalizes DNS-SD technique for external PSK identifiers in TLS. - Jon Mattsson: question about using one hash algorithm to generate keys for use with another. - ANO: Does the PSK constitute a channel binding? Depending how the External PSK is generated, this and the Resumption issue may overlap. A subsequent session has no way of knowing how the previous session was established. - Ekr: reusing hashes as proposed is secure. [Discussion inconclusive, needs further examination]. - * No objections to adoption as a work item. Take to list. ## TLS Client Network Address Extension - Tommy Pauly - Purpose: NAT detection in secure transport protocols - Relates to these drafts specifying extensions: - TLS, draft-kinnear-tls-client-net-address - QUIC, draft-pauly-quic-address-extension - Wes H.: is this specific to NATv4? - it applies everywhere. - Wes H: Why is this a TLS-specific problem? - for QUIC, this is a transport handshake question. For TLS, it would be more complicated to put it elsewhere (?). - DKG: what would a client do with this information? - the only real purpose of this is to check that you’re not behind a NAT. - * Discussion moved to the list for timekeeping reasons. ## Using Identity as Raw Public Key in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) - Haiguang Wang - Using Identity Based Signature exempts the server from having to maintain records of the binding between a raw public key and the entity presenting it. - * Next steps: ask to reserve specific code points for this mechanism to use in implementation and testing. Tuesday, 26 March, 2019 # Working Group Drafts ## Deprecating TLS 1.0 and 1.1 - TODO: update to deprecate DTLS 1.0 - Update to require NNTP to do the right thing - * Hearing no objection, headed for WGLC ## DTLS 1.3 - Issue 78 - we will say MUST limit amplification until the path is validated somehow. - - … and we will separately say that though there is a CID, there is not a migration piece - that is, endpoints don't send to new addresses in response to receiving valid records from those addresses. - Issue 72 - No change. - Implementation status - NSS, Mint, mbedTLS. ## Cert Compression - Add decompressed certificate to transcript? No. - * Will write up changes, then WGLC. ## Delegated credentials - * Ready for LC? Yes, most likely. ## ESNI - Current solution with PR#137 as an extension? Unclear from the room. - Will an ESNI RRType Diverge from the A/AAAA results? - [[lots of discussion, no resolutions]] # Individual Drafts ## OPAQUE in TLS 1.3 - We should wait for CFRG to opine. - Cisco has a use case, some possibility of web API? - * No action, due to novelty. ## Hybrid key exchange - Probably too early, given that research on combinations still active. ## CWTs in TLS / DTLS - Would need to restrict to PoP tokens. - * No action, due to novelty ## Fake SNI - Should be compared to earlier draft on attacks against SNI approaches. - * No action, due to novelty. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp
- [IPP] Fwd: [TLS] Minutes from IETF 104 Ira McDonald via ipp