Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Benjamin Kaduk]

Hi Mike,

On Tue, Oct 13, 2020 at 03:59:27PM -0400, Michael D'Errico wrote:
> > Saying that it's your preference without saying why is likely
> > to have little effect, yes.  (We endeavor to make decisions
> > based on technical merit, not voting, after all.)  Why do you
> > want this?
> 
> Hi,
> 
> I think the advice should be: "If your code currently
> only supports TLS 1.0, please spend a week or two
> adding support for both TLS 1.1 and the downgrade
> protection SCSV."
> 
> Since the vast majority of the 1.0 and 1.1 specifications
> is the same, someone who takes the advice has a
> good chance of succeeding.
> 
> (You could then also say which other extensions are
> important and why, roughly in order of importance.)

I don't see much to object to in that advice, but the precondition is
rather limiting.  Have you considered writing a draft that covers it
(including fleshing out the important extensions)?

> Recommending that people wholesale abandon
> their legacy system and implement TLS (1.2 and)
> 1.3 is asking too much, and will largely be ignored
> by the people who would be able to add 1.1 to their
> 1.0 code.

It may be true that such recommendations will largely be ignored by people
who have 1.0-only implementations (recall that the IETF does not have an
enforcement arm!), but draft-ietf-tls-oldversions-deprecate aims to be a
Best Current Practice, and there are not preconditions to that Best.  The
Best thing you can do for TLS involves TLS 1.3, and TLS 1.2 is probably
okay, too.  I don't see anyone arguing that the Best Curent Practice for
TLS, in general, involves TLS 1.0 or 1.1, at this point.

-Ben

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

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Sean Turner]

> On Oct 13, 2020, at 14:34, Benjamin Kaduk  wrote:
> 
> I think we still need to check for the latest version of the SP800-52r2
> reference, too.

You are correct - the date should be August 2019:
https://github.com/tlswg/oldversions-deprecate/pull/8

spt

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

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Michael D'Errico]

> Saying that it's your preference without saying why is likely
> to have little effect, yes.  (We endeavor to make decisions
> based on technical merit, not voting, after all.)  Why do you
> want this?

Hi,

I think the advice should be: "If your code currently
only supports TLS 1.0, please spend a week or two
adding support for both TLS 1.1 and the downgrade
protection SCSV."

Since the vast majority of the 1.0 and 1.1 specifications
is the same, someone who takes the advice has a
good chance of succeeding.

(You could then also say which other extensions are
important and why, roughly in order of importance.)

Recommending that people wholesale abandon
their legacy system and implement TLS (1.2 and)
1.3 is asking too much, and will largely be ignored
by the people who would be able to add 1.1 to their
1.0 code.

I understand that we don't vote here.

Mike


On Tue, Oct 13, 2020, at 15:15, Benjamin Kaduk wrote:
> Hi Mike,
> 
> On Tue, Oct 13, 2020 at 03:09:15PM -0400, Michael D'Errico wrote:
> > I know that saying this will have no effect, but I'd
> > rather see deprecation of just TLS 1.0 and retain
> > version 1.1 as not recommended.
> 
> Saying that it's your preference without saying why is likely to have
> little effect, yes.  (We endeavor to make decisions based on technical
> merit, not voting, after all.)  Why do you want this?  TLS 1.1 seems to
> have minimal usage (less even than 1.0) and is much closer to 1.0 than 1.2
> (let alone 1.3) in terms of design and safety.
> 
> > Also, we should not abandon RFC 7507 (downgrade
> > protection SCSV).  What harm is there in keeping it
> > around?  None.
> 
> I don't expect implementations to abandon SCSV any faster than they abandon
> TLS 1.0 or 1.1.  But if the official advice is that 1.0 and 1.1 are
> obsolete, then the official advice should also be that SCSV is obsolete --
> its function is performed in a different way by the newer versions of TLS.
> 
> -Ben
>

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

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Benjamin Kaduk]

Hi Mike,

On Tue, Oct 13, 2020 at 03:09:15PM -0400, Michael D'Errico wrote:
> I know that saying this will have no effect, but I'd
> rather see deprecation of just TLS 1.0 and retain
> version 1.1 as not recommended.

Saying that it's your preference without saying why is likely to have
little effect, yes.  (We endeavor to make decisions based on technical
merit, not voting, after all.)  Why do you want this?  TLS 1.1 seems to
have minimal usage (less even than 1.0) and is much closer to 1.0 than 1.2
(let alone 1.3) in terms of design and safety.

> Also, we should not abandon RFC 7507 (downgrade
> protection SCSV).  What harm is there in keeping it
> around?  None.

I don't expect implementations to abandon SCSV any faster than they abandon
TLS 1.0 or 1.1.  But if the official advice is that 1.0 and 1.1 are
obsolete, then the official advice should also be that SCSV is obsolete --
its function is performed in a different way by the newer versions of TLS.

-Ben

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

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Michael D'Errico]

I know that saying this will have no effect, but I'd
rather see deprecation of just TLS 1.0 and retain
version 1.1 as not recommended.

Also, we should not abandon RFC 7507 (downgrade
protection SCSV).  What harm is there in keeping it
around?  None.

Mike

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

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Benjamin Kaduk]

Thanks, Sean, the linked pull requests seem to do the trick.

Skimming through
https://mailarchive.ietf.org/arch/msg/tls/K9_uA6m0dD_oQCw-5kAbha-Kq5M/ once
more, I think I still plan to put out a status-change document to move RFC
5469 (IDEA and DES ciphers) to Historic in parallel with the IETF LC for
this document.  It is probably not critical that we mention such a change
in the document text, though we could if we want to.

I think we still need to check for the latest version of the SP800-52r2
reference, too.

Thanks again,

Ben

On Tue, Oct 13, 2020 at 01:02:07PM -0400, Sean Turner wrote:
> Ben,
> 
> Thanks for pointing out I missed a couple. Inline …
> 
> spt
> 
> > On Aug 13, 2020, at 13:54, Benjamin Kaduk  wrote:
> > 
> > Hi Kathleen,
> > 
> > Also inline.
> > 
> > On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
> >> Hi Ben,
> >> 
> >> Thanks for your review.  Some initial responses are inline.
> >> 
> >> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:
> >> 
> >>> I found three documents (3656, 4540, 7562) in the list of update targets
> >>> that are on the ISE (not IETF) stream.  I had talked to Adrian during my
> >>> preliminary review, and in principle it is permissible to make those
> >>> updates as part of this document, but we will need specific ISE approval
> >>> to do so.  I am supposed to sync up with him during IETF LC, but the
> >>> document needs to be updated to clarify that the updates of ISE
> >>> documents are/will be done with permission of the ISE.  (Please also try
> >>> to double-check that the list is complete; I didn't find an
> >>> authoritative list of "all documents on the ISE stream" to grep against,
> >>> and I didn't try to have something parse rfc-index.xml to output such a
> >>> list.
> >>> 
> >> 
> >> OK, so you'd like a list added and that's not in your pull request, is that
> >> right?  We'll figure it out. Thanks in advance with the coordination with
> >> Adrian.
> > 
> > That's correct, this is not in my pull request (not least because that list
> > of three documents is incomplete -- I sent a more-likely-complete list of 6
> > documents in an off-list follow-up.
> > https://www.rfc-editor.org/search/rfc_search_detail.php?stream_name=Independent=All
> > will get a (presumably authoritative) list of ISE-stream documents, FWIW.
> 
> After going through the list I found six. Here’s some text that addresses the 
> fact that will have permission from the ISE:
> https://github.com/tlswg/oldversions-deprecate/pull/6
> 
> >>> Section 1.1
> >>> 
> >>> I went through all 83 of the references in the big list, that are
> >>> supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0,
> >>> as well as the shorter list of already-obsoleted documents.
> >>> 
> >>> I won't bore you with my full notes, but there are some particular
> >>> things that stood out from the review:
> >>> 
> >>> - We have a separate list of updates for documents that are already
> >>>  obsolete (but don't say much about why we're going go the extra
> >>>  bother).  However, three of the documents in our main list of updates
> >>>  (4743, 4744, and 6460) are already Historic, and presumably should be
> >>>  treated more like the already-obsolete ones.
> >>> 
> >> 
> >> Obsolete does not mean the same thing as deprecate though.  TLSv1.2 has
> >> been obsoleted by TLSv1.3, but not deprecated.  The deprecation goes the
> >> extra step to say not to use it and it triggers many to begin phase out
> >> plans.  Am I misunderstanding the question?
> > 
> > I think you're misunderstanding the question, yes, sorry.
> > 
> > I think we want the documents that are Historic to be listed separately
> > from the other ("regular") updates, in a manner akin to what is already
> > done for the documents that are currently obsolete.  Or, perhaps, to say
> > that there is no point in deprecating something that is already historic,
> > and not bother updating those three documents, but it seems okay to keep
> > the current status with a comprehensive list of updates.
> 
> How about this:
> https://github.com/tlswg/oldversions-deprecate/pull/7
> 
> spt
> 
> 

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

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Sean Turner]

