[TLS] I-D Action: draft-ietf-tls-dtls13-27.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG 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-27.txt Pages : 45 Date: 2018-07-02 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-27 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-27 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/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-dtls13-28.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG 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-28.txt Pages : 45 Date: 2018-07-02 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-28 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-28 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/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-dtls-connection-id-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Datagram Transport Layer Security (DTLS) Connection Identifier Authors : Eric Rescorla Hannes Tschofenig Thomas Fossati Tobias Gondrom Filename: draft-ietf-tls-dtls-connection-id-01.txt Pages : 11 Date: 2018-07-02 Abstract: This document specifies the Connection ID construct for the Datagram Transport Layer Security (DTLS) protocol. A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-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/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
On 6/25/18 at 9:20 PM, j...@salowey.net (Joseph Salowey) wrote: Hi Folks, There has been some discussion with a small group of folks on github - https://github.com/tlswg/dnssec-chain-extension/pull/19. I want to make sure there is consensus in the working group to take on the pinning work and see if there is consensus for modifications in the revision. Please respond to the following questions on the list by July 10, 2018. 1. Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another approach)? I would like to see a pinning mechanism, and think this Working Group is the right place to move the idea forward. 2. Do you support the reserved bytes in the revision for a future pinning mechanism? Yes. 3. Do you support the proof of denial of existence text in the revision? I had difficulty reading the GitHub thread. 4. Do you support the new and improved security considerations? ditto Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-subcerts-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Delegated Credentials for TLS Authors : Richard Barnes Subodh Iyengar Nick Sullivan Eric Rescorla Filename: draft-ietf-tls-subcerts-01.txt Pages : 11 Date: 2018-07-02 Abstract: The organizational separation between the operator of a TLS server and the certificate authority that provides it credentials can cause problems, for example when it comes to reducing the lifetime of certificates or supporting new cryptographic algorithms. This document describes a mechanism to allow TLS server operators to create their own credential delegations without breaking compatibility with clients that do not support this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-subcerts-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-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/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] FW: New Version Notification for draft-barnes-tls-pake-02.txt
Hey all, Following up from the threads in April, a new version has been posted that addresses some of those comments, and makes the TLS extensions generic enough to transport any PAKE, with some open questions on PAKE algorithm agility. All feedback on making the extension generic for transporting any PAKE params, and the open item suggestion to follow TLS1.3 key_share extension pattern for algorithm negotiation would be great. Cheers, Owen -Original Message- From: internet-dra...@ietf.org Sent: Friday 29 June 2018 18:33 To: Richard Barnes ; Owen Friel (ofriel) Subject: New Version Notification for draft-barnes-tls-pake-02.txt A new version of I-D, draft-barnes-tls-pake-02.txt has been successfully submitted by Owen Friel and posted to the IETF repository. Name: draft-barnes-tls-pake Revision: 02 Title: Usage of SPAKE with TLS 1.3 Document date: 2018-06-29 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-02.txt Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/ Htmlized: https://tools.ietf.org/html/draft-barnes-tls-pake-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake Diff: https://www.ietf.org/rfcdiff?url2=draft-barnes-tls-pake-02 Abstract: The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] DNS-based Encrypted SNI
Hi folks, I just submitted: https://tools.ietf.org/html/draft-rescorla-tls-esni-00 This draft describes a DNS-based approach to doing encrypted SNI. Previously, we had thought this wouldn't work because only sites that were particularly vulnerable would do it, and so the use of ESNI marks you out. The idea behind this draft is that there are a lot of sites which are hosted by -- and whose DNS is run by -- a large provider, and that provider can shift many if not all of its sites to ESNI at once, thus removing the "standing out" issue and making a DNS-based approach practical. I am working on an implementation for NSS/Firefox and I know some others are working on their own implementations, so hopefully we can do some interop in Montreal. This is at a pretty early stage, so comments, questions, defect reports welcome. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DNS-based Encrypted SNI
On Mon, 2 Jul 2018, Eric Rescorla wrote: https://tools.ietf.org/html/draft-rescorla-tls-esni-00 This is at a pretty early stage, so comments, questions, defect reports welcome. This structure is placed in the RRData section of a TXT record as a base64-encoded string. If this encoding exceeds the 255 octet limit of TXT strings, it must be split across multiple concatenated strings as per Section 3.1.3 of [RFC4408]. It is strongly recommended not to use TXT records. Why not use a new RRTYPE? Everything these days knows how to serve unknown record types (see RFC 3597). The only possibly exception is provisioning tools of small players, but this document starts of saying you basically need to be on a bulk hosting provider anyway. They can properly provision. I need to think more about the document to see if there is really not something simpler or better possible. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DNS-based Encrypted SNI
On Mon, Jul 2, 2018 at 8:53 PM, Paul Wouters wrote: > On Mon, 2 Jul 2018, Eric Rescorla wrote: > > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 >> > > This is at a pretty early stage, so comments, questions, defect >> reports welcome. >> > > > This structure is placed in the RRData section of a TXT record as a > base64-encoded string. If this encoding exceeds the 255 octet > limit > of TXT strings, it must be split across multiple concatenated > strings > as per Section 3.1.3 of [RFC4408]. > > It is strongly recommended not to use TXT records. Why not use a new > RRTYPE? Everything these days knows how to serve unknown record types > (see RFC 3597). The only possibly exception is provisioning tools of > small players, but this document starts of saying you basically need > to be on a bulk hosting provider anyway. They can properly provision. > See: https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906 -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
