Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
+1 to Tim - tell the reader explicitly that they will only ever get PQC w/ TLS 1.3 or higher. Cheers, - Ira On Thu, Dec 21, 2023, 12:34 PM Tim Hollebeek wrote: > I personally think this point is important enough to be made explicitly > instead of implicitly. > > > > If we want to communicate loudly and clearly that post-quantum > cryptography is NEVER coming to TLS 1.2, we need to explicitly say that. > > > > Otherwise people will say “I know you said TLS 1.2 was frozen, but > post-quantum cryptography isn’t a feature, it’s a critical security > vulnerability that needs to be patched regardless of any freezes.” > > > > The answer will be and needs to be: “No, we told you clearly and > explicitly that post-quantum cryptography would require moving to TLS 1.3 > or later”. > > > > -Tim > > > > *From:* TLS *On Behalf Of *Hannes Tschofenig > *Sent:* Monday, December 11, 2023 12:06 PM > *To:* Salz, Rich ; Hannes Tschofenig > ; Bas Westerbaan 40cloudflare@dmarc.ietf.org>; Deirdre Connolly < > durumcrustu...@gmail.com> > *Cc:* TLS@ietf.org > *Subject:* Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze' > > > > Hi Rich, > > > > that is implied by a "feature freeze". No reason to highlight PQC (even > though it is a hype topic right now). > > > > Ciao > > Hannes > > > > Am 11.12.2023 um 17:18 schrieb Salz, Rich: > > 1. I consider Section 3 "Implications for post-quantum > cryptography" misplaced. I suggest to delete the section > > 2. The motivation for the draft is unrelated to developments with > PQC. > > The point is to explain to people that we are going to need PQ crypto, and > it **will not be a 1.2 enhancement** > > > > > > ___ > > 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
Hi, Approve. Cheers, - Ira On Wed, Nov 29, 2023 at 10:51 AM Joseph Salowey wrote: > RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an > External Pre-Shared Key) was originally published as experimental due to > lack of implementations. As part of implementation work for the EMU > workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is > ongoing implementation work. Since the implementation status of RFC 8773 is > changing, this is a consensus call to move RFC 8773 to standards track as > reflected in [RFC8773bis]( > https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will also > help avoid downref for the EMU draft. Please indicate if you approve of or > object to this transition to standards track status by December 15, 2023. > > Thanks, > > Joe, Sean, and Deirdre > ___ > 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] consensus call: deprecate all FFDHE cipher suites
Hi, Yes - I support deprecating all FFDHE cipher suites including well-known groups. Cheers, - Ira On Tue, Dec 13, 2022 at 9:46 AM Sean Turner wrote: > During the tls@IETF 115 session topic covering > draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there > was support to deprecate all FFDHE cipher suites including well-known > groups. This message starts the process to judge whether there is consensus > to deprecate all FFDHE cipher suites including those well-known groups. > Please indicate whether you do or do not support deprecation of FFDHE > cipher suites by 2359UTC on 6 January 2023. If do not support deprecation, > please indicate why. > > NOTE: We had an earlier consensus call on this topic when adopting > draft-ietd-tls-deprecate-obsolete-kex, but the results were inconclusive. > If necessary, we will start consensus calls on other issues in separate > threads. > > Cheers, > Chris, Joe, and Sean > ___ > 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] Draft TLS Extension for Path Validation
Hi Ashley,
Bear in mind that DTLS 1.3 languished in the RFC Editor's queue for over a
year.
The major TLS libraries have had implementations and have been doing
interop testing
for a long time. Simply doing software update to current library versions
would make
DTLS 1.3 available in civil aviation.
FWIW - The Common Criteria standard workgroup for Network Devices (routers,
switches,
etc.) has approved the mandatory requirement for DTLS 1.3 in their next
version (draft in
July 2022 for publication in fall 2022).
Cheers,
- Ira
On Tue, May 31, 2022 at 12:32 PM Ashley Kopman
wrote:
> Eric,
>
> Thank you for your comments.
>
> My initial concern with limiting this to (D)TLS 1.3 was that the DTLS 1.3
> RFC has just been released and support is not yet widely available.
> However, our use case is for civil aviation and it will take time for the
> community begin using it. By that time there should be sufficient support
> for DTLS 1.3. I believe it is possible to limit this to (D)TLS 1.3. I will
> make the update to the draft.
>
> Thank you,
>
> Ashley
>
>
> On May 28, 2022, at 5:27 PM, Eric Rescorla wrote:
>
> I took a quick look at this draft. A few comments follow.
>
>
> VENUE
> The correct venue for this work is the TLS WG. This is a relatively
> straightforward piece of work that is clearly within the TLS WG's
> charter scope ("This includes extensions or changes that help
> protocols better use TLS as an authenticated key exchange protocol").
> To that end, I don't think we need a BOF or SECDISPATCH. I would
> encourage you to ask for TLS WG time in PHL.
>
>
> TECHNICAL
> In general, we are trying to avoid extending (D)TLS 1.2, so it would
> be good if we could limit this to (D)TLS 1.3. Is that possible?
>
> I realize that the certificate_status message extension includes a new
> message, but I think that's proven to be kind of an anti-pattern.
> If you are going to put this in (D)TLS 1.2, I would just put it in
> a ServerHello extension, which more closely parallels (D)TLS 1.3.
>
> If you use extensions, then you can register them with Specification
> Required, which would allow you to publish in the Independent Stream
> (or some other venue) to register the code points should the TLS
> WG choose not to take up this work.
>
> -Ekr
>
>
>
> On Thu, May 26, 2022 at 4:53 PM Robert Moskowitz
> wrote:
>
>> This is the Aviation use case I mentioned in earlier mails.
>>
>> I will be submitting a BOF request tomorrow, performa.
>>
>> Of course it is for the ADs to decide if this is a standalone BOF or a
>> 20min slot in SECDISPATCH.
>>
>> How much time people want to discuss it is in large measure related to
>> the discussion we engender here.
>>
>> Thank you for your attention. And thank you for reviewing and making
>> this a solid design that we can get deployed for avaiation Air-to-ground
>> and any similar use case.
>>
>> Bob
>>
>> On 5/26/22 19:43, Ashley Kopman wrote:
>>
>>
>> The use case for the D(TLS) Path Validation extension in civil aviation
>> has been submitted
>> https://www.ietf.org/archive/id/draft-segers-tls-cert-val-ext-use-case-00.txt
>> there
>> is also referenced slide deck available
>> http://conceptsbeyond.com/resources/SCVPValidationRequest_UseCase_CB.pdf
>>
>> Thank you,
>> Ashley Kopman
>>
>> On May 26, 2022, at 8:36 AM, Ashley Kopman
>> wrote:
>>
>> Ilari,
>>
>> Thank you for your feedback.
>>
>> You are correct in assuming that this was designed after the OCSP
>> status_request extension. It is a valid point that the extension can likely
>> be omitted from the server hello. The intent was to communicate to the
>> client that the server supports the extension and will respond with the
>> path validation information. However, since it is allowed for the server to
>> respond with the extension and then not supply the path validation, it is
>> not very useful overhead. I will remove the extension from the server hello.
>>
>> You are also correct that sending the certificate chain becomes
>> unnecessary. It was my intent to communicate that, but looking back at the
>> draft, I don’t think I made it clear. I will add it.
>>
>> Thank you,
>>
>> Ashley
>>
>>
>> On May 25, 2022, at 2:23 PM, Ilari Liusvaara
>> wrote:
>>
>> On Wed, May 25, 2022 at 12:40:13PM -0400, Ashley Kopman wrote:
>>
>> Hi TLS,
>>
>> I have just submitted a draft TLS Extension for Path Validation
>>
>> https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt
>> <
>> https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt
>> >
>>
>> The proposal is for a Path Validation Extension to provide a new
>> protocol for TLS/DTLS allowing inclusion of certificate path
>> validation information in the TLS/DTLS handshake. Specifically, it
>> covers the use of Server-based Certificate Validation Protocol
>> (SCVP) for path validation.
>>
>>
>> Looking at how this is integrated to (D)TLS:
>>
>>
>> For (D)TLS 1.2, the server extension does not seem to be technically
>> necressary, and
Re: [TLS] TLS Flags and IANA registration policy
Hi Eric, I agree. Let's get the semantics right. You mentioned a 3-tuple w/ "Discouraged". Should that be "Deprecated" (for clarity)? On Fri, Oct 29, 2021 at 5:17 PM Eric Rescorla wrote: > Well, we certainly can change it in 8446-bis. > > My put here would be: let's get consensus on the *semantics* we want for > the various categories without worrying about the names (call them A, B, C, > etc.) and then we can name them after. > > -Ekr > > > On Fri, Oct 29, 2021 at 2:14 PM Ira McDonald > wrote: > >> Hi Eric, >> >> Thanks for the background. I still sympathize with Hannes' point that >> "Recommended" means "IETF Consensus". I have to explain this >> too often in the insular automotive industry. >> >> But I certainly wouldn't write an RFC to change the title of a single >> column in an IANA registry. I've been one of the Designated Experts >> for the IANA Internet Printing Protocol (IPP) registry for 20 years and >> we rename IANA fields as needed by a direct request to our IANA >> folks (after consensus in the IEEE-ISTO Printer Working Group IPP >> WG - successor to IETF IPP WG in the 1990s). >> >> Cheers, >> - Ira >> >> >> On Fri, Oct 29, 2021 at 3:18 PM Eric Rescorla wrote: >> >>> Previous discussion is on this issue: >>> https://github.com/tlswg/tls13-spec/issues/1214 >>> >>> On Fri, Oct 29, 2021 at 12:13 PM Salz, Rich wrote: >>> >>>> >>>>- I am actually not in favor of changing it to IETF Consensus. I >>>>think these have different meanings. >>>> >>>> >>>> >>>> To be clear, I wasn’t expressing an opinion on whether or not to do >>>> this, I was just showing folks how to start the change process. >>>> >>> ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Flags and IANA registration policy
Hi, I agree that the "Recommended" column in the IANA registry (which is frequently misunderstood) should just be renamed to "IETF Consensus". Obvious and self-explanatory. Cheers, - Ira On Tue, Oct 26, 2021 at 10:45 AM Hannes Tschofenig < hannes.tschofe...@arm.com> wrote: > Rich, this makes more sense. Maybe the column should say "IETF Consensus" > (Y/N) instead of Recommended. > > In any case, the draft should say what recommended means for the flags > values. > > -Original Message- > From: TLS On Behalf Of Salz, Rich > Sent: Tuesday, October 26, 2021 3:19 PM > To: Ilari Liusvaara ; IETF TLS > Subject: Re: [TLS] TLS Flags and IANA registration policy > > The Recommended column is "was this done via IETF consensus." Some of the > values you think are odd are from pre-1.3, done by consensus, even if the > protocol is now outdated by 1.3 > > If there are some 1.0 and 1.1 extensions that are not defined in 1.2, then > that deprecation draft should suggest IANA changes. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ___ > 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] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites
Hi, I agree with Bill. Keeping confidentiality in all TLS/1.3 connections is future proofing. Supposedly analyzing and then leaving confidentiality out invites future attacks. Cheers, - Ira On Thu, Feb 11, 2021 at 9:56 AM Bill Frantz wrote: > On 2/11/21 at 9:01 PM, rsalz=40akamai@dmarc.ietf.org (Salz, > Rich) wrote: > > >>I would just like to recognize that there are some situations where it > isn't needed. > > > >Can you explain why TLS 1.2 isn't good enough for your needs? > > In my experience, there are many attacks that aren't anticipated > by the designers, but are successful. How can anyone know that > you don't need privacy? > > Back in the dark ages, I was working with a protocol which > provided the same basic assurances as TLS does: confidentiality, > authentication, and integrity. It and TlS also provide some > other important assurances, such a one-time, in order delivery, > which we also depended on. When we looked at a similar protocol > which didn't provide confidentiality, we discovered that there > was application level data that needed to be kept secret or the > application's assurances would be violated. > > In all honesty, it's probably cheaper to just provide > confidentiality than it is to do the analysis and protocol > proofs to show you don't need it. > > Cheers - Bill > > -- > Bill Frantz| There are now so many exceptions to the > 408-348-7900 | Fourth Amendment that it operates only by > www.pwpconsult.com | accident. - William Hugh Murray > > ___ > 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] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
I support Stephen and Uri and oppose adoption. On Mon, Jul 27, 2020 at 8:20 AM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > I support Stephen and oppose adoption. IMHO, this is not a technology that > IETF should standardize. > > > On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" < > tls-boun...@ietf.org on behalf of stephen.farr...@cs.tcd.ie> wrote: > > > I oppose adoption. While there could be some minor benefit > in documenting the uses and abuses seen when mitm'ing tls, > I doubt that the effort to ensure a balanced document is at > all worthwhile. The current draft is too far from what it'd > need to be to be adopted. > > Send to ISE. > > S. > > On 23/07/2020 02:30, Jen Linkova wrote: > > One thing to add here: the chairs would like to hear active and > > explicit support of the adoption. So please speak up if you believe > > the draft is useful and the WG shall work on getting it published. > > > > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > > wrote: > >> > >> Folks, > >> > >> > >> > >> This email begins a Call For Adoption on > draft-wang-opsec-tls-proxy-bp. > >> > >> > >> > >> Please send comments to op...@ietf.org by August 3, 2020. > >> > >> > >> > >> Ron > >> > >> > >> > >> > >> Juniper Business Use Only > >> > >> ___ > >> OPSEC mailing list > >> op...@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsec > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > ___ > > 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] adoption call for draft-dt-tls-external-psk-guidance
+1 for TLS WG adoption. Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmu...@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, May 21, 2020 at 10:12 PM Sean Turner wrote: > This is a WG document adoption call for draft-dt-tls-external-psk-guidance > (aka Guidance for External PSK Usage in TLS). This effort was kicked off > @IETF106 by Ben Kaduk and supported by others in the audience. There was > also some nominal amount of support for adopting the draft at the last > virtual interim though no formal adoption call was issued at the interim. > > If you support adopting this draft as a WG Document, then please send > email indicating your support to the list. If you have any comments or > reservations send them to the list too. > > This adoption call completes at 2359 UTC 5 June 2020. > > Cheers, > spt (for the chairs) > ___ > 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] IANA Considerations for draft-ietf-tls-dtls-connection-id
Hi, I strongly prefer option 3. The future-proofing and avoidance of a proliferation of new columns in the IANA registries is paramount. The points about QUIC highlight the near-term need to clean up this this issue. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmu...@gmail.com PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Jun 26, 2019 at 1:32 PM Sean Turner wrote: > While these IANA points are minor, what is being considered here affects > all TLS registries so please let us know what you think about the proposal > for the following issue: > > > Issue: > > The IANA DEs (Designated Experts) think that the registry should indicate > that the connection_id is DTLS-Only. This is the first extension defined > that would need this marking. Currently, there is no “DTLS-Only” column in > the TLS ExtensionType Values registry nor is there a "DTLS-OK" column like > there are in the TLS Parameter registries [0]. Note none of the TLS > extension registries [1] have a "DTLS-OK” column. > > > Proposals (there might be more): > > 0. Do nothing > > 1. Add a note to the top of the registry that says connection_id is > DTLS-Only > > 2. Add a DTLS-Only column to the TLS ExtensionType Values registry and > mark this one Y and all others N > > 3. Think about the future (inspired by Achiem in the GH repo): > > - Change the “DTLS-OK” column to "TLS/DTLS”. Allow values of TLS, DTLS, > or TLS/DTLS. > > - Mark all DTLS-OK=Y rows to “TLS/DTLS” and all DTLS-OK=N to “TLS”. [2] > > - Add “TLS/DTLS” column to the TLS ExtensionType Values registry and mark > the connection_id extension as “DTLS" and all others as “TLS/DTLS". > > > Selection: > > While option 3 is the most work it does kind of future proof the > registries and would make the columns the same in the parameter and > extensions registry groupings. > > > spt > > [0] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml > [1] > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml > [2] Most of the DTLS-OK=N are deprecated cipher suites, but a couple of > Exporter Labels are also marked as DTLS-OK=N. > > > On Jun 20, 2019, at 21:46, Sean Turner wrote: > > > > All, > > > > During the DE’s review of the assignments for > draft-ietf-tls-dtls-connection-id, they requested a new “DTLS Only” column > be added to the TLS ExtensionType Values registry. This connection_id would > be the only “Y” and all others there now would be “N”. > > > > The chairs also noted that the IANA considerations in > draft-ietf-tls-dtls-connection-id needs to specify values for all the > columns for connection_id in the TLS ExtensionType Values registry and > tls12_cid in the TLS ContentType registry. Here are the proposed values: > > > > connection_id > > TLS 1.3 column: “-“ it is not applicable to TLS 1..3 > > Recommended: “Y" > > > > tls12_cid > > DTLS-OK: “Y” > > > > This has been captured in the following PR: > > https://github.com/tlswg/dtls-conn-id/pull/67 > > > > Obviously, please comment. > > > > spt > > ___ > 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] WG adoption call: draft-moriarty-tls-oldversions-diediedie
I support adoption. - Ira On Fri, Aug 17, 2018 at 1:32 PM, Sean Turner wrote: > At the TLS@IETF102 session, there seemed to be some interest in adopting > draft-moriarty-tls-oldversions-diediedie as a WG item. This email is to > determine whether there is WG consensus to adopt this draft as a WG item. > If you would like for this draft to become a WG document and you are > willing to review it as it moves through the process, then please let the > list know by 2359UTC 20180831. If you are opposed to this being a WG > document, please say so (and say why). > > Note that we will suggest replacing “diediedie" with “deprecate" in the > adopted draft’s name to address the naming comment raised during the > meeting. > > Thanks, > Chris, Joe and Sean > ___ > 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] Confirming consensus: TLS1.3->TLS*
Hi, I think that the presumption that most tech people (or even security people) won't have any trouble with the future version numbering of TLS is wrong. Yesterday morning, on an SAE Vehicle Electrical Systems Security call with some 40 auto security professionals present, I mentioned that TLS 1.3 was wrapping up and was asked "What's TLS?" Usual explanation about SSL being succeeded by IETF TLS 17 years ago. Several responses that were the equivalent of blank stares. And finally, "Then why is the library still called OpenSSL?" Rich has highlighted that the tech community goes right on conflating SSL with TLS on web sites. I change my two cents to "TLS 4" but am unsure about "4" or "4.0" because the tech community has been trained to care about major.minor. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmu...@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Sat, Nov 19, 2016 at 6:32 AM, Jeffrey Walton <noloa...@gmail.com> wrote: > On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner <s...@sn3rd.com> wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG > should rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-rebranding-aka-pr612-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to > not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this > decision on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. > > Please forgive my ignorance... > > Who are you targeting for the versioning scheme? Regular users? Mom > and pop shops with a web presence? Tech guys and gals? Security folks? > > For most tech people and security folks, I don't think it matters > much. However, how many regular users would have clung to SSLv3 and > TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and > TLS 1999 (given TLS 2008 or TLS 2010 was available)? > > (Sorry to violate the Hum restriction). > > Jeff > > ___ > 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] [Cfrg] 3DES diediedie
Hi Dave, Might work for lightbulbs. Doesn't work for automotive sensors and ECUs, which already have proprietary security (undisclosed algorithms) and badly need to have standards-based security. Cents in cost really matter here. ARM CPUs are not and will not become the only answer in automotive. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmu...@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Sep 6, 2016 at 8:17 PM, Dave Garrett <davemgarr...@gmail.com> wrote: > On Tuesday, September 06, 2016 04:40:30 pm Derek Atkins wrote: > > Ben Laurie <b...@google.com> writes: > > > An ARM is far too much hardware to throw at "read sensor/munge > data/send > > > data". > > > > > > The question is not "how much hardware?" but "price?" - with ARMs > including h > > > /w AES coming in at $2 for a single unit, its hard to explain why > you\d want > > > to use a less powerful CPU... > > > > Because this is a light bulb that sells for $6-10. Adding $2 to the > price > > is just completely unreasonable. The price point needs to be pennies. > > Note that this is just one example, but yes, these level of products are > > getting "smarter" and we, as security professionals, should encourage > > "as strong security as possble" without getting the manufacturers to > > just say "sorry, too expensive, I'll go without." (which is, > > unfortunately, exactly what's been happening) > > Personally, I'd just say "stop putting chips in light bulbs", instead. > Companies making these things are unfortunately just not going to be making > good security decisions. Bad or no security is cheaper than competent > security, and selling light bulbs with bad security is not illegal. We'll > be more successful focusing our effort on dealing with light bulb botnets > than trying to get people to make secure "smart" light bulbs. There is no > good solution on our end, and debating the price of chips for light bulbs > is not a good way to make security decisions in TLS. > > > Dave > > ___ > 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] [Cfrg] 3DES diediedie
Hi, This survey of TLS in 1 million web servers shows that 93% support 3DES - oof! https://jve.linuxwall.info/blog/index.php?post/TLS_Survey 3DES hasn't quite disappeared on the Internet. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmu...@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Aug 25, 2016 at 9:33 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Thu, Aug 25, 2016 at 6:21 AM, david wong <davidwong.cry...@gmail.com> > wrote: > >> I don't think a RFC deprecating them is a good idea: >> >> * TLS 1.3 is almost here and is already doing that >> * what browser still use 64-bit ciphers? Who lets his "old" browser open >> for 75 hours? >> > > Actually, I believe that all the major browsers support 3DES. > > -Ekr > > * in other uses of TLS. It's not always obvious if there is a possible >> beast style attacks. And their implementation might really well not be >> vulnerable (due to limiting number of messages according to specs) >> >> David >> ___ >> Cfrg mailing list >> c...@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > > > ___ > Cfrg mailing list > c...@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
