Re: [TLS] sect571r1

On Wed, Jul 15, 2015 at 11:13 AM, Dave Garrett wrote: > So, should it stay or should it go now? Opinions? I'd prefer to see it removed. There's no good reason to keep it, IMO. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https:/

Re: [TLS] sect571r1

On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett wrote: > It's the most used of the rarely used curves. I think all "rarely used curves" should be removed from TLS. Specifically, I think it would make sense for TLS to adopt a curve portfolio like this: - CFRG curves (RECOMMENDED): Curve25519, Ed4

Re: [TLS] sect571r1

On Wed, Jul 15, 2015 at 4:40 PM, Brian Smith wrote: > I agree, except that I think we should get rid of P-521 too. > I'd be fine with that -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] sect571r1

ocket just in case of an ECC disaster, why do we need backup curves in addition to FFDHE? -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1

ecommend curves and not > only include special primes. Should some problem with a particular subclass > show up over time, one then at least has other classes available. I just responded to Dan Brown with this, but it applies here as well: -- Forwarded message ------ From: Tony Ar

Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1

://eprint.iacr.org/2015/310.pdf I think even if we don't completely pare down the TLS curve portfolio to the list I suggested, if nothing else I would like to see binary curves removed. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ie

Re: [TLS] sect571r1

On Wed, Jul 15, 2015 at 8:41 PM, Jeffrey Walton wrote: > It provides 256-bits of security. Its the only curve I am aware that > can transport a AES-256 key while maintaining security levels. Why do you think P-521 doesn't provide this? -- T

Re: [TLS] sect571r1

On Wed, Jul 15, 2015 at 8:52 PM, Jeffrey Walton wrote: > My bad... I meant over the binary curves. Per my comments on the other thread ("selection criteria for crypto primitives"), I think binary curves don't instill confidence and should probably be remove

Re: [TLS] DSA support in TLS 1.3.

real-world use case in mind. In absence of real-world use cases, removing legacy baggage from TLS reduces attack surface and makes things easier for implementers. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

and the people asking for it to be retained do not seem to have real-world use cases. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

atents should apply to the CFRG curves or EdDSA (and it's seeming highly likely that the CFRG signature algorithm will greatly resemble or be EdDSA) -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

en those hypothetical people should use RSA signatures and FFDHE key exchange -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for consensus to remove anonymous DH

On Wednesday, September 16, 2015, Eric Rescorla wrote: > In addition, they are already part of TLS, so the question would be if we > have > consensus to remove them > I see a bunch of +1s and zero -1s. Just saying... -- Tony Arcieri ___

Re: [TLS] TLS 1.3 - Support for compression to be removed

On Sat, Sep 19, 2015 at 12:04 PM, Daniel Kahn Gillmor wrote: > I think we should remove compression and we should also explicitly warn > users of the protocol about the risks of combining compression with TLS. +1 -- Tony Arcieri ___ TLS m

Re: [TLS] TLS 1.3 - Support for compression to be removed

S just because some protocols want to do unsafe things and are too lazy to implement their own compression. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

ss support. Period. They should not be relying on a poorly conceived feature which has been repeatedly demonstrated to introduce vulnerabilities in what is supposed to be a *security protocol* just because they don't want to implement compression themselves. -- Tony Arcieri

Re: [TLS] TLS 1.3 - Support for compression to be removed

value an attacker wishes to learn, and attacker-controlled data, or there will be a compression side-channel. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

produced a secure system for "compression side-channel resistant encryption", I haven't seen it. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

o try to use TLS compression instead, not only would it fail to compress as well, but it would have a compression side-channel an attacker could use to potentially recover a transcript of an encrypted conversation (such attacks against against VBR audio compression). TLS is the wrong layer at which to solve t

Re: [TLS] Data limit for GCM under a given key.

confidentiality protection" being used here? > I too am confused by Quynh's statement. Indistinguishability is the modern bar for confidentiality and authentication. Quynh, are you talking about anything less than IND-CCA2? If you are, that is less than the modern bar I would personally

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

This is HTTP/1.1 pipelining, which is supported by most browsers but typically disabled by default as most servers don't support pipelining correctly. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dumb thoughts for hardware backed keys for AEAD

ns of TLS using a key stored in an SGX enclave versus the same operations outside an SGX enclave? I'd be curious what the actual performance impact is. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] bikeshed: Forward Security or Secrecy?

On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk wrote: > The more common term is "forward secrecy" > I'd second this. I'm also a fan of Dan Bernstein's recommended term: "key erasure" -- Tony Arcieri __

Re: [TLS] Forward secrecy with resumption, and 0-RTT security

on't care. There's a simple enough way to solve that problem: rotate the session ticket key every few days. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

allow MD5 signatures even though this was not the case in previous TLS versions, or at least that was the claim of the miTLS presenters on SLOTH at RealWorldCrypto 2016. If this is the case, this seems like a big regression in TLS 1.2. -- Tony Arcieri __

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

TLS police to arrest the people who are ignoring the IETF RFCs and still shipping diediedie-filled crypto, but if we want any modicum of security want any sort of security guarantees from TLS, all stacks *MUST* abandon MD5 in its entirety. -- Tony Arcieri ___

Re: [TLS] Fixing TLS

3 can shed the cruft, OPTLS seems like a nice direction to go for "TLS 2.0" -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] JPAKE

On Mon, Feb 15, 2016 at 11:54 AM, Watson Ladd wrote: > PAKE in SSL has always been a solution in search of a problem. > Browsers do not have UI elements compatible with PAKE (unless someone cares to bring up the basic auth dialog, in which case I'd simply suggest please don't) Brian Warner's "Ma

Re: [TLS] JPAKE

actually be interested in using a PAKE in a generalized transport context would be an IPSEC/IKE context (in addition to a client cert as a second factor). -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] JPAKE

On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie wrote: > In Thread, it is used for local device authentication and authorisation. > These use cases clearly benefit from a PAKE, i.e. getting deriving a shared > cryptographic from a weaker shared password. > The better way to solve this problem is

Re: [TLS] JPAKE

. I personally believe the future of authentication is having a weak credential which unlocks a strong credential on something you have. This approach to authentication is generally described as "something you have and something you know" -- Tony Arcieri __

Re: [TLS] The future devices that will break TLS 1.4

On Sat, Jan 13, 2018 at 12:02 AM, Hanno Böck wrote: > > The question I want to ask: What can we do *now* to stop this from > happening when TLS 1.4 will be deployed? I have the feeling GREASE > won't be enough... Sidebar: TLS 4 ;)

Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13

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

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

y time in the next 5 years. There is lots of time to solve this problem and better ways to solve it than introducing codepaths which deliberately break the security of the protocol. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

using the CN). However, as an example, SPIFFE is a largely Kubernetes-focused identity system which encodes a "SPIFFE ID" in the client cert's subjectAltName and uses that to determine whether clients are authorized to continue a TLS connection: https://github.com/s

Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

eally helps to force things up a level out of the TLS handshake into something at the application level like an ACL language that lets you whitelist unauthenticated access to these resources. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Mail regarding draft-ietf-tls-tls13

ort / key encipherment (which lacks forward secrecy, among other problems). However, this is a property of how the protocol does key exchange / key agreement and has nothing to do with certificates. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www

Re: [TLS] Mail regarding draft-ietf-tls-tls13

thout any DH(E) algorithm whatsoever, and that is what is no longer supported in TLS 1.3. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

rchitectures. But it seems some people stuck on the Blue Coat model would rather make Internet security worse for everyone than invest in updating to a more modern approach. Enterprises can benefit from privacy just as much as individuals. However, not all enterprises within industry as a wh

Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

"unfortunate". There are no compelling practical reasons to continue to support the Brainpool curves. They are both redundant and obscure. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Drop "1.x" from future TLS version names?

4 => TLS 4 I bring this up so soon because I think a lot of the pushback regarding doing this before was due to changing the version so late in the development cycle. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Enforcing Protocol Invariants

suggestions are not improvements, they are regressions, or simply do not make sense. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ETSI releases standards for enterprise security and data centre management

decrypted traffic to resume decrypted sessions and thereby impersonate clients. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ETSI releases standards for enterprise security and data centre management

+-> Derive-Secret(., "res master", ClientHello...client Finished) = resumption_master_secret -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ETSI releases standards for enterprise security and data centre management

st obvious escrow design requiring no changes to the clients is to > use a static eDH key on the server-side. The next most obvious such > design is to have the server talk to the escrow agent. It seems like with an out-of-band escrow agent, the traffic secrets could be escrowed with no chan

Re: [TLS] ETSI releases standards for enterprise security and data centre management

t; take this work item back and solve it here in the IETF. > [...] > > On Dec 5, 2018, at 1:18 AM, Tony Arcieri wrote: > [...] > It seems like with an out-of-band escrow agent, the traffic secrets could > be escrowed with no changes to TLS. > > Note that the solution I was p

Re: [TLS] ETSI releases standards for enterprise security and data centre management

hich have come up in the past, including bugs in random number generation and bugs in the code in TLS stacks responsible for rotating ephemeral keys. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ETSI releases standards for enterprise security and data centre management

roviding a way for a passive observer to recover the *traffic* secrets, which would provide the ability to passively decrypt traffic (something I think is a bad idea, but I digress), but *NOT* resume observed sessions. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-dkg-tls-reject-static-dh

ar multiplication can be further optimized. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS Impact on Network Security draft updated

On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) < ncamw...@cisco.com> wrote: > Hi, > > Thanks to all the feedback provided, we have updated the > https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04 > > draft. At this point, we believe the draft is stable and would like to > r

Re: [TLS] RSA-PSS in TLS 1.3

utiny new attacks will be found. I think we need to define hybrid pre/post-quantum key exchange algorithms (e.g. ECC+Ring-LWE+HKDF), and that sounds like work better suited for the CFRG than the TLS WG. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org htt

Re: [TLS] Include Speck block cipher?

On Thu, Mar 17, 2016 at 6:37 PM, Mike Hamburg wrote: > No. The goal should be to remove ciphers, not add new ones, unless we > have a really compelling reason. > +1 -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.or

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett wrote: > Frankly, I think this document should be renamed "Extended Support > Profile", rather than "Long-term Support Profile" (and ESP instead of LTS). Legacy Support Profile? Then you don't have to chang

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

On Monday, March 21, 2016, Dave Garrett wrote: > I don't exactly see a 'T' for "LTS" in "Legacy Support Profile"... ;) > Haha, oops. LSP? -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

bile network deployment isn't ubiquitous on planet earth and mobile clients constantly go offline and back online several times throughout a day on average. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

e team "can't wait to TLS 1.3-ify" over QUIC, specifically reasons different from the ones I have already highlighted above? -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

etter > wording for this specific paragraph? > I think "nonce" meaning number used once is fine for cryptographic purposes. I'd also note Adam Langley has taken to pronouncing the word nonce as "n-once", at least at this year's RWC. -- Tony Arcieri

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

give that award to F5 BIG-IP devices -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS client puzzles

On Wednesday, July 6, 2016, Salz, Rich wrote: > Do IoT devices generally talk to public-facing web servers? > Yes, I'd consider that part of the "Internet" aspect of "Internet of Things" -- Tony Arcieri ___ TLS

Re: [TLS] RSA-PSS in TLS 1.3

natures in TLS 1.3. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

On Monday, August 8, 2016, Martin Rex wrote: > > The urban myth about the advantages of the RSA-PSS signature scheme > over PKCS#1 v1.5 keep coming up. > Do you think we'll see real-world MitM attacks against RSA-PSS in TLS similar to those we've seen with PKCS#1v1.5 signature forgery, such as BE

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

aid of BER in BERserk, and it was clearly the bigger of the two problems). Peter Gutmann's response was the sort of thing I was looking for when I originally asked the question. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

It's also worth noting that BERserk is one of many such incidents of this coming up in practice: https://cryptosense.com/why-pkcs1v1-5-signature-should-also-be-put-out-of-our-misery/ On Tue, Aug 9, 2016 at 2:13 PM, Tony Arcieri wrote: > On Tue, Aug 9, 2016 at 7:16 AM, Martin Re

[TLS] 3DES diediedie

.1(?) but I think it would make sense for it to be banned from TLS 1.3. [*] Lest anyone claim the contrary, I am not surprised by this attack, and have pushed to have 3DES removed from TLS prior to the publication of this attack, and can probably find a TLS implementer who can back me up on tha

Re: [TLS] [Cfrg] 3DES diediedie

3DES's usage in TLS, given its previous MTI status in TLS, and because it was until very recently included in the OpenSSL "DEFAULT" ciphersuite list. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

It appears 3DES is not supported in TLS 1.3. I would still support a "diediedie" RFC banning its use in previous versions of TLS, despite its previous MTI status. On Wed, Aug 24, 2016 at 7:34 PM, Tony Arcieri wrote: > On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk wrote: > &

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, Aug 24, 2016 at 7:41 PM, Stephen Farrell wrote: > On 25/08/16 03:34, Tony Arcieri wrote: > I guess there's sometimes value in those die-die-die RFCs. Given that > we have RFC7525/BCP195 [1] that already has a SHOULD NOT for effective > key sizes less than 128 bits, one

Re: [TLS] 3DES diediedie

attacks work across multiple session keys, whereas SWEET32 requires the same key, but I think the practical consequences regarding data volume limits are similar. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

ypto primitives on chips that meet the specifications you're describing. The payments industry has definitely shown it's possible. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

On Thu, Sep 8, 2016 at 8:01 AM, Derek Atkins wrote: > So they are finally up to 80-bit security? Woohoo! > That makes me feel so safe. > 1024-bit RSA is certainly less than ideal, but certainly better than nothing, which was the claim about devices in this class. Comparisons with symmetric cry

