Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Stephen Farrell]

Hi Tom,

On 10/11/2020 11:33, Stephen Farrell wrote:



On 10/11/2020 11:30, tom petch wrote:
Perhaps a second look at the algorithm 
to work out why these got missed to get a fix on how many more there may be. 



Sure, that's reasonable. (Mightn't be today.)


Just did that check by comparing [1] to the RFCs
referenced in the draft and best I can see only
5953 and 6353 were missing in the end.

I'd argue it's ok to add those without re-doing
the IETF LC as they were mentioned in early on,
in the LC, but of course that's the AD's call.

I'm doing the edits for draft-10 now so it'll
pop out shortly.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/rfc4347/referencedby/



Cheers,
S.

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



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-10.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 TLSv1.0 and TLSv1.1
Authors : Kathleen Moriarty
  Stephen Farrell
Filename: draft-ietf-tls-oldversions-deprecate-10.txt
Pages   : 24
Date: 2020-12-14

Abstract:
   This document, if approved, formally deprecates Transport Layer
   Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346).
   Accordingly, those documents (will be moved|have been moved) to
   Historic status.  These versions lack support for current and
   recommended cryptographic algorithms and mechanisms, and various
   government and industry profiles of applications using TLS now
   mandate avoiding these old TLS versions.  TLSv1.2 has been the
   recommended version for IETF protocols since 2008, providing
   sufficient time to transition away from older versions.  Removing
   support for older versions from implementations reduces the attack
   surface, reduces opportunity for misconfiguration, and streamlines
   library and product maintenance.

   This document also deprecates Datagram TLS (DTLS) version 1.0
   (RFC4347), but not DTLS version 1.2, and there is no DTLS version
   1.1.

   This document updates many RFCs that normatively refer to TLSv1.0 or
   TLSv1.1 as described herein.  This document also updates the best
   practices for TLS usage in RFC 7525 and hence is part of BCP195.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-10
https://datatracker.ietf.org/doc/html/draft-ietf-tls-oldversions-deprecate-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-oldversions-deprecate-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[tom petch]

On 14/12/2020 14:53, Stephen Farrell wrote:


Hi Tom,

On 10/11/2020 11:33, Stephen Farrell wrote:



On 10/11/2020 11:30, tom petch wrote:

Perhaps a second look at the algorithm
to work out why these got missed to get a fix on how many more there may be.



Sure, that's reasonable. (Mightn't be today.)


Just did that check by comparing [1] to the RFCs
referenced in the draft and best I can see only
5953 and 6353 were missing in the end.

I'd argue it's ok to add those without re-doing
the IETF LC as they were mentioned in early on,
in the LC, but of course that's the AD's call.

I'm doing the edits for draft-10 now so it'll
pop out shortly.


Stephen

Thank you for checking. With those two being SNMP
and having both DTLS and TLS I was thinking of
conspiracy theories but no:-)
I should see the announcement of the updated I-D
and will check it when I do.
Like you, I do not see the need for a further LC
just for the addition of those two RFC,

Tom Petch



Cheers,
S.

[1] https://datatracker.ietf.org/doc/rfc4347/referencedby/



Cheers,
S.

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



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

Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Gary Gapinski]

  
  
On 11/28/20 10:13 AM, Stephen Farrell
  wrote:

Hiya,
  
  
  On 28/11/2020 04:39, Gary Gapinski wrote:
  
  Looking at https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-09


§2:


   * §2 ¶5 has «TLS 1.3, specified in TLSv1.3 [RFC8446]…».

   * §2 ¶4 has «TLSv1.2, specified in RFC5246 [RFC5246]…»

   * §2 ¶3 has «TLS 1.1, specified in [RFC4346]…»


Were these variant ( specified in plaintext+[link], specified in
link+[link],

specified in [link] ) citation forms deliberate?

  
  
  Nope. We'll make 'em more consistent.

There are still "double cites" — …RFC [RFC]… — visible in
  the draft 10 HTML. Perhaps an RFC tooling problem as you had
  suspected.

  


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

Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Stephen Farrell]

Hiya,

On 14/12/2020 19:25, Gary Gapinski wrote:

On 11/28/20 10:13 AM, Stephen Farrell wrote:

Hiya,

On 28/11/2020 04:39, Gary Gapinski wrote:

Looking at https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-09
 §2:

   * §2 ¶5 has «TLS 1.3, specified in TLSv1.3 [RFC8446]…».
   * §2 ¶4 has «TLSv1.2, specified in RFC5246 [RFC5246]…»
   * §2 ¶3 has «TLS 1.1, specified in [RFC4346]…»

Were these variant ( specified in plaintext+[link], specified in link+[link],
specified in [link] ) citation forms deliberate?


Nope. We'll make 'em more consistent. 


There are still "double cites" — …RFC [RFC]… — visible in the draft 10
HTML. Perhaps an RFC tooling problem as you had suspected.


Probably not all, but the RFC editor will eventually sort
that kind of thing out according to their preferred style
so I left it be (also being a little bit lazy, I admit:-)

Cheers,
S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-cross-sni-resumption-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   : Transport Layer Security (TLS) Resumption across 
Server Names
Author  : Victor Vasiliev
Filename: draft-ietf-tls-cross-sni-resumption-00.txt
Pages   : 5
Date: 2020-12-14

Abstract:
   This document specifies a way for the parties in the Transport Layer
   Security (TLS) protocol to indicate that an individual session ticket
   can be used to perform resumption even if the Server Name of the new
   connection does not match the Server Name of the original.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-cross-sni-resumption-00.html


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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