Re: [TLS] Use-case for non-AEAD ciphers in network monitoring

[Darin Pettis]

Thanks to Eric and Rich for your technical responses and cautionary
statements.

I do see that Florian’s use-case below points to the continued need for
enterprise inspection as once the data lands inside the data center they
become the custodians of it and are responsible for the security and
performance of the data.

I would like to ask the group to ameliorate the use case and challenge them
to come up with a way for enterprises to see the data internally while
keeping it safe externally.

TLS 1.3 did a great job regarding safety of data on the Internet. For the
next version, let’s focus on how to best meet this used case

On Mon, May 17, 2021 at 3:01 PM Eric Rescorla  wrote:

> Hi Florian,
>
> This suggestion comes up occasionally, and as Rich Salz says,
> you could just register your own cipher suite.
>
> With that said, I would make three comments:
>
> 1. I think it's a bit of a category error to talk about AEAD versus
> non-AEAD in this context. AEAD is just an interface, so it's possible
> to have AEAD algorithms that can have separate keys. For instance,
> consider AES-CTR with HMAC.
>
> 2. If you have to define a new cipher suite, than that will require
> changes on both sides, client and server.
>
> 3. It can be fairly hard to reason about the security properties of
> this kind of system. As a concrete example, one might imagine that
> having only the confidentiality key would allow one to inspect HTTP
> client requests but not to modify them. However, because much HTTP
> authentication is via cookies, as a practical matter being able to
> inspect an HTTP transcation is sufficient to impersonate the client to
> the server.
>
> -Ekr
>
>
>
> On Mon, May 17, 2021 at 9:25 AM Florian Wilkens <
> wilk...@informatik.uni-hamburg.de> wrote:
>
>> Hey folks,
>>
>> we came across a novel use-case that highlights the need for non-AEAD
>> ciphers in TLS and would like to start a discussion on that.
>>
>> Our use-case is passive TLS decryption on network monitors (NMs).
>> Non-AEAD ciphers would allow  to selectively forward the TLS write keys
>> from clients to a NM that can then passively decrypt TLS sessions,
>> without touching their integrity (as the write MAC keys remain on the
>> host). This would be a major improvement compared to the usage of MitM
>> proxies as current state of the art. MitM proxies terminate all TLS
>> connections and establish own connections. Thus, a compromised MitM
>> proxy cannot only decrypt all packets, but also change packet contents.
>>
>> We propose an approach for passive TLS decryption [1] in which
>> cooperating hosts selectively forward TLS keys to the NM that then
>> decrypts TLS sessions. The approach is (i) completely passive and thus
>> does not interfere with the overall connection security and (ii) is able
>> to selectively decrypt certain TLS connections with the hosts retaining
>> full authority over the key material. While a MitM proxy can also claim
>> to selectively decrypt traffic, we can guarantee this by keeping key
>> material for selected connections on the client. Furthermore, for
>> non-AEAD ciphers only the write keys, but not the write MAC keys, are
>> forwarded, so that the NM can inspect but not modify TLS packets.
>>
>> Our prototype is built for the Zeek network monitor [2] and is currently
>> in the process of being upstreamed with explicit interest from the
>> maintainers [3]. Once merged, this will be the first open-source
>> solution for passive TLS decryption on both client host (for which we
>> built a small prototype) and network monitor (Zeek).
>>
>> We understand that AEAD ciphers offer many advantages and we understand
>> the decision to limit the set of available ciphers to secure choices
>> only. However, we think the use-case of passive TLS decryption is highly
>> relevant especially for enterprise settings. In such settings, mainly
>> MitM proxies are used that are a security problem on their own.
>>
>> We look forward to your feedback.
>>
>> Best,
>> Florian
>>
>> [1] https://arxiv.org/abs/2104.09828
>> [2] https://zeek.org
>> [3] https://github.com/zeek/zeek/pull/1518
>>
>> --
>> M.Sc. Florian Wilkens
>> Research Associate
>> Phone: +49 40 42883 2353
>>
>> IT-Sicherheit und Sicherheitsmanagement (ISS)
>> Universität Hamburg
>> Fachbereich Informatik
>> Vogt-Kölln-Straße 30
>> 
>> 22527 Hamburg
>> 
>> Deutschland
>> 
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mail

Re: [TLS] Use-case for non-AEAD ciphers in network monitoring

[Darin Pettis]

…use case*

Thanks in advance,
Darin Pettis

On Mon, May 17, 2021 at 3:33 PM Darin Pettis 
wrote:

> Thanks to Eric and Rich for your technical responses and cautionary
> statements.
>
> I do see that Florian’s use-case below points to the continued need for
> enterprise inspection as once the data lands inside the data center they
> become the custodians of it and are responsible for the security and
> performance of the data.
>
> I would like to ask the group to ameliorate the use case and challenge
> them to come up with a way for enterprises to see the data internally while
> keeping it safe externally.
>
> TLS 1.3 did a great job regarding safety of data on the Internet. For the
> next version, let’s focus on how to best meet this used case
>
> On Mon, May 17, 2021 at 3:01 PM Eric Rescorla  wrote:
>
>> Hi Florian,
>>
>> This suggestion comes up occasionally, and as Rich Salz says,
>> you could just register your own cipher suite.
>>
>> With that said, I would make three comments:
>>
>> 1. I think it's a bit of a category error to talk about AEAD versus
>> non-AEAD in this context. AEAD is just an interface, so it's possible
>> to have AEAD algorithms that can have separate keys. For instance,
>> consider AES-CTR with HMAC.
>>
>> 2. If you have to define a new cipher suite, than that will require
>> changes on both sides, client and server.
>>
>> 3. It can be fairly hard to reason about the security properties of
>> this kind of system. As a concrete example, one might imagine that
>> having only the confidentiality key would allow one to inspect HTTP
>> client requests but not to modify them. However, because much HTTP
>> authentication is via cookies, as a practical matter being able to
>> inspect an HTTP transcation is sufficient to impersonate the client to
>> the server.
>>
>> -Ekr
>>
>>
>>
>> On Mon, May 17, 2021 at 9:25 AM Florian Wilkens <
>> wilk...@informatik.uni-hamburg.de> wrote:
>>
>>> Hey folks,
>>>
>>> we came across a novel use-case that highlights the need for non-AEAD
>>> ciphers in TLS and would like to start a discussion on that.
>>>
>>> Our use-case is passive TLS decryption on network monitors (NMs).
>>> Non-AEAD ciphers would allow  to selectively forward the TLS write keys
>>> from clients to a NM that can then passively decrypt TLS sessions,
>>> without touching their integrity (as the write MAC keys remain on the
>>> host). This would be a major improvement compared to the usage of MitM
>>> proxies as current state of the art. MitM proxies terminate all TLS
>>> connections and establish own connections. Thus, a compromised MitM
>>> proxy cannot only decrypt all packets, but also change packet contents.
>>>
>>> We propose an approach for passive TLS decryption [1] in which
>>> cooperating hosts selectively forward TLS keys to the NM that then
>>> decrypts TLS sessions. The approach is (i) completely passive and thus
>>> does not interfere with the overall connection security and (ii) is able
>>> to selectively decrypt certain TLS connections with the hosts retaining
>>> full authority over the key material. While a MitM proxy can also claim
>>> to selectively decrypt traffic, we can guarantee this by keeping key
>>> material for selected connections on the client. Furthermore, for
>>> non-AEAD ciphers only the write keys, but not the write MAC keys, are
>>> forwarded, so that the NM can inspect but not modify TLS packets.
>>>
>>> Our prototype is built for the Zeek network monitor [2] and is currently
>>> in the process of being upstreamed with explicit interest from the
>>> maintainers [3]. Once merged, this will be the first open-source
>>> solution for passive TLS decryption on both client host (for which we
>>> built a small prototype) and network monitor (Zeek).
>>>
>>> We understand that AEAD ciphers offer many advantages and we understand
>>> the decision to limit the set of available ciphers to secure choices
>>> only. However, we think the use-case of passive TLS decryption is highly
>>> relevant especially for enterprise settings. In such settings, mainly
>>> MitM proxies are used that are a security problem on their own.
>>>
>>> We look forward to your feedback.
>>>
>>> Best,
>>> Florian
>>>
>>> [1] https://arxiv.org/abs/2104.09828
>>> [2] https://zeek.org
>>> [3] https://github.com/zeek/zeek/pu

Re: [TLS] Use-case for non-AEAD ciphers in network monitoring

[Darin Pettis]

Hi Stephen,
Thanks for the quick reply as I know it is getting late in Ireland.

I’m sure you do remember the conversation as you spent a lot of time at the
microphone around it.  :-)

It is certainly not an easy question to answer but this group comprises the
smartest people that I know!!  Surely someone must be up for the challenge
as fully half of the people in that London hall voiced the need for it.
Furthermore, when the day comes that TLS 1.2 can’t be used anymore, for
whatever the reason, this need is going to come racing down the tracks…

So, while everyone is breathing easy right now, it would be great to
address the need proactively.

Respectfully,
Darin

On Mon, May 17, 2021 at 3:48 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 17/05/2021 21:33, Darin Pettis wrote:
> > TLS 1.3 did a great job regarding safety of data on the Internet. For the
> > next version, let’s focus on how to best meet this used case
>
> I think we had this discussion a few years ago. There is
> no sensible boundary at which TLS can apply different
> cryptographic treatment.
>
> There were also many many other points raised at that
> time that I don't think we'll benefit from repeating.
>
> Cheers,
> S.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI hangout

[Darin Pettis]

Sean - thank you for the update and options on rooms.

Ben and Brett - which room should we meet in?

Initially opposed to encrypting SNI as it appears to break many services
that utilize it but curious to hear more.   Thx

On Mon, Nov 13, 2017 at 9:17 AM Christian Huitema 
wrote:

> On 11/12/2017 4:54 PM, Sean Turner wrote:
>
> > Hi!  I applaud the initiative for suggesting the hangout [0].  Squatting
> in that room ought to be okay but in case the secretariat ends up
> scheduling another IETF session in that room the 12 person room
> (Butterworth) is still available during that time:
> >
> https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100sidemeetings2
> > It can be scheduled through the following link:
> > https://ietf.org/meeting/amreq.html
> >
> > Cheers,
> >
> > spt
> >
> > [0] For those more process oriented folks, Ben and Bret correctly
> identified this as a hangout.  it’s not a WG session that got canceled.
> >
>
> The SNI Encryption draft is maintained on the TLS WG Github, at
> https://github.com/tlswg/sniencryption. It would be really nice if after
> or during the discussions someone opened issues and possibly PR.
>
> Thanks, and sorry I could not join you in Singapore
>
> -- Christian Huitema
>
> ___
> 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] TLS@IETF101 Agenda Posted

[Darin Pettis]

Artyom,
Thanks for mentioning the ID and you are right that draft Fenter is the
supporting problem description.

The reason it was written was to help folks understand why legitimate
internal out-of-band decryption is still needed on data once it reaches its
destination and that there isn’t a viable alternative that we are aware of.
   Especially not in-line MitM decryption.  It just doesn’t scale.  The
draft lists the legitimate internal requirements and speaks to the facts
around some of the suggestions that have been offered.

 It’s a good read and we are happy to answer questions in advance as
needed.

Darin

On Thu, Mar 8, 2018 at 4:11 PM Artyom Gavrichenkov 
wrote:

> Hi Sean, Joe,
>
> WG also has this at its disposal:
> https://tools.ietf.org/html/draft-fenter-tls-decryption-00
> Will that be discussed along with draft-rhrd-tls-tls13-visibility?
> Those two seem to be rather connected/dependant on each other.
>
> | Artyom Gavrichenkov
> | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
> | mailto: xima...@gmail.com
> | fb: ximaera
> | telegram: xima_era
> | skype: xima_era
> | tel. no: +7 916 515 49 58
>
>
> On Thu, Mar 8, 2018 at 12:21 PM, Stephen Farrell
>  wrote:
> >
> > Hi Sean, Joe,
> >
> > On 08/03/18 16:20, Sean Turner wrote:
> >> I’ve posted the draft agendas:
> >>
> >> Monday:
> >>
> https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb
> >
> > That includes:
> > "
> > TLS Vizability - Russ & Chairs - 30min
> >  - 10min draft - Russ
> >   https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
> >  - 10min discussion - Chairs
> >  - 10min wrap-up - Chairs
> > "
> >
> > Consider this as an objection to that agenda item
> > being given any time. I also have some questions
> > below.
> >
> > This topic was discussed at length in Prague with a
> > very clear lack of consensus to consider any work in
> > that space, despite there being quite a few fans of
> > doing such work in the room that day. I don't see
> > that anything has changed in the meantime.
> >
> > Russ' draft was discussed on the list last year, also
> > with (ISTM) no consensus at all to do any work in
> > that space. (While you didn't make a consensus call,
> > am I wrong?) The -01 version is not significantly
> > different from what was discussed on the list so I
> > see no need for any presentation nor discussion time.
> >
> > Given the above, on what basis are meeting attendees
> > being asked to waste yet more f2f time on this topic?
> >
> > And why is another want-it/hate-it exercise useful?
> >
> > As chairs, are you going to continually allow the same
> > topic to be raised, in the face of a very clear lack
> > of consensus to do anything in this space? If not,
> > then what's the plan for ending this?
> >
> > Thanks,
> > S.
> >
> > PS: I also strongly object to the "visibility" euphemism,
> > and while that's partly a comment on the draft, it would
> > also IMO be a significant error to pose any questions to
> > the WG based on that euphemism.
> >
> >
> > ___
> > 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] TLS@IETF101 Agenda Posted

[Darin Pettis]

Richard Barnes and Rich Salz,
Thank you for the kind words.   They are much appreciated!  Best of luck to
Rich with the health concerns too.

It’s been an interesting journey with a lot of great folks.  Will reply to
the issues later as I need to head out at the moment.

-Darin


On Tue, Mar 13, 2018 at 2:20 PM nalini elkins 
wrote:

> All,
>
> The time has gotten away from me.   I have to leave for the airport. I am
> taking my daughter to London & need to get us all packed & out of the house.
>
> I will write respond to all at length either from the airport or in London.
>
> Rich, so sorry about your health issues.  My best wishes for a full and
> complete recovery.
>
> Nalini
>
> On Tue, Mar 13, 2018 at 10:39 AM, Salz, Rich  wrote:
>
>>
>>- I am happy to set up an informal session where all can meet and
>>talk quietly.   Not everyone will be there on Sunday but maybe Monday
>>breakfast or during a break?  Just let me know if you are interested & we
>>can make intros.
>>
>>
>>
>> I won’t be there (health issues), but I’ve already turned down such
>> private invites before.
>>
>>
>>
>> Standing up in front of a WG and talking about unpopular topics is hard.
>> As Richard said, kudo’s to USBank (and a BCBS org) for doing so.  But if
>> you’re not willing to do the hard work, then you don’t get to have the IETF
>> address your concerns.
>>
>>
>>
>> I remember saying before that I firmly believe that the main, and
>> unstated, reason for wanting an IETF RFC on this is so that would-be
>> customers can point to vendors and ask for a common solution at a lower
>> price because the ability is now commoditized.  With all due respect to the
>> people involved, I believe that is still the case.
>>
>>
>>
>> I have heard concerns that it is necessary to have a “speedy” solution.
>> Again, I strongly disagree with this. The standard organizations haven’t
>> even made TLS 1.0 illegal yet, as I said last time.  What makes you think
>> that something is needed in under five years?  I asked that question
>> before, too.
>>
>>
>>
>>
>>
>
>
>
> --
> Thanks,
> Nalini Elkins
> President
> Enterprise Data Center Operators
> www.e-dco.com
>
> ___
> 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] Breaking into TLS to protect customers

[Darin Pettis]

Agreed.   I know a lot of good work has gone into TLS 1.3 and having
visibility to the data once it hits the data center seems like a new
capability to the good folks working that have had TLS 1.3 in mind for the
last couple years.   But to enterprises, they have visibility to their data
today and have become dependent on that visibility to utilize security and
troubleshooting tools.

This actually speaks to the fact the there is a different use case for the
Internet vs the data center.  Hopefully we can agree on that point.

On the Internet, data is transitory in nature and the focus of E2E
security.   Conversely, when the enterprise is the actual recipient of the
data, there is an expectation of security and performance of that data.
 If anything happens to that data, then the enterprise is pointed to - so
we need to see the data to run the needed services.  Initially regulated
companies have been pushed to encrypt internally which then in-turn
requires that data must be decrypted for tools and a select group of folks
can provided the required services.

Additionally, bad actors will have the ability to utilize TLS 1.3
decryption for command and control and data exfiltration purposes.
Security services need to see the data to combat that.

Finally, I wanted to make the clear that we utilize the term "visibility"
because it is the correct term for the outcome that is needed - regardless
of the technology solution that enables it.  Not to inflame anyone at all.
I know it's a contentious issue but appreciate everyone's input and
thoughts to come to a solution as pushing this to another technology or WG
isn't going to solve the current problem in time.  Kuddo's to EDCO for
sharing in both directions.

Thanks,
Darin

On Thu, Mar 15, 2018 at 2:50 PM, Ackermann, Michael 
wrote:

> Good point Yoav.
>
>
>
> And this positive side effect holds true in the health care and insurance
> industries as well,  and is not an accident.  It is one of the primary
> reasons this monitoring is performed.
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Yoav Nir
> *Sent:* Thursday, March 15, 2018 12:58 AM
> *To:* Rich Salz 
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] Breaking into TLS to protect customers
>
>
>
> Hi, Rich.
>
>
>
> You are conflating customers and users. The customer that may be protected
> by breaking TLS in a bank’s server farm is the bank itself. An IPS system
> with visibility into the traffic may detect bots that are there to steal
> data or mine cryptocurrencies or whatever.
>
>
>
> If the customers of the bank are protected, it’s a happy side effect
> (collateral benefit?). The object is to protect the system integrity and
> the data.
>
>
>
> Yoav
>
>
>
> On 15 Mar 2018, at 5:29, Salz, Rich  wrote:
>
>
>
> Some on this list have said that they need to break into TLS in order to
> protect customers.
>
>
>
> The thing customers seem to need the most protection is having their
> personal data stolen.  It seems to happen with amazing and disappointing
> regularity on astounding scales.  Some examples include
>
> · retailer Target, presumably subject to PCI-DSS rules
>
> · Anthem health insurance, presumably a regulated industry
>
> · Equifax, a financial-business organization (but apparently not
> regulated)
>
> · Yahoo, a company created on and by and for the Internet (one
> would think they know better)
>
> We could, of course, go on and on and on.
>
>
>
> NONE of those organizations are using TLS 1.3.
>
>
>
> So what kind of “protect the customer” requires breaking TLS?  And what
> benefits and increased protection will customers see?
>
>
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>
> ___
> 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] Encrypted SNI

[Darin Pettis]

+1



On Tue, Jul 3, 2018 at 12:08 PM Bret Jordan  wrote:

> From a discussion on the PATIENT list found here:
> https://www.ietf.org/mail-archive/web/patient/current/msg00078.html
>
>
> From my personal perspective, we need to be careful with all of these
> efforts. It feels like the pendulum has swung so far to one side, the side
> of privacy-at-any-cost, that we are unknowingly increasing the risk to
> individuals and organizations by enabling threat actors and intrusions sets
> to attack networks and clients without any level of protection from the
> network.
>
> It also feels like a lot of these initiatives are being done without
> adequately involving and ensuring that enterprise networks and critical
> infrastructure can work with these changes. Question, do we know how these
> ideas and changes are going to impact an organizations ability to fulfill
> their requirements for regulatory compliance?
>
> If we continue down these paths, then I fear networks will be required to
> wrap all traffic in some other less secure protocol, outright deny some of
> these protocols, or be forced to fully proxy all traffic or take an
> approach that Google has done with their BeyondCorp design.
>
> The IETF work needs to do more outreach with enterprise networks and
> critical infrastructure and be fundamentally more inclusive.
> Privacy-at-any-cost is not a holistic design.
>
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
> can not be unscrambled is an egg."
>
>
>
> ### Copied content from the PATIENT discussion 
>
>
> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty  at gmail.com> wrote:
>
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla  wrote:
>> >
>> >
>> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski > ..uk>
>> > wrote:
>> >>
>> >> Your point is one that deserves further discussion, Eric - which seems
>> >> likely to scale rapidly going forward.  It is key.
>> >>
>> >> So how does draft-ietf-tls-sni-encryption it into the argument?
>> >
>> >
>> > As you suggest, SNI encryption is intended to conceal the SNI, which of
>> > course would make SNI inspection difficult.
>> >
>> > My evaluation of the current state of SNI encryption is that given the
>> > current technical state, it will not see particularly wide deployment,
>> with
>> > the primary scenario being "at-risk" sites who are subject to
>> censorship who
>> > either hide behind or co-tenant with sites which are not subject to
>> > censorship. That probably isn't going to be incredibly common right
>> now. Of
>> > course, this is regrettable from the perspective of people designing
>> these
>> > protocols, but I think that's the situation.
>>
>> EKR posted a draft to encrypt SNI, see:
>> https://www.ietf.org/mail-archive/web/tls/current/msg26468.html
>>
>> It targets the CDNs who host most of the web traffic in the US at
>> least.  The right place to comment on this would be the TLS list of
>> course, but since proposals are being posted, this is a reality and
>> needs to be discussed.  Those using SNI need to make sure their use
>> cases are clear and understood and argue the pros and cons.
>>
>
> Kathleen,
>
> Thanks for pointing out this draft.
>
> As they say, predictions are hard, especially about the future. In March,
> the ESNI problem looked pretty intractable and then subsequently we had
> this idea about why it might be workable.
>
> -Ekr
>
> Best regards,
>> Kathleen
>>
>> >
>> > -Ekr
>> >
>> >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>> >>
>> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > yaanatech.co.uk>
>> >> wrote:
>> >>>
>> >>> Hi Diego,
>> >>>
>> >>> It is also worth referencing a relatively recent Lawfare article on
>> the
>> >>> scaling litigation in the U.S. against those supporting e2e encryption
>> >>> services or capabilities.
>> >>>
>> >>>
>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis
>> >>>
>> >>> This litigation trend is also likely to increase the insurance costs
>> of
>> >>> providers.  Indeed, a provider that supports TLS1.3, QUIC, SNI, etc,
>> may not
>> >>> even be able to get insurance.  It may be fun and games to play
>> crypto rebel
>> >>> in venues like the IETF where the risk exposure is minimal, but when
>> it
>> >>> comes to real world consequences and costs, the equations for
>> providers are
>> >>> rather different.
>> >>
>> >>
>> >> I think this rather overestimates the degree to which both TLS 1.3 and
>> >> QUIC change the equation about what a provider is able to determine
>> from
>> >> traffic inspection. As a practical matter, the primary change from TLS
>> 1.2
>> >> is that the provider does not get to see the server's certificate, but
>> it
>> >> does see the SNI. Given that the SNI contains the identity of the
>> server
>> >> that the client is connected to and that the other identities in the
>> >> certificate are often whateve

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

[Darin Pettis]

On Thu, Nov 14, 2019 at 4:43 PM Adam Langley 
wrote: People on this list who manage large corporate networks may wish to
pay attention to this: while you may not have updated servers to TLS 1.3
yet, eventually it'll happen and I suspect some will find a significant
amount of things like TPMs, in which you currently have client-certificate
keys, which only sign with PKCS#1 v1.5. Without this draft adopted and
implemented ahead of time, it's going to be painful.

Adam - Wanted to thank you for the call-out to people on the list managing
large corporate networks.  Looking into the mutual authentication supported
protocols issue that you and David raised.  Will evaluate potential future
impact.

Cheers,
Darin

On Thu, Nov 14, 2019 at 4:43 PM Adam Langley  wrote:

> On Mon, Nov 11, 2019 at 11:33 AM Christopher Wood 
> wrote:
>
>> The adoption call is now (belatedly) finished. At this time, there's not
>> enough interest to take this on as a WG item. We encourage further
>> discussion on the list, perhaps based on subsequent draft updates, and will
>> revisit adoption in the future if interest grows.
>>
>
> People on this list who manage large corporate networks may wish to pay
> attention to this: while you may not have updated servers to TLS 1.3 yet,
> eventually it'll happen and I suspect some will find a significant amount
> of things like TPMs, in which you currently have client-certificate keys,
> which only sign with PKCS#1 v1.5. Without this draft adopted and
> implemented ahead of time, it's going to be painful.
>
>
> Cheers
>
> AGL
> ___
> 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] Weekly github digest (TLS Working Group Drafts)

[Darin Pettis]

Hi - trying to understand the intent of this:  “Don’t stick out” approach
to eSNI, now being called ECHO apparently.

About a year ago, the understanding was that eSNI would be identifiable and
that enterprises wouldn’t need to use it internally and that it would only
be used on the Internet.

Is that not the case anymore?

On Sun, Apr 12, 2020 at 2:33 AM Repository Activity Summary Bot <
do_not_re...@mnot.net> wrote:

> Sunday April 12, 2020 Issues tlswg/draft-ietf-tls-esni (+2/-0/💬1)
>
> 2 issues created:
>
>- #215 Limit "Don't stick out" to explicit signals
> (by
>chris-wood)
>- #214 Clarify whether ClientHelloInner can support TLS 1.2.
> (by
>chris-wood)
>
> 1 issues received 1 new comments:
>
>- #204 Anonymity sets
> (1 by
>ret394)
>
> tlswg/draft-ietf-tls-external-psk-importer (+0/-1/💬1)
>
> 1 issues received 1 new comments:
>
>- #26 Clarify MUSTs
>
>(1 by chris-wood)
>
> 1 issues closed:
>
>- #26 Clarify MUSTs
>
>
> tlswg/tls-exported-authenticator (+1/-0/💬1)
>
> 1 issues created:
>
>- #56 Generalize authentication terminology
> (by
>chris-wood)
>
> 1 issues received 1 new comments:
>
>- #56 Generalize authentication terminology
> (1 by
>chris-wood)
>
> Pull requests tlswg/draft-ietf-tls-esni (+1/-0/💬4)
>
> 1 pull requests submitted:
>
>- #213 README: fix links to WG docs
> (by
>Lekensteyn)
>
> 1 pull requests received 4 new comments:
>
>- #209 padding scheme text
> (4 by
>chris-wood, sayrer, sftcd)
>
> tlswg/draft-ietf-tls-external-psk-importer (+1/-1/💬0)
>
> 1 pull requests submitted:
>
>- #29 Tighten up IANA considerations
>
>(by jsalowey)
>
> 1 pull requests merged:
>
>- #28 Editorial pass to simplify text and unify terminology.
>
>
> tlswg/draft-ietf-tls-ticketrequest (+1/-0/💬4)
>
> 1 pull requests submitted:
>
>- #19 Use two counters for fresh and resumed connections
> (by
>chris-wood)
>
> 1 pull requests received 4 new comments:
>
>- #19 Use two counters for fresh and resumed connections
> (4 by
>chris-wood, martinthomson, tfpauly)
>
> tlswg/dtls13-spec (+0/-0/💬1)
>
> 1 pull requests received 1 new comments:
>
>- #129 Removed term "deprotection"
> (1 by ekr)
>
> Repositories tracked by this digest:
>
>- https://github.com/tlswg/draft-ietf-tls-semistatic-dh
>- https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
>- https://github.com/tlswg/draft-ietf-tls-esni
>- https://github.com/tlswg/certificate-compression
>- https://github.com/tlswg/draft-ietf-tls-external-psk-importer
>- https://github.com/tlswg/draft-ietf-tls-ticketrequest
>- https://github.com/tlswg/tls-flags
>- https://github.com/tlswg/dtls13-spec
>- https://github.com/tlswg/dtls-conn-id
>- https://github.com/tlswg/tls-subcerts
>- https://github.com/tlswg/oldversions-deprecate
>- https://github.com/tlswg/sniencryption
>- https://github.com/tlswg/tls-exported-authenticator
>- https://github.com/tlswg/draft-ietf-tls-grease
>
> ___
> 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*

[darin . pettis]

Hello,

On Mon, Nov 21, 2016 at 9:43 PM, Salz, Rich  wrote:

> With this in mind, I'm voting in favor of any re-branding of TLS 1.3 
where the
> protocol name remains "TLS" and major version becomes > 1.

I originally hummed for 1.3 in the room as that is what people (that are 
currently aware of it) know it by.  However, as the new standard goes out 
into the world, a major revision number seems appropriate to recognize the 
significant changes that have gone into it. 

+1
Darin Pettis


U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[darin . pettis]

+1 with Andrei. 

"That SSL should never be used" is the one clear message we have so going 
back to SSL would muddy those waters too much.  Strong vote for staying 
with TLS.  It will become better known over time- especially with the 
current enterprise push to deprecate all SSL versions from use. 
Regarding the numbering schema, someone recently mentioned that probably 
only a few hundred of us are aware of the TLS 1.3 nomenclature at this 
point and I would concur with that.  So, after considering all of the good 
points that have been circulating, I would like to change my vote to TLS 
2017.  It provides clarity, recognizes that it is a major change and pulls 
us out of the whole SSL/TLS numbering confusion/quagmire.

Darin



From:   Andrei Popov 
To: Daniel Kahn Gillmor , Peter Gutmann 
, Stephen Farrell , 
David Benjamin , Tony Arcieri , 
"" 
Date:   12/02/2016 12:34 PM
Subject:Re: [TLS] Confirming consensus: TLS1.3->TLS*
Sent by:"TLS" 



Indeed, "all known versions of SSL are broken and should never be used" is 
what I've been telling people for a while now...

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Daniel Kahn Gillmor
Sent: Friday, December 2, 2016 6:36 AM
To: Peter Gutmann ; Stephen Farrell 
; David Benjamin ; Tony 
Arcieri ;  
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*

On Fri 2016-12-02 03:33:21 -0500, Peter Gutmann wrote:
> If no-one from Microsoft has any objections, can we just rename it 
> back to what it's always been for everyone but us, SSL?

fwiw, the industry (and stackexchange) uses "SSL" to mean all sorts of 
things, not only TLS.  Yesterday i got an e-mail from a reputable CA 
reseller that said "Your SSL is expiring in two days!  Buy a new SSL now!"

Surely no one is proposing that we also re-name the X.509 certificate 
format to "SSL" just because vendors whose business models revolve around 
these products are confused about terminology.  What else should we rename 
to "SSL" on that basis?  Maybe a load-balancer is also "SSL"!

Here's a useful and effective meme for convincing bosses that it's ok to 
turn off SSLv3: all known versions of SSL are broken and should never be 
used.  Please do not break this meme by trying to rename TLS to SSL.

I don't care about the bikeshed over the number: i'd be fine with any of 
TLS 1.3 or TLS 4 or TLS 2017.  But can we please not create *even more* 
confusion by bikeshedding over the name itself?

   --dkg

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




U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Darin Pettis]

On Thu, Oct 19, 2017 at 12:27 PM Salz, Rich  wrote:

> We disagree.
>
> Being able to block traffic is much less effort than pretending to be
> another identity.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

First I want to thank the TLS WG for all their assistance and conversation
around finding the right methodology for continued visibility.

The question has been raised: "Why address visibility now?"   The answer is
that it is critical that the visibility capability is retained.  It is
available today through the RSA key exchange algorithm.  We understand that
the issue was raised late and have fallen on the preverbal sword for being
late to the party but the issue is real.  That is where the "rhrd" draft
has come from.  A way to retain that visibility capability but with a newer
and more secure protocol.

We need to protect and troubleshoot data that is within each of our
companies.   As encryption becomes more prevalent, it becomes more and more
critical to see that data.

The amount of people currently voicing concern is likely small for two
reasons.  One is that everything is public and many of the "lurkers" are
hesitant to voice their concerns.  The second reason is that so many don't
know that visibility will be an issue.  They will either discover this as
they migrate to TLS 1.3 or as they start to encrypt within their data
center.  There is work to rapidly raise that awareness through roundtables,
conferences and other venues.

It is very positive that the WG has made a number of great recommendations
that have led to this solution.   That is the intention.  We would
appreciate the WG now adopting the extension so that it can be ushered
through the process.   This continued visibility can continue to be
available as we all have expectations that our data is safeguarded and that
websites are available to us quickly.   Thank you for your valued
assistance!
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls