IETF conflict review for draft-sheffer-tls-pinning-ticket
conflict-review-sheffer-tls-pinning-ticket-02

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-sheffer-tls-pinning-ticket@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-sheffer-tls-pinning-ticket-12

The IESG has completed a review of draft-sheffer-tls-pinning-ticket-12
consistent with RFC5742.

The IESG has no problem with the publication of 'TLS Server Identity Pinning
with Tickets'  as an Experimental
RFC.

The IESG has concluded that this work is related to IETF work done in the TLS
WG, but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-sheffer-tls-pinning-ticket/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-sheffer-tls-pinning-ticket@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-sheffer-tls-pinning-ticket-11

The IESG has completed a review of draft-sheffer-tls-pinning-ticket-11
consistent with RFC5742.

The IESG has no problem with the publication of 'TLS Server Identity Pinning
with Tickets'  as an Experimental
RFC.

The IESG has concluded that this work is related to IETF work done in the TLS
WG ,but this relationship does not prevent publishing.

Additionally, the IESG requests the following note be added to the document
if it is published:

The cryptographic construction used in this document to derive a
pinning_protection_key from an existing resumption_protection_key (e.g., one
that is shared across a cluster of servers authoritative for the same domain)
reuses the same long-term cryptographic key for both bulk encryption (of TLS
session tickets) and as the PRK input to HMAC [RFC2104] via the HKDF-Expand()
[RFC5689] construction.  This reuse of key material without an intermediate
derivation step has not undergone extensive cryptanalysis and may introduce
unforseen weaknesses for both the original session-ticket encryption usage
[RFC5077] and the new usage proposed in this document.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-sheffer-tls-pinning-ticket/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
I am happy for this document to be published in the Independent Stream.

I have a couple of small comments/questions on the document itself:

2.3.  Indexing the Pins

  Each pin is associated with a set of identifiers which include among
  others host name, IP addresses, protocol (TLS or DTLS) and port
                    ^^^^^^^^^^^^
Here you say that PIN is associated with IP addresses.

  number.  In other words, the pin for port TCP/443 may be different
  from that for DTLS or from the pin for port TCP/8443.  These
  identifiers are expected to be relevant to characterize the identity
  of the server as well as the establishing TLS session.  When a host
  name is used, it MUST be the value sent inside the Server Name
  Indication (SNI) extension.  This definition is similar to a Web
  Origin [RFC6454], but does not assume the existence of a URL.

  The purpose of ticket pinning is to pin the server identity.  As a
  result, any information orthogonal to the server's identity MUST NOT
  be considered in indexing.  More particularly, IP addresses are
  ephemeral and forbidden in SNI and therefore pins MUST NOT be
                                                ^^^^^^^^^^^^^^^^
  associated with IP addresses.  Similarly, CA names or public keys
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And here you say that it MUST NOT be associated with IP addresses. Is there some inconsistency in text or did I misread this section?

  associated with server MUST NOT be used for indexing as they may
  change over time.


4.4.  Pinning Proof

proof = HMAC(original_pinning_secret, "pinning proof 2",
              pinning_proof_secret + Hash(server_public_key))

I think HMAC function is defined to have 2 parameters (data and key), but you have 3 here.