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

[Kathleen Moriarty]

Hi Eliot,

Thanks for raising your concern.  I’ll note that I first started working on 
this because a well deployed library already had plans to drop support for 
versions 1.0 and 1.1 in their next release.  Customers that wanted those 
versions would have to use a prior library. This history may help.

Best regards,
Kathleen 

Sent from my mobile device

> On Nov 28, 2020, at 10:26 AM, Stephen Farrell  
> wrote:
> 
> 
> Hi Eliot,
> 
>> On 28/11/2020 10:45, Eliot Lear wrote:
>> Hi there IESG
>> I support the intent of this document, and I think the approach to
>> update the various documents listed is the right one.
> 
> Cool.
> 
>> Because of the breadth of documents updated, I wonder if at least
>> some implementation guidance is warranted, in order to assist
>> developers and even perhaps administrators.  Perhaps in some cases
>> these are compile-time or even run time options.  I’d suggest
>> guidance for common libraries, such as Microsoft .NET, OpenSSL,
>> GNUTLS, and WolfSSL. Better to give that guidance to get people to
>> TLS 1.3 rather than 1.2, of course.  Even informational references
>> would be fine, as assuredly some of this guidance exists.
> 
> Text welcomed of course, but I think it's mostly a case of
> doing the s/w update for the library and then either waiting
> 'till the library developer defaults to TLSv1.2 or better, or
> else various config file or API options that don't differ
> that much from library to library. I can check it out before
> we're done (again, text welcome if someone else wants to do
> that), but not sure it'll be that useful in the end TBH.
> (I'll get back when I get to doing that.)
> 
> Cheers,
> S.
> 
>> Thanks,
>> Eliot
 On 9 Nov 2020, at 23:26, The IESG  wrote:
>>> The IESG has received a request from the Transport Layer Security
>>> WG (tls) to consider the following document: - 'Deprecating TLSv1.0
>>> and TLSv1.1'  as Best
>>> Current Practice
>>> The IESG plans to make a decision in the next few weeks, and
>>> solicits final comments on this action. Please send substantive
>>> comments to the last-c...@ietf.org mailing lists by 2020-11-30.
>>> Exceptionally, comments may be sent to i...@ietf.org instead. In
>>> either case, please retain the beginning of the Subject line to
>>> allow automated sorting.
>>> 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 (RFC6347), 
>>> 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 file can be obtained via 
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
>>> 
>>> 
>>> 
>>> 
> No IPR declarations have been submitted directly on this I-D.
>>> The document contains these normative downward references. See RFC
>>> 3967 for additional information: rfc5024: ODETTE File Transfer
>>> Protocol 2.0 (Informational - Independent Submission Editor
>>> stream) rfc5024: ODETTE File Transfer Protocol 2.0 (Informational -
>>> Independent Submission Editor stream) rfc5023: The Atom Publishing
>>> Protocol (Proposed Standard - IETF stream) rfc5019: The Lightweight
>>> Online Certificate Status Protocol (OCSP) Profile for High-Volume
>>> Environments (Proposed Standard - IETF stream) rfc5019: The
>>> Lightweight Online Certificate Status Protocol (OCSP) Profile for
>>> High-Volume Environments (Proposed Standard - IETF stream) rfc5018:
>>> Connection Establishment in the Binary Floor Control Protocol
>>> (BFCP) (Proposed Standard - IETF stream) rfc4992: XML Pipelining
>>> with Chunks for the Internet Registry Information Service (Proposed
>>> Standard - IETF stream) rfc4992: XML Pipelining with Chunks for the
>>> Internet Registry Information Service (Proposed Standard - IETF
>>> stream) rfc4976: Relay Extensions for the Message Sessions Relay
>>> Protocol (MSRP) (Proposed Standard - IETF stream) rfc4975: The
>>> Message Session Relay Protocol (MSRP) (Proposed Standard - IETF
>>> stream) rfc4975: The Message Session Relay Protocol (MSRP)
>>> (Proposed Standard - IETF stream) 

Re: [Emu] Eric Rescorla's Yes on charter-ietf-emu-04-01: (with COMMENT)

[Kathleen Moriarty]

Hi Eric,

On Wed, Feb 21, 2018 at 11:55 PM, Eric Rescorla  wrote:
> Eric Rescorla has entered the following ballot position for
> charter-ietf-emu-04-01: 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.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-emu/
>
>
>
> --
> COMMENT:
> --
>
> LGTM with some nits below:
>
>
>  - Provide a guidance or update to enable the use of TLS 1.3 in the
>context of EAP TLS (RFC 5216). Update the security
>considerations relating to EAP TLS, to document the implications
>of using new vs. old TLS version, any recently gained new
>
> Nit: versions
>
>   In all of the above, it is a requirement that none of the updates
>   break backwards compatibility with existing specifications or
>   implementations. The current EAP-TLS RFCs shall not be obsoleted but
>
> s/shall/will/?
>
>   rather updated with either new information or instructions on
>   what is needed, for instance, to employ a new TLS version.
>
>

The suggested changes have been made, thank you.


-- 

Best regards,
Kathleen

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Mirja Kühlewind's No Objection on charter-ietf-emu-04-00: (with COMMENT)

[Kathleen Moriarty]

Mirja,

The milestones have been updated per the dates and language provided by Jari.

Thanks,
Kathleen

On Mon, Feb 19, 2018 at 11:36 AM, Mirja Kuehlewind (IETF)
 wrote:
> Yes. I don’t see a big difference between „WGLC" and "send to IESG“ but it’s 
> good to have a deadline!
>
>> Am 18.02.2018 um 12:48 schrieb Jari Arkko :
>>
>> Mirja,
>>
>>> I would actually rather like to see milestones for when the work is 
>>> supposed to
>>> be finished (send to IESG for publication) than when it is supposed to start
>>> (wg adoption) as the first is probably harder to achieve in time than the
>>> second.
>>
>> I suggested edits to the milestones in a response to Kathleen’s
>> comments, and the suggested edits include having both start
>> (adopt) and end (WGLC) for all work items. Does that work for
>> you?
>>
>> (Although some of our charters speak about WGLC and others
>> about sending to IESG… not sure the difference matters.)
>>
>> Jari
>>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu



-- 

Best regards,
Kathleen

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Kathleen Moriarty's Yes on charter-ietf-emu-04-00: (with COMMENT)

[Kathleen Moriarty]

Thank you, Jari.  The milestones have been updated.

Best regards,
Kathleen

On Sun, Feb 18, 2018 at 6:25 AM, Jari Arkko  wrote:
> Mohit, Kathleen,
>
> I’d suggest editing the current milestones as follows. The edit and schedule
> suggestions are based in part on what I think the 3GPP schedules are going
> to be. They need some stuff soon (e.g., any fixes to existing EAP-AKA’;
> there’s a technical specification with a few paragraphs labeled “move these
> to IETF RFC when it is updated) but some of the other things (EAP TLS 1.3,
> PFS solutions) can probably wait until their 5G phase 2 work.
>
> Then again, for the sake of resolving issues in existing RFCs and
> general issues in EAP usage, we also want to pursue the other stuff.
>
> These are however my suggestions only; others may see priorities and
> order differently. So consider this proposal as a straw-man only.
>
> OLD:
>
>  Apr 2018 - WG adopts initial draft on guidance for EAP TLS with TLS 1.3
>  Apr 2018 - Begin work on EAP-AKA update, RFC5448-bis
>  May 2018 - Adopt draft for extension to EAP-AKA to support forward secrecy
>  Jul 2018 - Adopt draft to define session identifiers for fast
>  re-authentication for EAP-SIM, EAP-AKA, and EAP-AKA
>  Jul 2018 - Adopt draft on operational recommendations for large certificate
>  and chain sizes
>  Feb 2019 - Working group last call for EAP-AKA update, RFC5448-bis
>
> NEW:
>
>  Mar 2018 - WG established
>  Apr 2018 - WG adopts initial draft on guidance for EAP TLS with TLS 1.3
>  Apr 2018 - WG adopts initial draft on EAP-AKA update, RFC5448-bis,
>  including definition session identifiers for fast re-authentication for 
> EAP-AKA'
>  Sep 2018 - WG last call on EAP-AKA update, RFC5448-bis
>  Oct 2018 - WG adopts initial draft on extension to EAP-AKA to support 
> forward secrecy
>  Oct 2018 - WG adopts initial draft on definition of session identifiers for 
> fast
>  re-authentication in EAP-SIM and EAP-AKA
>  Nov 2018 - WG last call on guidance for EAP TLS with TLS 1.3
>  Dec 2018 - WG adopts initial draft on operational recommendations for large 
> certificate
>  and chain sizes
>  Jan 2019 - WG last call on definition of session identifiers for fast
>  re-authentication in EAP-SIM and EAP-AKA
>  Feb 2019 - WG last call on extension to EAP-AKA to support forward secrecy
>  May 2019 - WG last call on operational recommendations for large
>  certificate and chain sizes
>
> Jari
>



-- 

Best regards,
Kathleen

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Ben Campbell's No Objection on charter-ietf-emu-04-00: (with COMMENT)

[Kathleen Moriarty]

Thank you Ben and Jari.  The updates will appear shortly int he new version.

Best regards,
Kathleen

On Sun, Feb 18, 2018 at 12:32 PM, Ben Campbell  wrote:
> Thanks, Jari, this all looks good to me.
>
> Ben.
>
>> On Feb 18, 2018, at 5:46 AM, Jari Arkko  wrote:
>>
>> Hi Ben,
>>
>> And thanks for your feedback.
>>
>>> First bullet point: "or other new concerns." makes this very open ended. Is
>>> this planned to be a standing working group? If not, can we put some
>>> constraints around "other new concerns”?
>>
>> Understood.
>>
>> Note that the sentence starts with “Update the security considerations…”
>> so the goal of these updates is about discovering new vulnerabilities and
>> the like; not any random other concerns. That being said, the text already
>> covers new vulnerabilities, so may be this is merely unnecessary text.
>>
>> How about the following text:
>>
>> OLD:
>>Update the security
>>considerations relating to EAP TLS, to document the implications
>>of using new vs. old TLS version, any recently gained new
>>knowledge on vulnerabilities, and the possible implications of
>>pervasive survellaince or other new concerns.
>>
>> NEW:
>>
>>Update the security
>>considerations relating to EAP TLS, to document the implications
>>of using new vs. old TLS version, any recently gained new
>>knowledge on vulnerabilities, and the possible implications of
>>pervasive surveillance.
>>
>> (Also updates a typo.)
>>
>>> The prohibition against obsoleting RFCs seems harsh. It's possible to 
>>> require
>>> backwards compatibility without this restriction. I think it should be up to
>>> the working group to decide whether work can be better organized using 
>>> updates
>>> or bis-drafts.
>>
>> There was a detailed discussion among the participants about this aspect and
>> a reasonable, strong opinion that the current EAP-TLS RFC remain as
>> the primary, and that the new RFC would be an update to it when it comes
>> to TLS 1.3.
>>
>> That being said, hmm… even my own draft for EAP-AKA’ bis currently says
>> “Obseletes RFC 5448 (if approved”)… so… how about this:
>>
>> OLD:
>>
>> The current RFCs shall not be obsoleted but
>> rather updated with either new information or instructions on
>> what is needed, for instance, to employ a new TLS version.
>>
>> NEW:
>>
>> The current EAP-TLS RFCs shall not be obsoleted but
>> rather updated with either new information or instructions on
>> what is needed, for instance, to employ a new TLS version.
>>
>>> -3rd paragraph: "And the
>>> understanding of security threats in today's Internet evolves as
>>> well,..."
>>>
>>> I suggest dropping “And"
>>
>> Yes.
>>
>> For Kathleen’s benefit, listing this in OLD/NEW style:
>>
>> OLD:
>>
>> And the
>> understanding of security threats in today's Internet evolves as
>> well, which has driven some of the evolution in these underlying
>> technologies.
>>
>> NEW:
>>
>> The
>> understanding of security threats in today's Internet evolves as
>> well, which has driven some of the evolution in these underlying
>> technologies.
>>
>>> -- 2nd bullet: This is a bit hard to parse. I suggest:
>>>
>>> OLD:
>>>   Update the EAP-AKA' specification (RFC 5448) to ensure that its
>>>capability to provide a cryptographic binding to network context
>>>stays in sync with what updates may come to the referenced 3GPP
>>>specifications through the use of EAP in 5G.
>>> NEW:
>>>Update the EAP-AKA' specification (RFC 5448) to ensure that its
>>>capability to provide a cryptographic binding to network context
>>>stays in sync with any 5G related updates to the referenced 3GPP
>>>specifications.
>>
>> Seems good. Thanks.
>>
>>> Same bullet point: The second paragraph seems out of place; was it intended 
>>> to
>>> be its own bullet point?
>>
>> I don’t have a strong opinion, but the two somewhat separate issues
>> were listed under the same bullet item since both of them should
>> go into the same draft (rfc5448bis). The EAP TLS bullet item
>> does the same thing, i.e., update tech + describe new knowledge
>> of vulnerabilities.
>>
>>> 4th bullet point: The second sentence seems like a non-sequiter. I suggest a
>>> top-level bullet point for "Analyzing opportunities to improve privacy..."
>>
>> I’d be fine with that. Suggested text:
>>
>> OLD:
>>
>>  - Develop an extension to EAP-AKA' such that Perfect Forward Secrecy
>>can be provided. There may also be privacy improvements that
>>have become feasible with the introduction of recent identity
>>privacy improvements in 3GPP networks.
>>
>> NEW:
>>
>>  - Analysing opportunities to improve privacy in EAP-AKA’.
>>
>>Develop an extension to EAP-AKA' such that Perfect Forward Secrecy
>>can be provided.
>>
>>There may also be other privacy improvements that
>>have become feasible with the introduction of recent identity
>>privacy improvements in 3GPP networks.
>>
>> Jari
>>
>
>
> 

[Emu] Kathleen Moriarty's Yes on charter-ietf-emu-04-00: (with COMMENT)

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
charter-ietf-emu-04-00: 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.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-emu/



--
COMMENT:
--

Milestones are likely to change (dates, etc.), but aligns with the charter. 
Jari's time was limited, so I helped and he will adjust.


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [saag] Feedback on Salted EAP draft

[Kathleen Moriarty]

Hello,

Is there interest in reviewing this draft?  Sam pointed out the importance
of moving this work forward, it would be helpful to have volunteers to
review the work and also to understand the level of interest (if any)
before this goes forward as AD sponsored.

Thank you!

On Fri, Mar 27, 2015 at 1:34 PM, Sam Hartman hartmans-i...@mit.edu wrote:

  Kathleen == Kathleen Moriarty kathleen.moriarty.i...@gmail.com
 writes:

 KathleenI meant to send the link to Dan's draft:
 Kathleen https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-01
 Kathleen Long week...

 I have briefly reviewed the goals behind this proposal and a sketch of
 the details but have not done a technical review of the proposal.

 The underlying goal is important and valuable.
 This issue is the same issue that was behind my response to your AD
 review of the oauth dynamic registration draft.
 The more we can do to make it possible to use  deployed password
 databases with more modern security, the more we will be able to employ
 that modern security.

 However, take careful note of section 5 of the draft.

 Assuming that  you can get positive technical reviews of the proposal,
 this draft seems to solve an important problem that would be valuable to
 solve in the EAP community.




-- 

Best regards,
Kathleen
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Feedback on Salted EAP draft

[Kathleen Moriarty]

I meant to send the link to Dan's draft:
https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-01

Long week...

On Fri, Mar 27, 2015 at 1:17 PM, Kathleen Moriarty 
kathleen.moriarty.i...@gmail.com wrote:

 Hello,

 Dan Harkin's asked that I AD sponsor the following draft:
 https://www.iab.org/activities/workshops/caris/

 I'm considering it, reviews and opinions are welcome.

 Thank you.

 --

 Best regards,
 Kathleen




-- 

Best regards,
Kathleen
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Feedback on Salted EAP draft

[Kathleen Moriarty]

Hello,

Dan Harkin's asked that I AD sponsor the following draft:
https://www.iab.org/activities/workshops/caris/

I'm considering it, reviews and opinions are welcome.

Thank you.

-- 

Best regards,
Kathleen
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu