Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt

2019-03-08 Thread John Mattsson
Hi,

Thanks for driving this. Great work. I would like to see deprecation of done 
more often in IETF and elsewhere.

3GPP has deprecated TLS 1.0 and DTLS 1.0 some years ago (but could at that time 
not deprecate TLS 1.1 due to interop with older releases). I would estimate 
that 3GPP will deprecate TLS 1.1 this year, at least that is what I am going to 
suggest. I think that 3GPP will deprecate non-AEAD and non-PFS cipher suites at 
the same time as TLS 1.1.

Moving deprecation of SHA-1 to a different document makes sense to me. I would 
want such a document be deprecate a much as section 9.2 of RFC 7540 with the 
exception of TLS_PSK_WITH_AES_128_CCM_8 for IoT. I.e, I think such a document 
should forbid non-AEAD and < 2048 DHE as well as changing the MTI cipher suite 
in TLS 1.2. 

- I think the document should mention DTLS 1.0 much earlier, probably even in 
the title.

- Nit: The document uses "TLS1.0" "TLSv1.0" while most other drafts use "TLS 
1.0"

Cheers,
John

-Original Message-
From: TLS  on behalf of Stephen Farrell 

Date: Thursday, 8 November 2018 at 06:36
To: "TLS@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt


Hiya,

This version attempts to make the few changes discussed
at the meeting on Monday. I wrote a script that gave me
a list of 76(!) RFCs this might need to update, and may
of course have mucked that up, so if anyone has a chance
to check if (some of) those make sense, that'd be great.

Ta,
S.

On 08/11/2018 05:28, internet-dra...@ietf.org wrote:
> 
> 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-01.txt
>   Pages   : 21
>   Date: 2018-11-07
> 
> Abstract:
>This document, if approved, formally deprecates Transport Layer
>Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves
>these documents to the historic state.  These versions lack support
>for current and recommended cipher suites, 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.  Products having to support older versions
>increase the attack surface unnecessarily and increase opportunities
>for misconfigurations.  Supporting these older versions also requires
>additional effort for library and product maintenance.
> 
>This document updates many RFCs that normatively refer to TLS1.0 or
>TLS1.1 as described herein.  This document also updates 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-01
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-oldversions-deprecate-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-oldversions-deprecate-01
> 
> 
> 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
> 

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


Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt

2019-03-08 Thread Julien ÉLIE

Hi Stephen,

And RFC 7525 (belonging to BCP 195) states in Section 3.1.1:

    o  Implementations SHOULD NOT negotiate TLS version 1.1
[...]
    o  Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
   negotiate TLS version 1.2 over earlier versions of TLS.

That's why I thought RFC 8143 was already requiring not to use TLS 1.1.


SHOULD NOT != MUST NOT though:-) And in any case, an additional
unnecessary update would be no harm in this case, so I figure it's
best to leave it as-is.


Sure.



(Unless I'm missing some reason why that
UPDATE would do damage, in which case, we should chat more.)


No damage at all.
You can leave it as-is.



So, yes, I've added 7525 to the list of UPDATEd stuff in my copy
and made a change of intended status to BCP. (I bet a beer we'll
change that again >1 time:-)


:)

--
Julien ÉLIE

« Si l'art n'a pas de patrie, les artistes en ont une. » (Camille
  Saint-Saëns)

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


Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt

2019-03-08 Thread Stephen Farrell

Hiya,

On 08/03/2019 19:31, Julien ÉLIE wrote:
> Hi Stephen,
>>> That's why I suggest draft-ietf-tls-oldversions-deprecate does not
>>> update RFC 4642.  It is no longer useful.
>>> Are you OK with this analysis?
>>
>> Sorta:-) I think these are overlapping but not quite
>> identical updates. E.g. IIUC 8143 doesn't say to not
>> use TLSv1.1. I added the sentence below to the editor's
>> copy [1], but happy to do something else if I'm wrong,
>> which is entirely possible;-)
> 
> RFC 8143 (updating RFC 4642) states in Section 3:
> 
>    The best current practices documented in [BCP195] apply here.
>    Therefore, NNTP implementations and deployments compliant with this
>    document are REQUIRED to comply with [BCP195] as well.
> 
> And RFC 7525 (belonging to BCP 195) states in Section 3.1.1:
> 
>    o  Implementations SHOULD NOT negotiate TLS version 1.1
> [...]
>    o  Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
>   negotiate TLS version 1.2 over earlier versions of TLS.
> 
> That's why I thought RFC 8143 was already requiring not to use TLS 1.1.