Re: [TLS] Industry Concerns about TLS 1.3

, etc. tl;dr: your suggestions would harm the security of more "forward thinking" payments companies. Again, my personal opinion, not that of my employer. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

so I can ensure for the safety of my own money that I do not use them? -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

he voiced concerns are not representative of "enterprise", "industry", or "payments" as a whole, but an last-minute opinion of companies who haven't been paying attention to the process who do not want to invest in upgrading their security practices

Re: [TLS] Industry Concerns about TLS 1.3

ms for these companies, rather they seem to be attempting to futureproof their current bad practices. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

s. I think what you're proposing is actively harmful to Internet security and you should be working with the PCI Council, not the IETF, to address your concerns. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

I am a big fan of leaving it as TLS 1.3. It feels more like evolution than revolution, even with the addition of 0-RTT. I would like to see a future TLS 2.0, but one that makes fundamental changes which didn't make the cut for 1.3, e.g. moving to OPTLS. -- Tony Ar

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

al bit of errata everyone needs to learn if they ever encountered the "TLS 1.3" version in any of these materials. And I think the whole SSL/TLS thing is errata enough. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

e consulting this body of work will have to contend with. You will no doubt disagree, so I'm simply saying it for posterity: keeping the version TLS 1.3 is the least confusing option, IMO. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

eave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. I guess we're at the deadline, but I have a compromise I think makes sense: - Keep this version TLS 1.3 - For the next version of TLS, drop the 1.x

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

n to me as far as reducing these sort of mental gymnastics goes is to keep the version as "TLS 1.3" and drop the 1.x in the next release. This gets the "TLS 4" advocates what they want, just not right away, without renaming the current release at the last minute. -- Tony Arcieri

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Option C is more similar to option A, but not an improvement, IMO. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

I was one of the people arguing my hardest against the BITS Security proposal to continue to (ab)use RSA static keys to allow passive MitM, even though TLS 1.3 had already moved forward on what I would call a more modern protocol design of the sort I believe payments companies should embrace to imp

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

On Sat, Jul 8, 2017 at 8:44 AM, Stephen Farrell wrote: > On 08/07/17 16:39, Tony Arcieri wrote: > > Clearly there are echoes of the scary protocols of yesteryear, i.e. > > Clipper/LEAP. I think if you visit Matt Green's Twitter page and check > the > > image header

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

a preshared KEK as opposed to exfiltrating the DH private key? -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

fferent than the mandatory key escrow used > in the Clipper Chip. > It enables the same ends: recovery of session plaintexts, and as I stated on other threads I would personally prefer a more explicit key escrow mechanism implemented as a TLS extension, which to some degree would actually l

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

ource of confused deputy vulnerabilities: http://www.hpl.hp.com/techreports/2009/HPL-2009-20.pdf This is why I have been such a strong proponent of using something like a TLS extension for this sort of thing if it is to happen. At least that way we get mutual client and server co

Re: [TLS] WG adoption call: SNI Encryption

ad balancer versus a backend service, while still eventually negotiating an end-to-end encrypted session with the backend service. I wonder if the draft should be framed around the TLS-in-TLS tunneling mechanism, with encrypted SNI as a potential use case. -- Tony Arcieri ___

[TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

se case in addition to the reverse-proxy case [1]: https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ [2]: https://www.rfc-editor.org/rfc/rfc2817.txt [3]: https://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-01 -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

ed places who have run Squid this way in the past. CONNECT is widely supported enough to mostly make this work, but I think things could be... much better than they are. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

ils, I think they're worth at least considering when such a draft is being authored. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: SNI Encryption

S loophole is closed" scenario for SNI encryption. I am all for tunneling as a general WG item, but I think framing the discussion specifically in terms of SNI encryption is missing the forest for the trees. -- Tony Arcieri ___ TLS mailing list TLS@ietf

Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

onsidered from more angles than one. If TLS contains (mis)features which forbid anonymous speech or censor unapproved information sources, I'm afraid that the ship has already sailed there. But perhaps, well-implemented TLS tunnels could ultimately help route around censorship. -- Tony Arcieri

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

y only requires TLS 1.0. The deadline to switch to 1.1 or higher is 30 June 2018: https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

layed due to "industry" requirements / shortcomings. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill wrote: > Those advocating for some standardized method of subverting the security > properties of TLS have been offered numerous options in good faith, and > continue to reject them all. I’m aware of extremely large enterprises that > in fact require

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

erm “MitM” for a passive network observer, particularly one which can decrypt traffic, is perfectly apt. > -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Reviving draft-zauner-tls-aes-ocb?

d OCB, and if it does, if there are other concerns beyond those. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls