[TLS] Zaheduzzaman Sarker's No Objection on draft-ietf-tls-exported-authenticator-14: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-tls-exported-authenticator-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/



--
COMMENT:
--

Thanks for the work on this document. I found it well written and I have minor
comments and Nits

Comment :
  * As this document asked for a IANA registration entry with DTLS-OK, hence
  this mechanism is OK to be used with DTLS. I understand the heavily
  references to TLS 1.3 as it relay on the mechanisms described there. However,
  I found it odd not find any reference to DTLS1.3 (we had it on the last
  formal IESG telechat, it is quite ready to be referenced). Is this
  intentional? is it supposed to be that this mechanism defined in this
  document on can be used with DTLS1.2?

  * Section 7.3 & 7.4: is "active connection" defined somewhere? it would be
  good if some descriptive texts are added for clarification as done for the
  other bullets in the same list.

  * For the API considerations I was expecting a API to generate the 
  certificate_request_context.

Nits:
 * Post-handshake authentication is not defined in section 4.6.3 of TLS 1.3
 * Section 4 & 5: likely copy paste error -- s/as its as its/as its



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Deprecating FFDHE + RSA Key Exchange

[Nimrod Aviram]

Dear all,

Following the discussion around draft-bartle-tls-deprecate-ffdhe, what are
your thoughts on deprecating RSA key exchange, and Finite-Field
Diffie-Hellman? (This would probably happen in a separate document.)

Considering the following different areas/use cases:
1. On the open Internet/web, both key exchange methods have been superseded
by ECDH. Browser support for FFDHE has been entirely removed IIUC, so
formally deprecating FFDHE should not be a problem (right?). Are there any
reasons to avoid deprecating FFDHE and RSA on the open Internet?
2. On local networks, deprecating both key exchange methods may leave some
endpoints without any key exchange algorithms. Could you please give
feedback on the following:
a. Is the number of such endpoints large enough that we shouldn’t deprecate
these methods?
b. If the answer to the above is yes, what would be a good plan/timeline to
deprecate them?

We could also consider limiting FFDHE to well-known groups of at least 2048
bits, with fully ephemeral secrets. But this would likely cause enough
interoperability problems that we might as well deprecate it fully, right?

thanks,
Nimrod
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Genart last call review of draft-ietf-tls-exported-authenticator-13

[Lars Eggert]

Christer, thank you for your review. I have entered a No Objection ballot for 
this document.

Lars


> On 2020-10-28, at 10:29, Christer Holmberg via Datatracker  
> wrote:
> 
> Reviewer: Christer Holmberg
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-tls-exported-authenticator-13
> Reviewer: Christer Holmberg
> Review Date: 2020-10-28
> IETF LC End Date: 2020-10-16
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: I am happy with the way my comments and issues have been addressed,
> and the document is now ready for publication.
> 
> Major issues: N/A
> 
> Minor issues: N/A
> 
> Nits/editorial comments: N/A
> 
> 
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecating FFDHE + RSA Key Exchange

[Blumenthal, Uri - 0553 - MITLL]

As has been pointed out, TLS is *not* just the Web. And TLS peers are not 
necessarily browsers.

 

Yes, there are reasons to avoid deprecating FFDHE with RSA signatures on the 
open Internet (besides that doing it would be silly counterproductive, as not 
everybody uses ECC).

 

Limiting FFDHE to well-known groups would probably be a good idea. Though it 
would be educational to hear from those who for some reasons need weird 
“special” groups of weird sizes.

--

Regards,

Uri

 

There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of Nimrod Aviram 

Date: Tuesday, April 6, 2021 at 05:28
To: "" 
Subject: [TLS] Deprecating FFDHE + RSA Key Exchange

 

Dear all,

Following the discussion around draft-bartle-tls-deprecate-ffdhe, what are your 
thoughts on deprecating RSA key exchange, and Finite-Field Diffie-Hellman? 
(This would probably happen in a separate document.)

Considering the following different areas/use cases:
1. On the open Internet/web, both key exchange methods have been superseded by 
ECDH. Browser support for FFDHE has been entirely removed IIUC, so formally 
deprecating FFDHE should not be a problem (right?). Are there any reasons to 
avoid deprecating FFDHE and RSA on the open Internet?
2. On local networks, deprecating both key exchange methods may leave some 
endpoints without any key exchange algorithms. Could you please give feedback 
on the following:
a. Is the number of such endpoints large enough that we shouldn’t deprecate 
these methods?
b. If the answer to the above is yes, what would be a good plan/timeline to 
deprecate them?

We could also consider limiting FFDHE to well-known groups of at least 2048 
bits, with fully ephemeral secrets. But this would likely cause enough 
interoperability problems that we might as well deprecate it fully, right?

thanks,
Nimrod




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Éric Vyncke's No Objection on draft-ietf-tls-exported-authenticator-14: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-tls-exported-authenticator-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

I am trusting the WG and the responsible AD for ensuring that the specific
section in references are the correct ones.

-- Section 2 --
Unsure where the "terminology" part is...

Also, should "Client" and "Server" be defined here ? Reading section 3, I am
still unsure whether the "client" and "server" are the "TLS client" and "TLS
server" ...

In the same vein, a small figure with all parties involved would be welcome by
the reader.

== NITS ==

In some places, 'TLS13' is used as an anchor rather than 'RFC8446'.

Sometimes, the document uses 'octet' and sometimes 'bytes'.

-- Section 1 --
Spurious '.' in the last §.

-- Section 4 --
"as its as its" ?



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Benjamin Kaduk's Yes on draft-ietf-tls-exported-authenticator-14: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tls-exported-authenticator-14: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/



--
COMMENT:
--

I've made some (mostl) editorial suggestions in a github PR:
https://github.com/tlswg/tls-exported-authenticator/pull/73

Despite the overall YES ballot, I do have some substantive comments that
may be worth some further consideration.

Do we want to give any insight or examples into how an application might
choose to use the certificate_request_context?

Thanks to Yaron Sheffer for the multiple secdir reviews.  My
understanding is that the intent of this document is to only allow
"server_name" to appear in the ClientCertificateRequest structure that
otherwise uses the "CR" notation in the TLS 1.3 column of the TLS
ExtensionType Values registry, but not to allow for "server_name" in
authenticator CertificateRequests or handshake CertificateRequests.
Assuming that's correct, the easiest way to indicate that would be if
there was a "Comment" column in the registry that could say "only used
in ClientCertificateRequest certificate requests and no other
certificate requests", but there is not such a column in the registry.
I think it could also work to be much more clear in the IANA
considerations of this document as to why the "CR" is being added and
what restrictions there are on its use, even if that's not quite as
clean of a solution.

Section 1

   multiple identities -  Endpoints that are authoritative for multiple
  identities - but do not have a single certificate that includes
  all of the identities - can authenticate additional identities
  over a single connection.

IIUC this is only new functionality for server endpoints, since client
endpoints can use different certificates for subsequent post-handshake
authentication events.

   TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED
   to implement the mechanisms described in this document.

Please clarify whether this is a minimum TLS version required for using
EAs, or that this is a binding requirement on implementations of the
named protocol versions.  (If the latter is intended we may have some
discussions about an Updates: tag...)

Section 5.1

Using an exporter value as the handshake context means that any client
authentication from the initial handshake is not cryptographically
digested into the exporter value.  In light of what we ran into with
EAP-TLS1.3, do we want to revisit whether we're still happy with that?
We should in practice still benefit from the implicit confirmation that
anything the server participates in after receiving the Client Finished
means the server properly validated it and did not abort the handshake,
but it's a bit awkward, especially since the RFC 8446 post-handshake
authentication does digest the entire initial handshake transcript.
Would we feel any safer if an exporter variant was available that
digested the entire initial handshake transcript and we could use that?

Section 5.2.1

   Certificates chosen in the Certificate message MUST conform to the
   requirements of a Certificate message in the negotiated version of
   TLS.  In particular, the certificate chain MUST be valid for the
   signature algorithms indicated by the peer in the
   "signature_algorithms" and "signature_algorithms_cert" extension, as
   described in Section 4.2.3 of [TLS13] for TLS 1.3 or the
   "signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of
   [RFC5246] for TLS 1.2.

This seems awkward.  Do "the requirements of a Certificate message in
the negotiated version of TLS" include the actual message structure?
Because the rest of the document suggests that we always use the TLS 1.3
Certificate, but this line would set us up for using a TLS 1.2
Certificate.

Also, per §1.3 of RFC 8446, "signature_algorithms_cert" also applies to
TLS 1.2, so the last sentence seems incorrect or at least incomplete.

Section 5.2.1

   Otherwise, the Certificate message MUST contain only extensions
   present in the TLS handshake.  Unrecognized extensions in the
   authenticator request MUST be ignored.