Ben,

Thanks for pointing out I missed a couple. Inline …

spt

> On Aug 13, 2020, at 13:54, Benjamin Kaduk  wrote:
> 
> Hi Kathleen,
> 
> Also inline.
> 
> On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
>> Hi Ben,
>> 
>> Thanks for your review.  Some initial responses are inline.
>> 
>> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:
>> 
>>> I found three documents (3656, 4540, 7562) in the list of update targets
>>> that are on the ISE (not IETF) stream.  I had talked to Adrian during my
>>> preliminary review, and in principle it is permissible to make those
>>> updates as part of this document, but we will need specific ISE approval
>>> to do so.  I am supposed to sync up with him during IETF LC, but the
>>> document needs to be updated to clarify that the updates of ISE
>>> documents are/will be done with permission of the ISE.  (Please also try
>>> to double-check that the list is complete; I didn't find an
>>> authoritative list of "all documents on the ISE stream" to grep against,
>>> and I didn't try to have something parse rfc-index.xml to output such a
>>> list.
>>> 
>> 
>> OK, so you'd like a list added and that's not in your pull request, is that
>> right?  We'll figure it out. Thanks in advance with the coordination with
>> Adrian.
> 
> That's correct, this is not in my pull request (not least because that list
> of three documents is incomplete -- I sent a more-likely-complete list of 6
> documents in an off-list follow-up.
> https://www.rfc-editor.org/search/rfc_search_detail.php?stream_name=Independent=All
> will get a (presumably authoritative) list of ISE-stream documents, FWIW.

After going through the list I found six. Here’s some text that addresses the 
fact that will have permission from the ISE:
https://github.com/tlswg/oldversions-deprecate/pull/6

>>> Section 1.1
>>> 
>>> I went through all 83 of the references in the big list, that are
>>> supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0,
>>> as well as the shorter list of already-obsoleted documents.
>>> 
>>> I won't bore you with my full notes, but there are some particular
>>> things that stood out from the review:
>>> 
>>> - We have a separate list of updates for documents that are already
>>>  obsolete (but don't say much about why we're going go the extra
>>>  bother).  However, three of the documents in our main list of updates
>>>  (4743, 4744, and 6460) are already Historic, and presumably should be
>>>  treated more like the already-obsolete ones.
>>> 
>> 
>> Obsolete does not mean the same thing as deprecate though.  TLSv1.2 has
>> been obsoleted by TLSv1.3, but not deprecated.  The deprecation goes the
>> extra step to say not to use it and it triggers many to begin phase out
>> plans.  Am I misunderstanding the question?
> 
> I think you're misunderstanding the question, yes, sorry.
> 
> I think we want the documents that are Historic to be listed separately
> from the other ("regular") updates, in a manner akin to what is already
> done for the documents that are currently obsolete.  Or, perhaps, to say
> that there is no point in deprecating something that is already historic,
> and not bother updating those three documents, but it seems okay to keep
> the current status with a comprehensive list of updates.

How about this:
https://github.com/tlswg/oldversions-deprecate/pull/7

spt


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

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Benjamin Kaduk]

Hi Kathleen,

Also inline.

On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
> Hi Ben,
> 
> Thanks for your review.  Some initial responses are inline.
> 
> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:
> 
> > Thanks for putting together the -06 based on my preliminary comments, and
> > my apologies for taking so long to get back to it.  It turns out that going
> > through the 80-odd documents we update takes a while!
> >
> >
> > I have a bunch of suggestions that are basically editorial, that I'll
> > make a pull request for (along with suggested changes for several of the
> > following comments).  It's up at:
> > https://github.com/tlswg/oldversions-deprecate/pull/3
> 
> 
> Thanks for that!
> 
> >
> >
> > We mention in the Abstract (but not Introduction!) that this document
> > moves 2246 and 4346 (but not 6347!) to the historic state.
> > Unfortunately, this is slightly problematic from a process perspective,
> > since the current way to make things Historic
> > (
> > https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20
> > )
> > requires a separate "status change document" that gets its own IETF LC,
> > to effectuate the status change.  Most references to the status change
> > document can be replaced by this RFC after it's published, but formally
> > the move to historic is *not* done by this document.  I've pulled into
> > my pull request the language used in RFC 8429 to describe moves to
> > Historic; please make sure to reproduce that language in the
> > Introduction as well as the Abstract.
> >
> 
> Do you need us to submit a draft to request that status change?

No -- it's done purely in the datatracker without an I-D, so I will plan to
do that.  (Unfortunately, it has to be one status-change document per
status-change, so it'll be a lot of clicking for me, but that's life.)

> >
> > I found three documents (3656, 4540, 7562) in the list of update targets
> > that are on the ISE (not IETF) stream.  I had talked to Adrian during my
> > preliminary review, and in principle it is permissible to make those
> > updates as part of this document, but we will need specific ISE approval
> > to do so.  I am supposed to sync up with him during IETF LC, but the
> > document needs to be updated to clarify that the updates of ISE
> > documents are/will be done with permission of the ISE.  (Please also try
> > to double-check that the list is complete; I didn't find an
> > authoritative list of "all documents on the ISE stream" to grep against,
> > and I didn't try to have something parse rfc-index.xml to output such a
> > list.
> >
> 
> OK, so you'd like a list added and that's not in your pull request, is that
> right?  We'll figure it out. Thanks in advance with the coordination with
> Adrian.

That's correct, this is not in my pull request (not least because that list
of three documents is incomplete -- I sent a more-likely-complete list of 6
documents in an off-list follow-up.
https://www.rfc-editor.org/search/rfc_search_detail.php?stream_name=Independent=All
will get a (presumably authoritative) list of ISE-stream documents, FWIW.

> 
> >
> > I note that in addition to our BCP 195 update (called out in Section 6),
> > we also update 3552, which is BCP 72.  This update is quite incidental
> > (compared to our BCP 195 update), so it seems clear that having this
> > document be part of BCP 195 is correct.
> >
> 
> Are you asking here to include an update to RFC3552?   Thanks.

No change needed here, I think -- just noting that we already list RFC 3552
as being updated, but that we don't need to be part of BCP 72, since the
update in question is largely incidental.

> >
> > Section 1.1
> >
> > I went through all 83 of the references in the big list, that are
> > supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0,
> > as well as the shorter list of already-obsoleted documents.
> >
> > I won't bore you with my full notes, but there are some particular
> > things that stood out from the review:
> >
> > - We have a separate list of updates for documents that are already
> >   obsolete (but don't say much about why we're going go the extra
> >   bother).  However, three of the documents in our main list of updates
> >   (4743, 4744, and 6460) are already Historic, and presumably should be
> >   treated more like the already-obsolete ones.
> >
> 
> Obsolete does not mean the same thing as deprecate though.  TLSv1.2 has
> been obsoleted by TLSv1.3, but not deprecated.  The deprecation goes the
> extra step to say not to use it and it triggers many to begin phase out
> plans.  Am I misunderstanding the question?

I think you're misunderstanding the question, yes, sorry.

I think we want the documents that are Historic to be listed separately
from the other ("regular") updates, in a manner akin to what is already
done for the documents that are currently obsolete.  Or, perhaps, to say
that there is no point in deprecating something that 

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Kathleen Moriarty]

Hi Ben,

Thanks for your review.  Some initial responses are inline.

On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:

> Thanks for putting together the -06 based on my preliminary comments, and
> my apologies for taking so long to get back to it.  It turns out that going
> through the 80-odd documents we update takes a while!
>
>
> I have a bunch of suggestions that are basically editorial, that I'll
> make a pull request for (along with suggested changes for several of the
> following comments).  It's up at:
> https://github.com/tlswg/oldversions-deprecate/pull/3


Thanks for that!

>
>
> We mention in the Abstract (but not Introduction!) that this document
> moves 2246 and 4346 (but not 6347!) to the historic state.
> Unfortunately, this is slightly problematic from a process perspective,
> since the current way to make things Historic
> (
> https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20
> )
> requires a separate "status change document" that gets its own IETF LC,
> to effectuate the status change.  Most references to the status change
> document can be replaced by this RFC after it's published, but formally
> the move to historic is *not* done by this document.  I've pulled into
> my pull request the language used in RFC 8429 to describe moves to
> Historic; please make sure to reproduce that language in the
> Introduction as well as the Abstract.
>

Do you need us to submit a draft to request that status change?

>
> I found three documents (3656, 4540, 7562) in the list of update targets
> that are on the ISE (not IETF) stream.  I had talked to Adrian during my
> preliminary review, and in principle it is permissible to make those
> updates as part of this document, but we will need specific ISE approval
> to do so.  I am supposed to sync up with him during IETF LC, but the
> document needs to be updated to clarify that the updates of ISE
> documents are/will be done with permission of the ISE.  (Please also try
> to double-check that the list is complete; I didn't find an
> authoritative list of "all documents on the ISE stream" to grep against,
> and I didn't try to have something parse rfc-index.xml to output such a
> list.
>

OK, so you'd like a list added and that's not in your pull request, is that
right?  We'll figure it out. Thanks in advance with the coordination with
Adrian.


>
> I note that in addition to our BCP 195 update (called out in Section 6),
> we also update 3552, which is BCP 72.  This update is quite incidental
> (compared to our BCP 195 update), so it seems clear that having this
> document be part of BCP 195 is correct.
>

Are you asking here to include an update to RFC3552?   Thanks.

>
> Section 1.1
>
> I went through all 83 of the references in the big list, that are
> supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0,
> as well as the shorter list of already-obsoleted documents.
>
> I won't bore you with my full notes, but there are some particular
> things that stood out from the review:
>
> - We have a separate list of updates for documents that are already
>   obsolete (but don't say much about why we're going go the extra
>   bother).  However, three of the documents in our main list of updates
>   (4743, 4744, and 6460) are already Historic, and presumably should be
>   treated more like the already-obsolete ones.
>

Obsolete does not mean the same thing as deprecate though.  TLSv1.2 has
been obsoleted by TLSv1.3, but not deprecated.  The deprecation goes the
extra step to say not to use it and it triggers many to begin phase out
plans.  Am I misunderstanding the question?


>
> - Several documents (e.g., 8261, 5023) specifically have MUST-level
>   requirements for 1.0 (or 1.1) that disappear or become internally
>   inconsistent with our current update, so we might want to fill that
>   void.
>

I'm not sure what you mean here.  This draft will update the ones listed.
RFC8261 just has the following:
"The DTLS implementation MUST support DTLS 1.0 [RFC4347
] and SHOULD

   support the most recently published version of DTLS, which was DTLS

   1.2 [RFC6347 ] when this RFC was
published. "

This deprecates DTLS1.0.  Are you asking for us to add a MUST support
DTLS1.2?

For RFC5023, there's the following text:
"At a minimum, client and server

   implementations MUST be capable of being configured to use HTTP Basic
   Authentication [RFC2617 ] in
conjunction with a connection made with
   TLS 1.0 [RFC2246 ] or a
subsequent standards-track version of TLS
   (such as [RFC4346 ]),
supporting the conventions for using HTTP over

   TLS described in [RFC2818 ]."

This requires a lot of updates, but in terms of the text for TLS as it
pertains to this draft, there's already text that says