SHOULD NOT != MUST NOT though:-) And in any case, an additional
unnecessary update would be no harm in this case, so I figure it's
best to leave it as-is. (Unless I'm missing some reason why that
UPDATE would do damage, in which case, we should chat more.)

> Incidentally, in the Abstract of draft-ietf-tls-oldversions-deprecate,
> it is said that this document updates RFC 7525, but RFC 7525 does not
> appear in the Updates list.  Shouldn't it be added?

Yeah, I was wondering about that too;-)

A BCP can consist of >1 RFC (e.g. see BCP10 [1]). So this one can
become part of BCP195 without UPDATEing RFC7525 I think. However,
now that I actually look at BCP 10, it has two RFCs: 7437 and 8318.
And in that case 8318 does update 7437.

So, yes, I've added 7525 to the list of UPDATEd stuff in my copy [2]
and made a change of intended status to BCP. (I bet a beer we'll
change that again >1 time:-)

Cheers,
S.

[1] https://tools.ietf.org/html/bcp10
[2]
https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt

> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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


Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt

2019-03-08 Thread Julien ÉLIE

Hi Stephen,

That's why I suggest draft-ietf-tls-oldversions-deprecate does not
update RFC 4642.  It is no longer useful.
Are you OK with this analysis?


Sorta:-) I think these are overlapping but not quite
identical updates. E.g. IIUC 8143 doesn't say to not
use TLSv1.1. I added the sentence below to the editor's
copy [1], but happy to do something else if I'm wrong,
which is entirely possible;-)


RFC 8143 (updating RFC 4642) states in Section 3:

   The best current practices documented in [BCP195] apply here.
   Therefore, NNTP implementations and deployments compliant with this
   document are REQUIRED to comply with [BCP195] as well.

And RFC 7525 (belonging to BCP 195) states in Section 3.1.1:

   o  Implementations SHOULD NOT negotiate TLS version 1.1
[...]
   o  Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
  negotiate TLS version 1.2 over earlier versions of TLS.

That's why I thought RFC 8143 was already requiring not to use TLS 1.1.



Incidentally, in the Abstract of draft-ietf-tls-oldversions-deprecate, 
it is said that this document updates RFC 7525, but RFC 7525 does not 
appear in the Updates list.  Shouldn't it be added?


--
Julien ÉLIE

« Le rire est une chose sérieuse avec laquelle il ne faut pas
  plaisanter. » (Raymond Devos)

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


Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt

2019-03-08 Thread Stephen Farrell

Hi Julien,

Thanks for taking the time to check this!

On 07/03/2019 20:42, Julien ÉLIE wrote:
> Hi Stephen,
>> This version attempts to make the few changes discussed
>> at the meeting on Monday. I wrote a script that gave me
>> a list of 76(!) RFCs this might need to update, and may
>> of course have mucked that up, so if anyone has a chance
>> to check if (some of) those make sense, that'd be great.
> 
> I believe updating RFC 4642 (TLS with NNTP) is useless because this RFC
> has already been updated by RFC 8143.
> 
> In RFC 8143:
> 
> A.6.  Related to Other Obsolete Wording
> 
>    The first two sentences of the seventh paragraph in Section 2.2.2 of
>    [RFC4642] are removed.  There is no special requirement for NNTP with
>    regard to TLS Client Hello messages.  Section 7.4.1.2 and Appendix E
>    of [RFC5246] apply.
> 
> That is to say, the following sentences in RFC 4642 are no longer relevant:
> 
>    Servers MUST be able to understand backwards-compatible TLS Client
>    Hello messages (provided that client_version is TLS 1.0 or later),
>    and clients MAY use backwards-compatible Client Hello messages.
>    Neither clients nor servers are required to actually support Client
>    Hello messages for anything other than TLS 1.0.
> 
> 
> 
> That's why I suggest draft-ietf-tls-oldversions-deprecate does not
> update RFC 4642.  It is no longer useful.
> Are you OK with this analysis?

Sorta:-) I think these are overlapping but not quite
identical updates. E.g. IIUC 8143 doesn't say to not
use TLSv1.1. I added the sentence below to the editor's
copy [1], but happy to do something else if I'm wrong,
which is entirely possible;-)

  "In the case of [RFC4642], that has already been
   updated by [RFC8143] which makes an overlapping,
   but not quite the same, update as this document."

Cheers,
S.

[1]
https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt

> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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