TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key
draft-ietf-tls-tls13-cert-with-extern-psk-07

[Ballot comment]
Side note: I'm perfectly fine with the track, or Informational -- it seems interesting and useful (as much as I could understand, at any rate :-))

[Ballot comment]
Building on a point Barry made, I think it would be useful to distinguish in the document whether this spec is experimental because we are waiting for quantum computers to materialize, or whether it is experimental because current implementors want to gain more experience with it before standardization. That way if it does come back at some future point on the standards track the context for why it was experimental in the first place will be there.

Please respond to the Gen-ART reviewer.

[Ballot comment]
Thanks for the work on this document and its described mechanism.

ID Nits reports:

  == Unused Reference: 'RFC2104' is defined on line 504, but no explicit
    reference was found in the text

[Ballot comment]
* Section 7. The paragraphs that start with “In this extension, the external PSK preserves secrecy if the EC(DH) key agreement” …” and “In the future, if the (EC)DH key agreement ..” seem to be saying the same thing differently.

* Section 7. It’s worth mentioning somewhere the obvious thing – how to generate, distribute, manage the external PSKs is out of scope for this specification.

* Section 7.  Per “TLS 1.3 [RFC8446] has received careful security analysis, and some informal reasoning shows that the addition of this extension does not introduce any security defects”, is there a citation for this “informal reasoning”?  Otherwise, it’s a soft statement.

* Editorial Nits:
- Section 3.  Typo.  s/inclue/include/

- Section 5.1. Typo. s/extension are/extensions are/

- Section 5.1. /Most of those extension are not impacted in any way.  This section discusses the impacts on the other extensions./Most of those extension are not impacted in any way by this specification.  However, this section discusses the extensions that require additional consideration./

- Section 5.1.  Typo. s/may be know to other partiers/may be known to other parties/

- Section 5.1. Typo. s/know to other parties/known to other parties/

- Section 7.  Typo.  s/that external PSK/that the external PSK/

[Ballot comment]
* Section 7. The paragraphs that start with “In this extension, the external PSK preserves secrecy if the EC(DH) key agreement” …” and “In the future, if the (EC)DH key agreement ..” seem to be saying the same thing differently.

* Section 7. It’s worth mentioning somewhere the obvious thing – how to generate, distribute, manage the external PSKs is out of scope for this specification.

* Section 7.  Per “TLS 1.3 [RFC8446] has received careful security analysis, and some informal reasoning shows that the addition of this extension does not introduce any security defects”, is there a citation for this “informal reasoning”?  Otherwise, it’s a very soft statement.

* Editorial Nits:
- Section 3.  Typo.  s/inclue/include/

- Section 5.1. Typo. s/extension are/extensions are/

- Section 5.1. /Most of those extension are not impacted in any way.  This section discusses the impacts on the other extensions./Most of those extension are not impacted in any way by this specification.  However, this section discusses the extensions that require additional consideration./

- Section 5.1.  Typo. s/may be know to other partiers/may be known to other parties/

- Section 5.1. Typo. s/know to other parties/known to other parties/

- Section 7.  Typo.  s/that external PSK/that the external PSK/

[Ballot comment]
From the shepherd writeup:

  There was concern raised that no one has reported implementation
  of this draft. The document has experimental status and that helped
  gain working group consensus to move it forward.

...and...

  The document has been reviewed and is supported by a few
  working group members.  Not everyone in the group agrees
  that it is needed,

This seems to imply that making it Experimental was a tactic to get it through the working group, and that concerns me a bit, though not enough to get to DISCUSS.  I would be happier if there were some discussion in the document about how we would determine that it is, indeed, needed and useful, and when we might know that we should move it to Standards Track or else abandon it.

Unfortunately, I suspect the answer to that is that we won’t know until we have quantum computers to mount attacks with, and that won’t be until certain places freeze over.  I realize that preparing for maybe someday having quantum computers and what they might someday do is an exercise that not everyone will want to spend time working on and implementing.

Some editorial comments, for which no reply is necessary:

— Section 4 —

  Since the
  "tls_cert_with_extern_psk" extension is intended to be used only with
  initial handshakes, it MUST NOT be sent alongside the "early_data"
  extension.

What happens if it is?  Should this say that if they appear together the server aborts the handshake with an "illegal_parameter" alert?

  The hash algorithm MUST
  be set when the PSK is established, with a default of SHA-256.

If it MUST be set, how is there a default?

— Section 5 —

  If the server responds with a HelloRetryRequest
  message, then the client sends another ClientHello message as
  described in Section 4.1.2 of [RFC8446], including the same
  "tls_cert_with_extern_psk" extension as the original ClientHello
  message or abort the handshake.

“, or aborts” (the comma closes the comma before “including”, and “aborts” is parallel to “sends”).

— Section 5.1 —

  Most of those extension are
  not impacted in any way.  This section discusses the impacts on the
  other extensions.

Make it “those extensions”.  And I would rephrase the second sentence as, “This section discusses the impacts on the extensions that are affected.”

  The "psk_key_exchange_modes" extension restricts both the
  use of PSKs offered in this ClientHello and those which the server
  might supply via a subsequent NewSessionTicket.

“Use of” needs to be factored out of the “both” clause:
NEW
...restricts the use of both the PSKs offered in this ClientHello
and those that the server might supply...
END

— Section 7 —

  the external PSKs and searching the resulting small set of
  possibilities, rather than brute force searching the whole key space.

“and search”, and “brute-force”

  The reasoning is explained in [K2016] (see
  Section 4.2).

I suggest “The reasoning is explained in Section 4.2 of [K2016].”  Otherwise it sounds like you should see 4.2 of this doc (and I think the html links will be generated better this way).

  This specification does not require that external PSK is known only

“that the external PSK”

[Ballot comment]
Just a small thing to double-check: I wonder if this sentence would actually require an update to RFC8446:
  "TLS 1.3 does not permit the server to send a CertificateRequest
  message when a PSK is being used.  This restriction is removed when
  the "tls_cert_with_extern_psk" extension is negotiated, allowing
  certificate-based authentication for both the client and the server."
Or maybe it should be phrased differently, just:
"If the "tls_cert_with_extern_psk" extension is negotiated, certificate-based authentication is allowed for both the client and the server."
I guess it depends on what exactly is said in RFC8446 (and I didn't went and tried to find it).

And as a side note, it is usually recommended to provide the link to the registry in the IANA section (to make life for IANA easier).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-tls13-cert-with-extern-psk-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. We have a question about this action, and we understand that the author needs to submit a review request to the designated experts.

In the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at

https://www.iana.org/assignments/tls-extensiontype-values/

a single new ExtensionType value is to be registered:

Value: [ TBD-at-Registration ]
Extension Name: tls_cert_with_extern_psk
TLS 1.3: CH, SH
Recommended: ?
Reference: [ RFC-to-be ]

IANA Question --> Is the value for "Recommended" intended to be "Y" for this new registration?

It appears that according to Section 17 of RFC 8447, the authors need to send a review request to the registration designated experts on the tls-reg-review@ietf.org mailing list. The IANA state for this document will remain "Not OK" until the experts have approved the registration.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-12-02):

From: The IESG
To: IETF-Announce
CC: tls-chairs@ietf.org, Joseph Salowey , tls@ietf.org, draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, joe@salowey.net, kaduk@mit.edu
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key) to Experimental RFC


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'TLS 1.3 Extension for Certificate-based
Authentication with an
  External Pre-Shared Key'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-12-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a TLS 1.3 extension that allows a server to
  authenticate with a combination of a certificate and an external pre-
  shared key (PSK).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document states that it is experimental track

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies a TLS 1.3 extension that allows a server to
  authenticate with a combination of a certificate and an external pre-
  shared key (PSK).

Working Group Summary

The document has strong support from a small number of participants in
the working group.  Concerns have been raised about the lack of
implementation plans, but there was enough support to move this
experimental draft forward.

Document Quality

  Implementation plans are unknown.

Personnel

  Joe Salowey is the document shepherd

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document has been reviewed by the document shepherd and the
document shepherd believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There was concern raised that no one has reported implementation of this draft. 
The document has experimental status and that helped gain working group
consensus to move it forward. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure has been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document has been reviewed and is supported by a few working group
members.  Not everyone in the group agrees that it is needed, but there is
enough consensus to move it forward.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are no ID nits in this document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

NA

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Does not change any existing RFCs

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document states that it is experimental track

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies a TLS 1.3 extension that allows a server to
  authenticate with a combination of a certificate and an external pre-
  shared key (PSK).

Working Group Summary

The document has strong support from a small number of participants in
the working group.  Concerns have been raised about the lack of
implementation plans, but there was enough support to move this
experimental draft forward.

Document Quality

  Implementation plans are unknown.

Personnel

  Joe Salowey is the document shepherd

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document has been reviewed by the document shepherd and the
document shepherd believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There was concern raised that no one has reported implementation of this draft. 
The document has experimental status and that helped gain working group
consensus to move it forward. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure has been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document has been reviewed and is supported by a few working group
members.  Not everyone in the group agrees that it is needed, but there is
enough consensus to move it forward.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are no ID nits in this document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

NA

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Does not change any existing RFCs

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document states that it is experimental track

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies a TLS 1.3 extension that allows a server to
  authenticate with a combination of a certificate and an external pre-
  shared key (PSK).

Working Group Summary

The document has strong support from a small number of participants in
the working group.  Concerns have been raised about the lack of
implementation plans, but there was enough support to move this
experimental draft forward.

Document Quality

  Implementation plans are unknown.

Personnel

  Joe Salowey is the document shepherd

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

TBD

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There was concern raised that no one has reported implementation of this draft. 
The document has experimental status and that helped gain working group
consensus to move it forward. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

TBD

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document has been reviewed and is supported by a few working group
members.  Not everyone in the group agrees that it is needed, but there is
enough consensus to move it forward.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

NA

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Does not change any existing RFCs

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

IANA section is complete

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

NA