[TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-00.txt

[internet-drafts]

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   : Deprecating Obsolete Key Exchange Methods in TLS
Authors : Carrick Bartle
  Nimrod Aviram
Filename: draft-ietf-tls-deprecate-obsolete-kex-00.txt
Pages   : 20
Date: 2022-06-14

Abstract:
   This document makes several prescriptions regarding the following key
   exchange methods in TLS, most of which have been superseded by better
   options:

1. This document deprecates the use of RSA key exchange in TLS.

2. It limits the use of Diffie Hellman key exchange over a finite field to avoid
known vulnerabilities and improper security properties.

3. It discourages the use of static elliptic curve Diffie Hellman cipher suites.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-00.html


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

[Nick Sullivan]

Hi Roman,

Thank you for the good suggestions. Comments addressed here
https://github.com/tlswg/tls-subcerts/pull/108

Best,
Nick

On Tue, May 31, 2022 at 5:49 PM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-tls-subcerts-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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>
>
>
> --
> COMMENT:
> --
>
> ** Section 4
>  Endpoints will reject delegated
>   credentials that expire more than 7 days from the current time (as
>   described in Section 4.1) based on the default (see Section 3.
>
> For clarity, consider:
>
> NEW
> By default, unless set to an alternative value by an application profile
> (see
> Section 3), endpoints will reject delegated credentials that expire more
> than 7
> days from the current time (as described in Section 4.1.3).
>
> ** Section 7.1
>However, they cannot create new delegated credentials.  Thus,
>delegated credentials should not be used to send a delegation to an
>untrusted party, ...
>
> The second sentence doesn’t seem to follow from the first.
>
> ** Appendix B
>The following certificate has the Delegated Credentials OID.
>
> For clarity, consider:
>
> NEW
> The following is an example of a delegation certificate which satisfies the
> requirements described in Section 4.2 (i.e., uses the DelegationUsage
> extension
> and has the digitalSignature KeyUsage).
>
> ** Appendix B.  I will leave to the RFC Editor to decide if using the
> Watson
> Ladd’s personal home page (kc2kdm.com) in the certificate SAN is an
> acceptable
> example domain name.
>
> Editorial Nits
>
> ** Abstract.  Typo. s/to to/to/
>
> ** Section 4.2. Typo. s/documnt/document/
>
> ** Section 7.6.  In the spirit of inclusive language, consider if there is
> an
> alternative term to “man-in-the-middle certificate”
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls