Re: [TLS] Last Call: (Deprecating MD5 and SHA-1 signature hashes in TLS 1.2) to Proposed Standard

The IESG wrote: > > The IESG has received a request from the Transport Layer Security WG (tls) to > consider the following document: - 'Deprecating MD5 and SHA-1 signature > hashes in TLS 1.2' > >as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits

Re: [TLS] TLS 1.3 Problem?

Michael D'Errico wrote: > > Since RFC 8446 obsoletes RFC 5246, this is a serious problem. > > How is this supposed to work?   Sorry but I did not follow the > development of TLS 1.3.  I felt that I was unwelcome in this > group by some of the "angry cryptographers" as I call them. The

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Hubert Kario wrote: > On Wednesday, 1 May 2019 01:49:52 CEST Martin Rex wrote: >> >> It is formally provable that from the three protocol versions: >> >> TLSv1.0, TLSv1.1, TLSv1.2 >> >> the weakest one is TLSv1.2, because of the royally stupid downgrade

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Hubert Kario wrote: > > there are attacks, like BEAST, that TLS 1.0 is vulnerable to that > TLS 1.1 and TLS 1.2 are not - that's a fact there are ciphersuites > that are invulnerable to Lucky13 and similar style of attacks that > can not be used with TLS 1.0 or TLS 1.1 - that's a fact BEAST is

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Hubert Kario wrote: > Martin Rex wrote: >> Hubert Kario wrote: >>> MD5 was deprecated and removed by basically every library >>> and can't be used in TLS 1.2, I specifically meant SHA1 >> >> MD5 deprecated ? Nope, glaring emtpy: >> htt

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Hubert Kario wrote: >On Wednesday, 8 May 2019 02:31:57 CEST Martin Rex wrote: >> Hubert Kario wrote: >>>> Thanks to Peter Gutmann for the summary: >>>> https://mailarchive.ietf.org/arch/msg/tls/g0MDCdZcHsvZefv4V8fssXMeEHs >>>> >>>>

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Hubert Kario wrote: >> >> Thanks to Peter Gutmann for the summary: >> >> https://mailarchive.ietf.org/arch/msg/tls/g0MDCdZcHsvZefv4V8fssXMeEHs >> >> which you may have missed. > > yes, Joux paper also shows that attacking MD5||SHA1 is harder than attacking > SHA1 alone > > but that

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Hubert Kario wrote: > On Friday, 3 May 2019 16:56:54 CEST Martin Rex wrote: >> Hubert Kario wrote: >> > We've been over this Martin, the theoretical research shows that for >> > Merkle- Damgård functions, combining them doesn't increase their security >

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Hubert Kario wrote: > > We've been over this Martin, the theoretical research shows that for Merkle- > Damgård functions, combining them doesn't increase their security > significantly. You are completely misunderstanding the results. The security is greatly increased! Nobody is afraid of

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Martin Thomson wrote: > On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote: >> The sound-bite version is: first raise the ceiling, *then* the floor. > > Yep. We've done the ceiling bit twice now. > Once in 2008 when we published TLS 1.2 and then in 2018 > with the publication of TLS 1.3.

Re: [TLS] Further TLS 1.3 deployment updates

Nico Williams wrote: > On Wed, Dec 12, 2018 at 04:21:43PM -0600, David Benjamin wrote: >> We have one more update for you all on TLS 1.3 deployment issues. Over the >> course of deploying TLS 1.3 to Google servers, we found that JDK 11 >> unfortunately implemented TLS 1.3 incorrectly. On

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

Geoffrey Keating wrote: > Viktor Dukhovni writes: >> >> TL;DR: Should TLS client abort DHE-RSA handshakes with a peer >> certificate that *only* lists: >> >> X509v3 Key Usage: >> Key Encipherment, Data Encipherment > > Yes, because in DHE-RSA, the RSA key is used

Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

Eric Rescorla wrote: > Martin Rex wrote: > > > Sean Turner wrote: > > > > > > This is the working group last call for the > > > "Issues and Requirements for SNI Encryption in TLS" > > > draft available at > > > http://datatrack

Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

Sean Turner wrote: > > This is the working group last call for the > "Issues and Requirements for SNI Encryption in TLS" > draft available at > http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. > Please review the document and send your comments to the list > by 2359 UTC on 31

Re: [TLS] [CAUTION] Re: Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

m...@sap.com (Martin Rex) wrote: > Andrei Popov wrote: >> >> On the recent Windows versions, TLS 1.0 is negotiated more than 10% >> of the time on the client side (this includes non-browser connections >> from all sorts of apps, some hard-coding TLS versions), >&

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

Andrei Popov wrote: > > On the recent Windows versions, TLS 1.0 is negotiated more than 10% > of the time on the client side (this includes non-browser connections > from all sorts of apps, some hard-coding TLS versions), > and TLS 1.1 accounts for ~0.3% of client connections. "On recent Windows

Re: [TLS] Broken browser behaviour with SCADA TLS

Peter Gutmann wrote: > > (I have no idea about the prevalence of IE vs. others, but since it's the > default browser for Windows I assume this will be the easiest/recommended path > fowards, and until Windows 10 MS had a long history of being excruciatingly > careful about backwards

Re: [TLS] Broken browser behaviour with SCADA TLS

Martin Thomson wrote: > > The problem with DHE of course being that it uses the TLS 1.0 suites > with the SHA1 MAC and with the MAC and encrypt in the wrong order. I'm confused about what you are thinking here. In TLSv1.0 through TLSv1.2 inclusive, all of the TLS handshake messages, including

Re: [TLS] Broken browser behaviour with SCADA TLS

Peter Gutmann wrote: > David Benjamin ? writes: > >>The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit >>minimum. (Chrome enabled far more DHE ciphers than others, so we encountered >>a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95% >>of DHE

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

Ben Personick wrote: > > (My apology for the long email, I did not have time to write a shorter one) > We are currently evaluating when to begin offering ECC Certificates > based cypto on our websites. > > Despite the advantages to doing this in TLS 1.2, there is a lot of > push-back to wait

[TLS] Network middlebox corrupting TLS session resumes

Hi, During the analysis of a recent customer support call, I determined from a wireshark/network trace that the cause of unexpected failures of TLS session resumption handshakes were caused by some broken network middlebox, which allegedly was configured for "SSL inspection". I would like to

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

Ilari Liusvaara wrote: > On Fri, Dec 15, 2017 at 07:33:44PM +, Tim Hollebeek wrote: >> >> However, servers are easier to upgrade than clients, which is why you see >> some of the server side support you mention. I know CloudFlare in >> particular helped a lot of

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

Tim Hollebeek wrote: > Because it's easier for the client to decide what the client understands > than it is for the server to decide what the client understands. Less > complexity = less failures. > > Note that this is how XP was handled for code signing. The

[TLS] editorial error in draft-ietf-tls-rfc4492bis-17

I just noticed a strange inconsistency in section 6 of draft-ietf-tls-rfc4492bis-17 https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17#section-6 The last of the "must implement 1 of these 4" list of cipher suites at the end of section 6 is not contained in the table at the beginning of

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > > On 10/10/2017 10:52 AM, Martin Rex wrote: >> Nope, none at all. I'm _not_ asking for protocol changes, just that >> the TLS handshake continues to end with CCS + HS, and ContentTypes >> remain visible. Cont

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Ilari Liusvaara <ilariliusva...@welho.com> wrote: [ Charset UTF-8 unsupported, converting... ] > On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote: >> >> Fixing the backwards-incompatibilities in the TLS record layer >> would be terribly useful for streaming-

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Ilari Liusvaara wrote: > > And even if the changes might not be directly consequential to > security, the changes to get through some more annoying middleboxes > might be quite annoying to implement. > > E.g. there probably are several different middeboxes that have a >

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Eric Rescorla wrote: > > two options: > > - Try to make small adaptations to TLS 1.3 to make it work better with > middleboxes. Return to the proper TLSv1.2 record format with true ContentTypes (hiding them doesn't add any security anyways). With the needlessly broken

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

Ilari Liusvaara wrote: > On Tue, Sep 12, 2017 at 01:02:19PM +0200, Martin Rex wrote: >> >> A new TLS extension to convey acceptable signatures on certs would be >> needed, and for this, it would be preferable to pass along ASN.1 >> OIDs from AlgIds (not full AlgI

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

Eric Rescorla wrote: > > Generally, the idea with signature schemes is that they are supposed to > reflect both the capabilities of your TLS stack and the capabilities of > your PKI verifier [0]. So, yes, if you advertise this it is supposed to > work. So, ideally we would just say that it's as

Re: [TLS] 32 byte randoms in TLS1.3 hello's

Colm MacCárthaigh wrote: > Martin Rex <m...@sap.com> wrote: >> >> With RDRAND, you would use e.g. SHA-256 to compress 10*256 = 2560 Bits of >> a black-box CPRNG output into a 256-bit _new_ output that you >> actually use in communication protocols. > > I

Re: [TLS] 32 byte randoms in TLS1.3 hello's

Colm MacCárthaigh wrote: > Martin Rex <m...@sap.com> wrote: >> >> Since you also have no idea whether and how the internal hardware design >> behind Intel RDRAND is backdoored, you should not be using any of its >> output without an at least 10x cryp

Re: [TLS] 32 byte randoms in TLS1.3 hello's

Peter Gutmann wrote: > Christian Huitema writes: > >>On 7/25/2017 4:57 PM, Peter Gutmann wrote: >>> Are we talking about the same thing here? >> >>Not sure. > > OK, I'd say we are :-). This isn't about which PRNG or randomness source to > use but the need for a

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

Colm MacCárthaigh wrote: > > If you maintain that draft-green is Wiretapping, then that is also the > correct term for what is happening today. Today, operators are using a > static key, used on the endpoints they control, to decrypt traffic > passively. The only difference is DH vs RSA, and I

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

I'm sorry, Russ, but I think this would be seriously deceiving. Russ Housley wrote: > > If a specification were available that used an extension that involved > both the client and the server, would the working group adopt it, work > on it, and publish it as an RFC? > > I was listening very

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

Martin Rex wrote: > > There were a few issues with F5 loadbalancers (that were just forwarding > traffic, _not_ acting as reverse proxy) related to a borked F5 option called > "FastL4forward", which occasionally caused the F5 box to truncate TCP streams > (the box rec

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

I just watched the presentation on static DH / TLS decryption in Enterprise settings of todays TLS session https://youtu.be/fv1AIgRdKkY?t=4473 and I'm seriously appalled by the amount of cluelessness in the Networking & IT Departments on the one hand, and by what seems like woefully inadequate

Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

Ilari Liusvaara wrote: >On Wed, Jun 07, 2017 at 05:38:59AM +, Raja ashok wrote: >> Hi Victor & Alessandro, >> >> I have gone through the draft and I am having a doubt. >> >>> The extension only affects the Certificate message from the server. >>> It does not change the format of the

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

Watson Ladd wrote: >Martin Rex <m...@sap.com> wrote: >> >> The suggestion to accept a recognized TLSv1.2 cipher suite code point >> as an alternative indicator for the highest client-supported protocol >> version is not really a "mechanism". It's efficie

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

Eric Rescorla wrote: > On Tue, May 23, 2017 at 9:34 PM, Martin Rex <m...@sap.com> wrote: >> >> This change _still_ prohibits the server from negotiating these algorithms >> with TLSv1.1 and below. >> >> Could you elaborate a little on where and why you see a

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

Adam Roach wrote: > draft-ietf-tls-ecdhe-psk-aead-04: No Objection > > -- > COMMENT: > -- > > I agree with EKR's discuss -- specifying semantics for these

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

It seems I had a typo in the new text. Martin Rex wrote: > Eric Rescorla wrote: >> draft-ietf-tls-ecdhe-psk-aead-04: Discuss >> >>

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

Eric Rescorla wrote: > draft-ietf-tls-ecdhe-psk-aead-04: Discuss > > -- > DISCUSS: > -- > > The following text appears to have been added in -04 > >A

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

Benjamin Kaduk wrote: > > Some other editorial nits follow. > > In section 4, "these cipher suites MUST NOT be negotiated in TLS > versions prior to 1.2" should probably clarify that "these" cipher > suites are the new ones specified by this document. This reminds me of the specification goofs

Re: [TLS] trusted_ca_keys

Salz, Rich wrote: [ Charset UTF-8 unsupported, converting... ] > > The organization info (O, L, ST, C, etc...) is supposed to differ in that > > case (CN > > is just one field of DN), rendering the full DNs distinct. > > But where and how is that enforced, or enforceable? Again, any links to

Re: [TLS] trusted_ca_keys

Salz, Rich wrote: [ Charset windows-1252 unsupported, converting... ] > > There is some wording in PKIX and X.509 which creates the impression that a > > CA could be re-using the same Subject DName with different keys, but such > > an interpretation is a formally provable defect of the PKIX

Re: [TLS] trusted_ca_keys

Salz, Rich wrote: > >> The certificate should have its own DN, use that. > > She's saying that it *doesn't.* > > SubjectDN is not unique. IssuerDN/Serial is unique, but this extension use > that. SubjectDN of a *Certificate Authority* **MUST** be unique. There is some wording in PKIX and

Re: [TLS] TLS RSA-PSS and various versions of TLS

Dr Stephen Henson wrote: > On 25/04/2017 15:36, Benjamin Kaduk wrote: >> >>RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA- >> PSS [RFC3447 ] with mask >> generation function 1. The digest used in >> the mask generation

Re: [TLS] Alert after sending ServerHello

Ilari Liusvaara wrote: >> In effect, we assume that the entire flight is processed atomically >> and generate errors based on that. Only when the entire flight is >> processed cleanly do we install keys and respond. > > My implementation processes message-by-message. So it installs the > client

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Michael StJohns wrote: > Martin Rex wrote: >> oops, typo: >> >> Martin Rex wrote: >>> Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com >>> I'm a little confused. >>> >>> This is the cert chain (as visual

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

oops, typo: Martin Rex wrote: > > Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com > I'm a little confused. > > This is the cert chain (as visualized by Microsoft CryptoAPI): > > server-cert: CN=cloudflare.com, ... > contain

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Viktor Dukhovni wrote: > > > On Mar 24, 2017, at 1:08 AM, Martin Thomson > > wrote: > > > >> I've never seen > >> a TLS server that has multiple chains to choose from for the same > >> server identity. > [ https://www.cloudflare.com/ ] > > Both chains of course

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Viktor Dukhovni wrote: > > The net effect is that in practice you simply ignore the signature > algorithms when it comes to the certificate chain. Essentially correct. This is the only reasonable, highly backwards compatible and perfectly secure choice. > > I've never seen a TLS server that

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Eric Rescorla wrote: >> >> based on your reply my conclusion is that >> >> - there is no (standard compliant) way for a server to use a >> SHA256 based certificate for server side authentication in cases where the >> client does not provide the signature_algorithm extension > > Not quite.

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Fries, Steffen wrote: > > based on your reply my conclusion is that > > - there is no (standard compliant) way for a server to use a SHA256 > based certificate for server side authentication in cases where the > client does not provide the signature_algorithm extension The statement quoted by

Re: [TLS] RFC 6066 - Max fragment length negotiation

Peter Gutmann wrote: > Thomas Pornin writes: >> >>TLS 1.3 is moving away from the IoT/embedded world, and more toward a Web >>world. This is not necessarily _bad_, but it is likely to leave some people >>unsatisfied (and, in practice, people clinging to TLS 1.2). > > I would

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

Ilari Liusvaara wrote: > On Fri, Mar 10, 2017 at 09:25:41AM +0100, Martin Rex wrote: >> >> You don't understand the purpose of SNI and how the (already weak) >> rfc2818 section 3.1 server endpoint identification and CABrowser Forum >> public CA Domain validatio

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

Ben Schwartz wrote: > Martin Rex <m...@sap.com> wrote: > >>Ben Schwartz wrote: >>> >>> Like a lot of people here, I'm very interested in ways to reduce the >>> leakage of users' destinations in the ClientHello's cleartext SNI. It >>> see

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

Ben Schwartz wrote: > > Like a lot of people here, I'm very interested in ways to reduce the > leakage of users' destinations in the ClientHello's cleartext SNI. It > seems like the past and current proposals to fix the leak are pretty > difficult, involving a lot of careful cryptography and

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

David Benjamin wrote: > > Post-handshake auth exists basically entirely to service HTTP/1.1 reactive > client certificate which was previously hacked on via renegotiation. I > think we should not make this feature any more complicated than absolutely > necessary to support this mode, and we

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

I think the issue is more about the "principle of least surprise". The client needs to know whether it offered authentication by client cert and which client cert it offered. Whether the server accepted it, and caches the accepted cert in the session or in a session ticket, is the business of

Re: [TLS] Requiring that (EC)DHE public values be fresh

Adam Langley wrote: > > https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > specifies that (EC)DH values must be fresh for both parties in TLS > 1.3. > > For clients, this is standard practice (as far as I'm aware) so should > make no difference. For servers, this is not always

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

Christian Huitema wrote: > > I prefer TLS 1.3, because is signals continuity with the > ongoing TLS deployment efforts. As long as the awful hiding of the ContentType information in TLS Records remains in this protocol, it will *NOT* easily deploy as a replacement of TLSv1.2. I'm OK with TLS 4,

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Benjamin Kaduk wrote: [ Charset windows-1252 unsupported, converting... ] > On 11/09/2016 11:42 AM, Martin Rex wrote: > > Nobody so far has provide a single example of *REAL* value. > > For the hiding of ContentType to provide real value, the prerequisites are: > >

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Eric Rescorla wrote: > > I'm not quite following who's who in this scenario, so some potentially > stupid > questions below. > > As I understand it, you have the following situation: > > - A Web application server > - Some middleware, which comes in two pieces > - A crypto-unaware network

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Daniel Kahn Gillmor wrote: > > Martin Rex wrote: >> >> The problem here is that this breaks (network) flow control, existing >> (network socket) event management, and direction-independent connection >> closure, and does so completely without value. > >

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Yoav Nir wrote: > > On 3 Nov 2016, at 16:31, Martin Rex <m...@sap.com> wrote: >> >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. With the >> removal of rene

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Salz, Rich wrote: >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. > > Because it's kind of implied in the charter, about making as much private as > possible. > >> years), because it is actively

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Ilari Liusvaara wrote: >>> >>> Hiding the types does have its benefits (and it is also used for >>> zero-overhead padding scheme). >> >> Nope, ZERO benefits. But it totally breaks the middleware >> _at_the_endpoints_! > > Also, things like this should have been discussed like year or two >

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Ilari Liusvaara wrote: > Martin Rex wrote: >> Joseph Salowey wrote: >> >> There are two seriously backwards-incompatible changes in the >> current proposal that provide zero value, but completely break >> backwards-compatibility with existing middleware infr

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

If the server_name remains in plaintext and full sight in ClientHello (where it needs to be for TLSv1.2 backwards compatibility anyway), then I don't have an issue. (I'm sorry for not reading the draft in full). Eric Rescorla wrote: > >> (2) hiding of the TLS extension SNI. >> Right now it

Re: [TLS] SNI and Resumption/0-RTT

Kyle Nekritz wrote: > > I do think this should be allowed if the client is satisfied with the > previous identities presented. We currently allow resumption across > domains supported by our wildcard certificate (I believe this is fairly > common practice), and our clients take advantage of this

Re: [TLS] SNI and Resumption/0-RTT

Ilari Liusvaara wrote: > On Fri, Oct 21, 2016 at 11:41:59PM +1100, Martin Thomson wrote: >> On 21 October 2016 at 19:55, Ilari Liusvaara >> wrote: >>> Of course, defining the "same certificate" is >>> way trickier than it initially seems >> >> Not if you think

Re: [TLS] SNI and Resumption/0-RTT

Andrei Popov wrote: > > Perhaps it's OK to resume a session with a different SNI if in this > session the server has proved an identity that matches the new SNI. > In order to enforce this, the server would have to cache (or save in > the ticket) a list of identities it presented in each resumable

Re: [TLS] Deprecating alert levels

Kyle Nekritz wrote: > >> This list is already missing the warning-level "unrecognized_name" alert, >> and such a change would imply that all new/unrecognized alerts are going >> to be treated as fatal forever (i.e. that no new warning-level alerts >> can ever be defined). > > That alert is

Re: [TLS] CertficateRequest extension encoding

Geoffrey Keating wrote: > > A typical macOS system will have many issued certs, typically with at > most one that will work for any particular web site or web API. So > the filter is somewhat important for client certs to work there in any > kind of user-friendly way. In particular if the

Re: [TLS] Industry Concerns about TLS 1.3

Martin Rex wrote: > Stephen Farrell wrote: > > > > On 28/09/16 01:17, Seth David Schoen wrote: > > > People with audit authority can then know all of the secrets, > > > > How well does that whole audit thing work in the financial services > > indus

Re: [TLS] Industry Concerns about TLS 1.3

Stephen Farrell wrote: > > On 28/09/16 01:17, Seth David Schoen wrote: > > People with audit authority can then know all of the secrets, > > How well does that whole audit thing work in the financial services > industry? (Sorry, couldn't resist:-) I am actually having serious doubts that it

Re: [TLS] Industry Concerns about TLS 1.3

Judson Wilson wrote: > > I think this challenge is best solved by putting the information on the > wire in some way, possibly as a special industry-specific extension (used > only by those who are bent on shooting themselves in the foot). The benefit > being that if the TLS channel is alive, the

Re: [TLS] Industry Concerns about TLS 1.3

Pawel Jakub Dawidek wrote: > > Because of that, every corporate network needs visibility inside TLS > traffic not only incoming, but also outgoing, so they can not only > debug, but also look for data leaks, malware, etc. There may be a some countries with poor civil liberty protections where

Re: [TLS] Industry Concerns about TLS 1.3

Thijs van Dijk wrote: > > Regular clients, no. > But this would be a useful addition to debugging / scanning suites (e.g. > Qualys), or browser extensions for the security conscious (e.g. CertPatrol). With FREAK and LOGJAM attacks, there is a significant difference in effort between servers

Re: [TLS] Suspicious behaviour of TLS server implementations

My personal take on your questions: Andreas Walz wrote: > > (1) Several server implementations seem to ignore the list of proposed > compression methods in a ClientHello and simply select null compression > even if that has not been in the ClientHello's list. Sounds like reasonable behaviour

Re: [TLS] PR#625: Change alert requirements

Salz, Rich wrote: > > I've been reading this. > > I think we should get rid of the "abort" concept. There's a clean > shutdown and there's everything else which is an abrupt or unclean > closing of the connection. The "send alert" and "close connection" > concepts are separable and I think we

Re: [TLS] PR#625: Change alert requirements

Andrei Popov wrote: >>> the only popular stack I found that does not seem to send alerts is >>> the schannel from Microsoft > > To clarify, schannel does generate alerts per RFC, but the HTTP stack > (which actually owns the socket) sees no value in sending them. "Pillows don't hit people,

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

Tony Arcieri wrote: > > 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/ With the PKCS#1 v1.5 signature verification operation, as described in PKCS#1 v2.0

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

Tony Arcieri wrote: [ Charset UTF-8 unsupported, converting... ] > On Monday, August 8, 2016, Martin Rex <m...@sap.com> wrote: > > > > The urban myth about the advantages of the RSA-PSS signature scheme > > over PKCS#1 v1.5 keep coming up. > > Do you think

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

Hanno Böck wrote: > > Actually there is some info on that in the PSS spec [1]. What I write > here is my limited understanding, but roughly I'd interpret it as this: > It says that if you use a non-random salt the security gets reduced to > the security of full domain hashing, which was kinda the

Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

Viktor Dukhovni wrote: > >> On Jul 25, 2016, at 3:08 PM, Martin Rex <m...@sap.com> wrote: >> >> specifically, after the FF update, this new TLS ciphersuite: >> >> security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256 (0xcc, 0xa9) >> >> was the o

Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

Correction-- I'm sorry, I mistyped the firefox config, this should have said the chacha20_poly1305 (0xcc 0xa9) cipher suite was the only one enabled. Martin Rex wrote: > I've just run into a weird interoperability problem with an (alleged) > cloudflare/nginx TLS server and my personal F

[TLS] weird ECDSA interop problem with cloudflare/nginx

I've just run into a weird interoperability problem with an (alleged) cloudflare/nginx TLS server and my personal Firefox settings. https://regmedia.co.uk/2015/07/14/giant_weta_mike_locke_flicker_cc_20.jpg Traditionally I have all TLS ciphersuites with ECDSA disabled through about:config, but

Re: [TLS] HTTP, Certificates, and TLS

Martin Thomson wrote: > On 21 July 2016 at 18:41, Martin Rex <m...@sap.com> wrote: >>A server that implements this extension MUST NOT accept the request >>to resume the session if the server_name extension contains a >>different name. Instead, it pro

Re: [TLS] HTTP, Certificates, and TLS

Mike Bishop wrote: > > That means we now have a proposal for carrying both client and server > certificates above TLS, found at > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs. > > We have also discussed that it might be preferable to pull part of this > capability back

Re: [TLS] Thoughts on Version Intolerance

Hubert Kario wrote: > Martin Rex wrote: >> >> Forget TLS extensions, forget ClientHello.client_version. >> Both in fundamentally broken, and led to Web Browsers coming up >> with the "downgrade dance" that is target of the POODLE attack. >> >>

Re: [TLS] Thoughts on Version Intolerance

Hanno Böck wrote: Checking application/pgp-signature: FAILURE > Hubert Kario wrote: > >> so it looks to me like while we may gain a bit of compatibility by >> using extension based mechanism to indicate TLSv1.3, Forget TLS extensions, forget ClientHello.client_version. Both

Re: [TLS] Consensus call for keys used in handshake and data messages

Daniel Kahn Gillmor wrote: > On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote: >> wasn't that rejected because it breaks boxes that do passive monitoring >> of connections? (and so expect TLS packets on specific ports, killing >> connection if they don't look like TLS packets) > > We're

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

The IMO most reasonable way forward would be to side-step the TLS version negotiation through ClientHello.client_version entirely, because of the well-known interop problems. Simply use the presence of *ANY* TLSv1.2+ TLS cipher suite in the offered list of TLS cipher suites as an indication that

Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto

Salz, Rich wrote: >> In MinimaLT, the current ephemeral key for the server is added to >> the DNS record fetched during the DNS lookup. These entries expire fairly >> quickly, ensuring that old keys are never used. > > Can you compare the TTL of the ephemeral key record with the > A/

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Alexandre Anzala-Yamajako wrote: > > IMO, the layer creating the plaintext shouldn't have to pad it for security > that's the job of the TLS layer. Yep. And retrofitting random padding into TLS (all protocol versions, all PDUs) could be actually pretty simple and straightforward.

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Colm MacCárthaigh wrote: > > But I take the point that AEAD modes are harder for programmers to screw > up; and that does have value. Though it is a pretty flawed assumption. I've seen an AEAD cipher implementation fail badly just recently (resulting in corrupted plaintext that went unnoticed

Re: [TLS] RSA-PSS in TLS 1.3

Fedor Brunner wrote: > > Please see the paper "Another Look at ``Provable Security''" from Neal > Koblitz and Alfred Menezes. > > https://eprint.iacr.org/2004/152 > > Section 7: Conclusion > > "There is no need for the PSS or Katz-Wang versions of RSA; > one might as well use just the basic

  1   2   >