At least the first sentence seems redundant with the previous section
(but I did not propose removing this in my editorial PR).  The second
sentence arguably follows from the RFC 8446 requirements, though I don't
mind mentioning it again as much as I do for the first sentence.

Section 5.2.2

   The authenticat

Re: [TLS] Secdir telechat review of draft-ietf-tls-exported-authenticator-14

[Benjamin Kaduk]

Hi Yaron,

Thanks for the (multiple!) reviews.

My understanding is that the intention is not to allow "server_name" in all
CertificateRequests but only specifically in the ClientCertificateRequest
case.  I think it can be helpful to notate that with a "CR" in the "TLS
1.3" column of the registry but we would need some further clarification as
to what that notation actually means.  I left some suggestions for how to
do that in my ballot position, but to summarize: a "comment" column in the
registry would be great for this, and failing that a note in the IANA
Considerations of this document to clarify what is and is not being
registered would probably work as well.

Thanks again for highlighting this point,

Ben

On Fri, Apr 02, 2021 at 09:05:38AM -0700, Yaron Sheffer via Datatracker wrote:
> Reviewer: Yaron Sheffer
> Review result: Has Issues
> 
> After a bit of back and forth over my *two* previous SecDir requests, I'm
> afraid that my original comment has not yet been fully addressed. The IANA
> considerations section (Sec. 8.1) adds server_name as a possible extension for
> CertificateRequest. This would be a non-backward compatible change to TLS.
> 
> IMO what we needed to do is both to clarify the allowed extensions for what
> Nick called "the CR-like structure" (almost done in Sec. 4, though the last
> sentence should by changed to include CertificateRequest) and undo the change
> to the TLS ExtensionType registry (not done, would require to remove Sec. 
> 8.1).
> 
> * Nit: this sentence is repeated almost verbatim in Sec. 4 and Sec. 5, and in
> both cases is mangled.
> 
> Old:
> 
> The application layer protocol used to send the authenticator request SHOULD
> use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as its
> as its underlying transport to keep the request confidential.
> 
> New:
> 
> The application layer protocol used to send the authenticator request SHOULD
> use a secure *channel* with equivalent security to TLS, such as QUIC
> [QUIC-TLS], as its ~~as its~~ underlying transport to keep the request
> confidential.
> 
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Secdir telechat review of draft-ietf-tls-exported-authenticator-14

[Yaron Sheffer]

I fully agree. Thank you Ben!

On 4/6/21, 21:43, "Benjamin Kaduk"  wrote:

Hi Yaron,

Thanks for the (multiple!) reviews.

My understanding is that the intention is not to allow "server_name" in all
CertificateRequests but only specifically in the ClientCertificateRequest
case.  I think it can be helpful to notate that with a "CR" in the "TLS
1.3" column of the registry but we would need some further clarification as
to what that notation actually means.  I left some suggestions for how to
do that in my ballot position, but to summarize: a "comment" column in the
registry would be great for this, and failing that a note in the IANA
Considerations of this document to clarify what is and is not being
registered would probably work as well.

Thanks again for highlighting this point,

Ben

On Fri, Apr 02, 2021 at 09:05:38AM -0700, Yaron Sheffer via Datatracker 
wrote:
> Reviewer: Yaron Sheffer
> Review result: Has Issues
> 
> After a bit of back and forth over my *two* previous SecDir requests, I'm
> afraid that my original comment has not yet been fully addressed. The IANA
> considerations section (Sec. 8.1) adds server_name as a possible 
extension for
> CertificateRequest. This would be a non-backward compatible change to TLS.
> 
> IMO what we needed to do is both to clarify the allowed extensions for 
what
> Nick called "the CR-like structure" (almost done in Sec. 4, though the 
last
> sentence should by changed to include CertificateRequest) and undo the 
change
> to the TLS ExtensionType registry (not done, would require to remove Sec. 
8.1).
> 
> * Nit: this sentence is repeated almost verbatim in Sec. 4 and Sec. 5, 
and in
> both cases is mangled.
> 
> Old:
> 
> The application layer protocol used to send the authenticator request 
SHOULD
> use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as 
its
> as its underlying transport to keep the request confidential.
> 
> New:
> 
> The application layer protocol used to send the authenticator request 
SHOULD
> use a secure *channel* with equivalent security to TLS, such as QUIC
> [QUIC-TLS], as its ~~as its~~ underlying transport to keep the request
> confidential.
> 
> 


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls