RFC 8672 on TLS Server Identity Pinning with Tickets

rfc-editor@rfc-editor.org Thu, 31 October 2019 21:24 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC12120818 for <ietf-announce@ietfa.amsl.com>; Thu, 31 Oct 2019 14:24:46 -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, RCVD_IN_DNSWL_MED=-2.3, 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 bYnJN8oGyQ9R for <ietf-announce@ietfa.amsl.com>; Thu, 31 Oct 2019 14:24:44 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A572120145 for <ietf-announce@ietf.org>; Thu, 31 Oct 2019 14:24:43 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id DA7CFF406D3; Thu, 31 Oct 2019 14:24:33 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Subject: =?UTF-8?B?UkZDIDg2NzIgb24gVExTIFNlcnZlciBJZGVudGl0eSBQaW5uaW5nIHdpdGggVGlja2V0cw==?=
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org
Content-type: text/plain; charset=UTF-8
Message-Id: <20191031212433.DA7CFF406D3@rfc-editor.org>
Date: Thu, 31 Oct 2019 14:24:33 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/RBFKBfyup2W2O2UVt1YO4hZ5koM>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2019 21:24:46 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 8672

        Title:      TLS Server Identity Pinning with Tickets 
        Author:     Y. Sheffer,
                    D. Migault
        Status:     Experimental
        Stream:     Independent
        Date:       October 2019
        Mailbox:    yaronf.ietf@gmail.com, 
                    daniel.migault@ericsson.com
        Pages:      22
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-sheffer-tls-pinning-ticket-12.txt

        URL:        https://www.rfc-editor.org/info/rfc8672

        DOI:        10.17487/RFC8672

Misissued public-key certificates can prevent TLS clients from
appropriately authenticating the TLS server. Several alternatives
have been proposed to detect this situation and prevent a client from
establishing a TLS session with a TLS end point authenticated with an
illegitimate public-key certificate. These mechanisms are either not
widely deployed or limited to public web browsing.

This document proposes experimental extensions to TLS with opaque
pinning tickets as a way to pin the server's identity. During an
initial TLS session, the server provides an original encrypted
pinning ticket. In subsequent TLS session establishment, upon receipt
of the pinning ticket, the server proves its ability to decrypt the
pinning ticket and thus the ownership of the pinning protection key.
The client can now safely conclude that the TLS session is
established with the same TLS server as the original TLS session. One
of the important properties of this proposal is that no manual
management actions are required.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC