[TLS] Re: Changing WG Mail List Reputation

Although it is, as ekr has pointed out, not normative, nevertheless RFC 7282 provides a solid process for coming to rough consensus. This method does not involve voting, and I think operates in the way that DJB proposes. I certainly would not consider vote counting to be a valid way to determine co

[TLS] Re: Changing WG Mail List Reputation

Moreover, it means that someone who is not available at the time of the meeting for whatever reason even if it’s not money (for example, they have a conflict with another wg) is now excluded. There is a good reason why we do consensus on mailing lists. If participants are engaging in dos attacks yo

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

Encrypted dns transport works if you can trust the provider you are talking to. DNSSEC works even if you can’t. And if your provider is trustworthy, DNSSEC validation of results acquired through this tunnel should work. So it’s silly in this case to trust the tunnel—there’s no upside to doing so ot

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

his which might have been more > clear when they > were a single document. > >Erik > > > > > On Fri, Mar 29, 2024 at 11:31 PM Ted Lemon wrote: > >> Yes, that fully addresses my concern. Thanks! >> >> Op vr 29 mrt 2024 om 22:54 schreef Eric Resc

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

> -Ekr > > > > On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon wrote: > >> Okay, I think I see the disconnect, maybe. The issue I'm pointing to is >> that you may or may not be doing DNSSEC validation. And you may or may not >> be /able/ to do DNSSEC validation if t

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

ts > embedded in the SVCB are met (the server chooses those, which can include > many aspects of the request). I don't understand why one would insert > DNSSEC here. That seems to be the whole point--it works without it. > > thanks, > Rob > > > On Fri, Mar 29, 2024

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

ervers. I think these are > separate problems, though. > > thanks, > Rob > > > On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon wrote: > >> It looks like if you can't get the SCVB you're going to fail insecure, so >> being able to use DNSSEC to prevent that for si

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

It looks like if you can't get the SCVB you're going to fail insecure, so being able to use DNSSEC to prevent that for signed domains seems worthwhile. On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre wrote: > On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker < > nore

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

That seems okay. Would be good to document in the security considerations. On Fri, Mar 29, 2024 at 4:41 PM Eric Rescorla wrote: > > > On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker < > nore...@ietf.org> wrote: > >> Reviewer: Ted Lemon >> Review res

[TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

Reviewer: Ted Lemon Review result: Almost Ready This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01. Section 4.1 advises disabling fallback, but does not talk about DNSSEC, which is surprising given that the draft proposes privacy properties for SVCB responses containing ECH data. I

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

On Dec 4, 2020, at 19:17, Nick Hilliard wrote: > people don't necessarily buy stuff that's not ungradeable. They buy stuff > which has a support lifetime of finite duration. Same thing. If you’re serious about business continuity, you have an arrangement with the vendor about what happens if t

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

On Dec 4, 2020, at 5:29 PM, Ackermann, Michael wrote: > Regards to the 12 years vs 1-2.12 years is probably too long for just > about anything, once it is determined to be a business need. But that is > the key first step. Then it will likely be a minimum of 1-2 years to get > the ident

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

On Dec 4, 2020, at 3:00 PM, Ackermann, Michael wrote: > 1. Enterprises do not expect nor want IETF to be responsible for their > planning for changes in technology.But when IETF decides to change > protocols or deprecate existing technology of any sort, it would be > beneficial to all if o

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

Michael, fundamentally the disconnect here seems to be that the IETF could ever be responsible for helping businesses to figure out how to plan for changes in technology _other_ than by doing work like this. Deprecating old versions of protocols is exactly what the IETF should be doing. This is

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

On Dec 2, 2020, at 1:51 PM, STARK, BARBARA H wrote: > The final version of this was published over a year ago (August 2019). The > first draft was in 2017. > You said enterprises needed 1-2 years (or more) lead time. In the US, I think > they've had at least 3 years lead time, so far. Actually,

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

On Dec 2, 2020, at 11:22 AM, Bill Frantz wrote: > One I think I can address are heart pacemakers. These are imbedded in the > patients chests. Upgrading them requires surgery. However, they have a > limited lifespan due to their batteries running down, I think we're talking > about 10 years or

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

On Dec 2, 2020, at 11:00 AM, Ted Lemon wrote: > The situation right now is that it’s been known for a long time that RC4 and > MD5 are not safe to use. Your vendors have known about this for a long time. > If they do not have a roll-out plan for software that corrects the problem, &

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

On Dec 2, 2020, at 9:58 AM, Ackermann, Michael wrote: > As an Enterprise person I can say we are not well equipped to be aware of nor > react "Nimbly" to changes such as this. Wide scope and security related > changes can require major changes to core Business systems. This can mean > signifi

Re: [TLS] Intdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

e of those cryptographic weaknesses is > certainly a factor in moving to deprecate the vulnerable algorithms, but it > is not the only factor. > > -Ben > >> On Wed, Oct 28, 2020 at 08:56:13AM -0700, Ted Lemon via Datatracker wrote: >> Reviewer: Ted Lemon >> Review result:

[TLS] Intdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

Reviewer: Ted Lemon Review result: Ready with Nits This document is ready for publication, with one minor nit, which is included at the end. Éric additionally made the following request: As those hash algorithms were 'cheap' for TLS, I would appreciate a review of the impac

Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS

Can you provide a citation for that statement? Not doubting you, particularly, but this is news to me, and probably to some others on this list, if true. On Tue, Oct 16, 2018 at 4:01 PM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > Unjust certificates can be bought for 150,- $ in the darkne

Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS

Not an argument in favor of the proposal, but the issue with firewall certs is not that we would want to override local security policy, but that firewall certs *can* in principle override local security policy, and in principle DANE could be used to prevent that. What is meant by a firewall cert

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

browser. > > 2. Even if there is a browser (and see point 1 before assuming) any > HTTP communication would be at a much much slower rate than machine to > machine I/O > > > > Hope that clears it up. > > > > Thanks and Best Regards, > > > >

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

If the device implements the cipher so as to talk to the browser, it's clearly capable of implementing the cipher... On Tue, Aug 21, 2018 at 1:34 PM, Jack Visoky wrote: > Hi Rich, > > > > I’m not sure if I’m following the question, but what was meant was that > these ciphers are generally NOT us

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

So rather than upgrading to TLS 1.3, why not just upgrade to IPsec? You're going to have to change what you do anyway—rather than arguing with us why not bypass us entirely? On Tue, Aug 21, 2018 at 1:06 PM, Jack Visoky wrote: > Just to pile on what Steffen is saying, the motivation for this is

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

needed. > > > > Thanks and Best Regards, > > > > --Jack > > > > *From:* Ted Lemon [mailto:mel...@fugue.com] > *Sent:* Tuesday, August 21, 2018 10:58 AM > *To:* Jack Visoky > *Cc:* Andreas Walz ; tls@ietf.org; ncamwing= > 40cisco@dmarc.ietf.or

Re: [TLS] integrity only ciphersuites

This is a situation where there is a clear alternative: use IPsec. IPsec is ideal for the problem space you are in. TLS is actually really not ideal. You are trying to cram a round peg into a square hole. On Tue, Aug 21, 2018 at 12:00 PM, Fries, Steffen wrote: > > > > > Ø If there would b

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

Thanks, Jack, but could you respond to the specific questions that we asked you? Earlier you were saying that your motivation for using NULL ciphers was that you had specific hardware that couldn't implement encryption due to lack of horsepower or memory. Now you seem to be saying something com

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

On Mon, Aug 20, 2018 at 5:36 PM, Jack Visoky wrote: > 2. In some cases the code size is quite important. It’s not uncommon for > hardware to be in the field in Industrial Automation for 15 or more years, > so in some cases the hardware is already stretched pretty thin and might > not be able to

Re: [TLS] Doubts about a solution or new service/protocol

Why do you need to extend tls to do this? Why not just use it for encapsulation? What you are describing sounds more like pgp than tls. On Mon, Jul 16, 2018 at 12:15 PM Walter Neto wrote: > Hi IETF tls list, > > I have some problem to solve I believe it is good to make my questions and > propo

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

I have no pony in this race, but FWIW ~5 people on each side represents a lack of consensus. A lack of consensus means that the work doesn't happen in the working group. Thomas, your response (sorry to pick on you!) illustrates another consensus issue: consensus exists when all technical objecti

Re: [TLS] TLS@IETF101 Agenda Posted

My responses for today are all in this message, including a response to Ralph. I'm going to try not to engage on this again until tomorrow. On Mar 14, 2018, at 6:52 PM, nalini elkins wrote: > 1. Multiple standards are likely to diverge. We don't need multiple standards, so this isn't an issue

Re: [TLS] TLS@IETF101 Agenda Posted

Perhaps this would be a good time to put in a plug for additional funding for openssl et al... On Mar 14, 2018 14:53, "Russ Housley" wrote: > > > On Mar 14, 2018, at 8:39 AM, Hubert Kario wrote: > > > > On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote: > >> Ted: > >>> There's an easy w

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 11:49 PM, Russ Housley wrote: > I was trying to separate these two cases. If the TLS session is terminated > at a load balancer, then the client within the load balancer is (as Ted says) > under control of the operator. The operator can include any extensions that > it wis

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

On Mar 14, 2018, at 5:01 AM, Stephen Farrell wrote: >> I hum in the meeting is a meaningful way to find out what the >> quiet people are thinking. > > And of course also any people who try pack out the room for any > reason;-( As long as the hum is treated as Pete describes in RFC 7282, this sho

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 6:16 PM, Russ Housley wrote: > This is a bogus argument. I'm pretty sure there's a Monty Python skit about this, so I won't belabor the point. > First, staying with an old protocol version often leads to locking in > unmaintained versions of old software. Right, that's one

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 6:22 PM, Stephen Farrell wrote: > I mean, do you *really* think there's any chance of reaching rough > consensus on the list for this draft? If not, then ISTM you're > putting meeting attendees and list participants through a bunch > of pain for no gain. It's actually worse th

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 3:20 PM, Ackermann, Michael wrote: > I think that most Enterprises are not espousing any conversations "how can we > avoid making any changes?" With respect, Michael, when I have conversed with you about this in the past, that is precisely what you have asked for. You do n

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 12:37 PM, nalini elkins wrote: > "We" is a consortium of organizations. I would say over 50 so far. They > operate large data centers. They are in manufacturing, insurance, finance, > and others. Nalini, why don't you (the consortium) define the standard, then? The r

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

On Mar 6, 2018, at 5:35 PM, Colm MacCárthaigh wrote: > There's a general conjecture that the more information that is provided to > attackers, the more easily they can leverage into a compromise. Personally I > believe that conjecture, and would actually prefer to see fewer signals, > ideally a

Re: [TLS] Captive portals, "access administratively disabled" and alert messages

We had a conversation about this at a Boston IETF meetup last year; the consensus, with which I agree, is that simply adding TLS alerts isn't good enough, for (essentially) the reason you stated earlier: we have no way to know that the attacker here is a good guy. E.g., in the case of the Open

Re: [TLS] TLS@IETF100: Agenda Requests

On Nov 5, 2017, at 5:09 PM, Salz, Rich wrote: > I didn’t say votes. Sure, but you did say "only the authors are interested" which to me seems to imply a comparison of numbers. Sometimes everybody who's interested in an idea is an author; that doesn't mean it's a bad idea. There have been ca

Re: [TLS] TLS@IETF100: Agenda Requests

Consensus isn't about number of votes. However, I think we can say that although there seems to be some interest in making sure this use case is addressed, there are known ways of addressing it, and little interest in inventing a new way that weakens a new feature of tls 1.3 On Nov 5, 2017 14:03,

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

prises because rearchitecting their systems for a multi-key escrow > is either too costly or that the requirement for TLS 1.3 will come too soon. > Ted Lemon had some convincing arguments earlier about why enterprises should > see this coming and invest in migrating to a model closer

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

On Oct 24, 2017, at 4:40 PM, David A. Cooper wrote: > Also, in the data center case, there is no middlebox. Others, who know much > more than I do about operational constraints in data center environments, > have already argued that setting up a bunch of middleboxes would not be a > viable solu

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

On Oct 24, 2017, at 4:21 PM, David A. Cooper wrote: > I'm not suggesting that cash strapped schools would use one of these devices. > I'm simply saying that such a solution would be simpler and far more > effective than trying to use draft-rhrd-tls-tls13-visibility to snoop on > outgoing traffi

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

On Oct 24, 2017, at 3:59 PM, Ted Lemon wrote: > On Oct 24, 2017, at 3:54 PM, David A. Cooper <mailto:david.coo...@nist.gov>> wrote: >> There are already middleboxes on the market today that do this. They work >> for all outgoing connections and don't require any co

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

On Oct 24, 2017, at 3:54 PM, David A. Cooper wrote: > There are already middleboxes on the market today that do this. They work for > all outgoing connections and don't require any cooperation whatsoever from > the outside servers that the clients are trying to connect to, and only > expert use

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

On Oct 24, 2017, at 3:24 PM, Ralph Droms wrote: > ...with the assumption that a client would automatically revert to trying the > connection with the visibility extension if it can't make a connection > without the extension. Why would that assumption be useful? How is this > situation differ

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

On Oct 24, 2017, at 12:49 PM, Joseph Salowey wrote: > First, we would like to clarify that this discussion isn't delaying TLS 1.3. > We've been holding final publication to resolve some middlebox issues as > described in a recent message from ekr > https://mailarchive.ietf.org/arch/msg/tls/yt4ot

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

On Oct 24, 2017, at 3:04 PM, David A. Cooper wrote: > In order for a middlebox to be able to use this draft to intercept traffic > that is TLS protected, it would need to: > > 1) get the server to agree to allow it to intercept the traffic; and > > 2) get the client to include the new extension

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

On Oct 23, 2017, at 2:12 PM, Ackermann, Michael wrote: > To suggest that I or my industry does not take security seriously, is > inaccurate and immaterial to this discussion. I'm sure you take security seriously. What I'm saying is that you have tunnel vision about it, because you are caught

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

On Oct 23, 2017, at 1:30 PM, Ackermann, Michael wrote: > The WHY you ask is in the answer. > It is a huge proposition requiring change to virtually every platform and > application.Not to mention all the management, monitoring and security > platforms. > It would be very expensive and ti

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

On Oct 23, 2017, at 12:39 PM, Ackermann, Michael wrote: > If staying with TLS 1.2 indefinitely was considered acceptable, would we > even be having these discussions? This is a vacuous argument. Nobody has provided any evidence of any kind that "enterprise" installations relying on TLS 1.2

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

On Oct 23, 2017, at 12:25 PM, Ralph Droms wrote: > Is there running code that demonstrates the IPsec+IKE can be deployed and > operated at scale in the sort of environment the enterprise network tips have > described to us? Is there running code that demonstrates that draft-rhrd-tls-tls13-visib

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

On Oct 23, 2017, at 12:22 PM, Ackermann, Michael wrote: > My question back to you was WHAT SIMPLIER PROTOCOL? This is what I actually wrote, in the message before the one Kathleen sent: > What they require is visibility into contents of the flow that they are using > encryption to protect.

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

On Oct 23, 2017, at 10:35 AM, Ackermann, Michael wrote: > I was only asking what your opinion was, based on that statement in your > reply. With respect, Michael, I gave my opinion in the message to which Kathleen replied, so your assertion that you have been reading these messages doesn't se

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

On Oct 22, 2017, at 7:16 PM, Ackermann, Michael wrote: > And out of curiosity, what is the simpler protocol you are recommending? > I say out of curiosity because switching to a whole different protocol is not > likely to be feasible from any perspective for large enterprises and the > comp

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

On Oct 22, 2017, at 7:26 PM, Steve Fenter wrote: > I have been saying to anyone who will listen that the IETF needs a private > forum for enterprises, to enable them to come forward and discuss their real > requirements. Without this input the IETF is trying to architect and engineer > solution

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

On Oct 22, 2017, at 4:48 PM, Steve Fenter wrote: > The main problem with not addressing the TLS visibility issue now is that no > one knows when a vulnerability will be discovered in TLS 1.2 that forces > enterprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the > RSA key exc

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

On Oct 22, 2017, at 1:54 PM, Russ Housley wrote: > No one is requiring TLS 1.3 that I know about. However, there are places > that require visibility into TLS. I will let one of the people that works in > a regulated industry offer pointers to the documents. What they require is visibility in

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

On Oct 20, 2017, at 9:54 AM, Stephen Farrell wrote: > Others did > comment that the lack of client opt-in was a > bad aspect of draft-green, but I'm not sure > that anyone clearly said "I do want draft-green > snooping, but with client opt-in." I can say for myself that there was a really strong

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

On Oct 19, 2017, at 1:12 PM, Blumenthal, Uri - 0553 - MITLL wrote: > If those middleboxes already have sufficient alternative options, why do we > spend time discussing this draft? Why do we need to add yet another > alternative for them? Indeed, if this proposal were equivalent to CA forcing,

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Aug 11, 2017, at 11:17 AM, Short, Todd wrote: > The application can solve this by having its own padding. If it’s going to > force all messages to be padded out to 1024 bytes by TLS, why not just make > that part of the application protocol? Its not as though it’s trying to save > bytes here

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL wrote: > What I am trying to avoid is the ability to *surreptitiously* subvert a > protocol that’s assumed to be secure. You don't seem to be hearing what I'm trying to say. What you are proposing is physically impossible. It is a

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Jul 23, 2017, at 5:37 PM, Christian Huitema wrote: > Speaking of threat model, one of the main threats is the "Lavabit" case: a > server is asked to somehow implement a backdoor so existing clients. In that > case, it is very useful for clients to detect that something has changed. > They ca

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL wrote: > I think there's no way the connection can be established if the third party > in control of the network does not allow that. This is why it’s hard to reason well about this stuff—we tend to get the threat models wrong. Th

Re: [TLS] datacenter TLS decryption as a three-party protocol

I did a little bit of rubber-duck debugging on this proposal with Andrea on the way back from Boston this morning. It's actually better for the server to secretly use a static key than to negotiate. Stephen has already explained why: if this is a negotiation, then it's possible for a third p

Re: [TLS] Is there a way forward after today's hum?

t; > I hope the above helps, but my real question is why would this be special > or even relevant to the TLS1.3 discussion. > > > > Attempting to address specific applications or implementations would seem > only add confusion IMHO. > > > > Thanks > > &g

Re: [TLS] Is there a way forward after today's hum?

The problem is that one of the applications for web browsers is as a replacement for 3270s (the first web browser). That use case is said to require this functionality. On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter wrote: > On 20 July 2017 at 01:53, Yoav Nir wrote: > > > > On 20 Jul 2017, at 8:

Re: [TLS] Is there a way forward after today's hum?

*From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon > *Sent:* Thursday, July 20, 2017 07:51 > *To:* Paul Turner > *Cc:* Robin Wilton ; > *Subject:* Re: [TLS] Is there a way forward after today's hum? > > > > Paul, the reason to use the MiTM approach rath

Re: [TLS] Is there a way forward after today's hum?

e added to everyone's TLS libraries. Now the number of lines of code I'd have to #ifdef out to avoid setting the evil bit would be much less than if it weren't. On Thu, Jul 20, 2017 at 1:44 PM, Paul Turner wrote: > > > > > *From:* TLS [mailto:tls-boun...@ie

Re: [TLS] Is there a way forward after today's hum?

Paul, it would be trivial to normal that exchange to conceal from the client that a static key is being used. No software mods required on either end: just in the middle. On Jul 20, 2017 1:04 PM, "Paul Turner" wrote: > > > > > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Robin Wilton

Re: [TLS] Is there a way forward after today's hum?

t; violation for the server to include it. > > Russ > > > On Jul 19, 2017, at 1:14 PM, Ted Lemon wrote: > > Provably involved, or involved setting an evil bit? > > On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley > wrote: > >> The hum told us that the room was r

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

So is it an accurate assessment that the reason you aren't using ipsec fur this use case is that the APIs suck and your engines don't support them? On Jul 19, 2017 8:41 PM, "Roland Dobbins" wrote: > On 19 Jul 2017, at 20:37, Blumenthal, Uri - 0553 - MITLL wrote: > > I keep telling that this pool

Re: [TLS] datacenter TLS decryption as a three-party protocol

7;t mean it can't be done. On Wed, Jul 19, 2017 at 7:45 PM, Colm MacCárthaigh wrote: > > > On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon wrote: > >> The problem is that the actual solution to this problem is to accept that >> you aren't going to be able to dec

Re: [TLS] datacenter TLS decryption as a three-party protocol

The problem is that the actual solution to this problem is to accept that you aren't going to be able to decrypt the streams, and then figure out what to do instead. Which is work the proponents of not doing that are not interested in doing, understandably, and which is also not the work of this

Re: [TLS] Is there a way forward after today's hum?

Provably involved, or involved setting an evil bit? On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley wrote: > The hum told us that the room was roughly evenly split. In hind sight, I > wish the chairs had asked a second question. If the split in the room was > different for the second question, t

Re: [TLS] datacenter TLS decryption as a three-party protocol

n is to say "if you want to solve this problem in the IETF, here is what we could do that might get IETF consensus." On Wed, Jul 19, 2017 at 3:51 PM, Kyle Rose wrote: > On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon wrote: > >> This is exactly right. We have a *real* proble

Re: [TLS] datacenter TLS decryption as a three-party protocol

This is exactly right. We have a *real* problem here. We should *really* solve it. We should do the math. :) On Wed, Jul 19, 2017 at 3:09 PM, Benjamin Kaduk wrote: > As Stephen noted in his presentation, a lot of the proposals for passive > decryption can be seen as trying to turn TLS fr

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

What it means for users to be denied the benefits of TLS 1.3 is that they don't get, for example, perfect forward secrecy. Since the proposal was to do away with that anyway, but for all users, not just some users, that doesn't seem like it is better than just continuing to use TLS 1.2. It's alre

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael wrote: > Your first sentence illustrates the disconnect between the Enterprise > perspective and what many at IETF are saying. > > That being the unencrypted stream is available to the endpoints. IT IS > NOT. When you run a packet trace at

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

I was at at least one of those presentations recently, and while it certainly convinced me that there was a problem in the short term, it did not convince me that the points you are making are inherent problems with the technology. That is, the problem is not that there is no way to achieve what

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sat, Jul 15, 2017 at 11:05 AM, Dobbins, Roland wrote: > There is plenty of information on these topics available on the Internet > today. Search engines exist. It isn't reasonable to expect a class to be > held on the basics of network security & troubleshooting tools & techniques > on this

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sat, Jul 15, 2017 at 10:22 AM, Dobbins, Roland wrote: > > I think that your first and third points are actually non-sequiturs: the > unencrypted stream is available to the entities controlling either > endpoint, not just the log. > > This assertion is both incorrect & incomplete in its scope. >

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

paraphrase that correctly? On Sat, Jul 15, 2017 at 9:54 AM, Dobbins, Roland wrote: > > > > On Jul 15, 2017, at 14:48, Ted Lemon wrote: > > > > In the event that it is not feasible for an operator to obtain the > plaintext of a message without the key, isn't that bec

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

In the event that it is not feasible for an operator to obtain the plaintext of a message without the key, isn't that because they don't control either endpoint? If so, why would it be their responsibility to obtain the plaintext? It should be the responsibility of the controller of one of the

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

It seems to me that all the use cases you just described require the *client* to have a static key, since the client is the thing that the operator controls. If the client uses an unknown key, is malware or unauthorized. On Jul 14, 2017 20:42, "Roland Dobbins" wrote: > On 15 Jul 2017, at 1:01, M

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

I have two working groups already in the monday slot. I doubt I'm unique in this. It seems like you should put the important business in the slot that was previously scheduled, and the overflow into the Monday slot. It's hard to imagine how a discussion of the wiretapping thing could be anythin

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 12, 2017, at 10:35 AM, Kyle Rose wrote: > Which will have zero impact on pervasive surveillance until some government > decides they want to use this mechanism or something like it and mandates > that it be implemented universally within their borders. Then it will appear > in short orde

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 12, 2017, at 10:32 AM, Richard Barnes wrote: > Oh, come on. You've never seen code in a library that implements something > that's not in an IETF RFC? Of course I have. I think that putting a warning in the TLS 1.3 spec as Christian suggested will mean that the code won't appear in

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 12, 2017, at 10:18 AM, Kyle Rose wrote: > We need to dispel the myth that mere inaction on our part will on its own > prevent implementation of these mechanisms, if for no other reason but to > redirect energy to the political arena where the pervasive monitoring battles > *are* actually

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 12, 2017, at 8:24 AM, Kyle Rose wrote: > Much of this conversation seems to conflate wiretapping with collaboration. > 2804 has a clear definition of wiretapping: The problem is that in modern times we can't assume that collaboration is consensual, so the rules in RFC2804 aren't as appli

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

To paraphrase (and forgive me for being a bit brutal here), you have no basis for what you said other than handwaves and something from a Cisco marketing presentation? That is, "the odds are better if..." is a handwave, and not clearly true. "Malware could be caught ... with multiple inspection po

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 11, 2017, at 4:58 PM, Ted Lemon wrote: > On Jul 11, 2017, at 4:31 PM, Stephen Farrell <mailto:stephen.farr...@cs.tcd.ie>> wrote: >> I'd bet folks would invent proprietary >> ways of avoiding detection, that deviate from the "standard" >> and t

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 11, 2017, at 4:31 PM, Stephen Farrell wrote: > I'd bet folks would invent proprietary > ways of avoiding detection, that deviate from the "standard" > and that perhaps make crypto worse all around. Say by deriving > secrets from some function f(exfiltrated-secret, time, count) > for a small

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 11, 2017, at 3:59 PM, Stephen Farrell wrote: > I can't see that happening. Once the first example.com > is called > out for using this, others will make their list longer or take > other approaches, e.g. use one exfiltrated private value as a > seed for others via som

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 11, 2017, at 3:40 PM, Stephen Farrell wrote: > It'd seem possible for a server to hold a rather long > list of re-used static DH values and unlikely for normal > clients to detect those. Bearing in mind that the current proposal is intended to perpetuate a well-established use model so as

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 11, 2017, at 2:39 PM, Steve Fenter wrote: > Network security monitoring is not just monitoring traffic that results from > communications with customers and partners. All it takes is for one user to > click on a phishing email and there is malware inside the enterprise. Once > this hap

Re: [TLS] chairs - please shutdown wiretapping discussion...

What the draft actually says is that you can install a fixed key on the server rather than generating new keys every time, and then that fixed key can also be installed on monitoring software. This is, I believe, the actual intended use of the proposal. It’s also true that you can just exfilt

  1   2   >