Andrei Popov wrote:
> I'm not happy with this either.
I liked that proposal.
The spec already says:
>
> "If the client supports only the default hash and signature algorithms
> (listed in this section), it MAY omit the signature_algorithms
> extension. If the client does not support the defau
Henrik Grubbström wrote:
> Martin Rex wrote:
>>
>> Nope, _our_ client is perfectly compliant by _not_ sending TLS extensions.
>> SCHannel is violating a MUST requirement, failing to properly process
>> a ServerHello without a TLS extension.
>>
>> http
Dave Garrett wrote:
> On Monday, July 13, 2015 10:30:06 am Martin Rex wrote:
>> Section 7.4.1.4 Hello Extensions and its subsections are clearly
>> IRRELEVANT for a client that does not use Hello Extensions.
>
> If you want to put it that way, sure, however they are N
Ilari Liusvaara wrote:
>
> E.g. if client advertised {sha256, ecdsa} + in its
> signature_algorithms and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> + others in its ciphersuites, then the server MAY pick
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and then proceed to
> sign the handshake with ECDSA/SHA-256.
Andrei Popov wrote:
>
> I think a good design is to have the client explicitly advertise any
> algorithms the client is willing/able to support, and for the server
> to honor the client's capabilities.
A good design provides robust interop and good backwards-interoperability,
and a reasonble defau
Eric Rescorla wrote:
> I'm not necessarily opposed to relaxing this requirement on the server,
> but given that:
>
> 1. SHA-1 is on its way out.
> 2. Future versions of TLS seem very likely to explicitly indicate which
> hash algorithms the clients support.
>
> I'm kind of confused about the prin
Viktor Dukhovni wrote:
> Andrei Popov wrote:
>>
>> Would it make sense for an opportunistic client to advertise all algorithms
>> commonly supported in the server certs? After all, there are relatively
>> few signature/hash pairs in use, and they are changing very slowly over
>> time.
>
> This do
Viktor Dukhovni wrote:
> Andrei Popov wrote:
>>
>> When old algorithms are deprecated and new algorithms replace them in
>> actual deployments (a very slow process), an opportunistic client would
>> need to be updated, just like a normal server-authenticating client does.
>> Except for the opportu
Tony Arcieri wrote:
[ Charset UTF-8 unsupported, converting... ]
> 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:
Florian Weimer wrote:
> * Viktor Dukhovni:
>
>> In that case, it should be said that a client MUST NOT advertise
>> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers
>> (or perhaps less restrictive at least one TLS 1.3 compatible cipher).
>
> Or the server should negotiate TLS 1.2
Andrei Popov wrote:
> Hi Ilari,
>
>>
>> What sort of usecase you have in mind for this?
>
> This is to support a fairly common website design where the landing
> page does not require client auth, but subsequent request to a
> protected resource triggers client authentication within an existing
>
Brian Smith wrote:
>
> There's no evidence that the presence or absence of an alert when a
> connection is closed makes any positive difference in the security of any
> non-secure fallback mechanism. Keep in mind that the alerts during the
> handshake are NOT authenticated, and the TLS threat mode
Salz, Rich wrote:
>
> At the TLS interim earlier this week, Brian Sniffen (from Akamai) started
> a proposal that makes SNI-encryption something that can be deployed and
> tested on the Internet in TLS 1.3. So we'll see if it gets used and works.
> The earlier slides notwithstanding, it's somethi
Martin Rex wrote:
> Salz, Rich wrote:
> >
> > At the TLS interim earlier this week, Brian Sniffen (from Akamai) started
> > a proposal that makes SNI-encryption something that can be deployed and
> > tested on the Internet in TLS 1.3. So we'll see if it gets
Eric Rescorla wrote:
> On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich wrote:
>>
>>> 1) We know CRIME threat, but it can not be risk for everyone.
>>> e.g., CVSS v2 Base Score: 2.6 (LOW)
>>
>> CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called
>> it 7.5
>>
>>> Which one is safer,
Eric Rescorla wrote:
>
> That is what the document says:
> "Versions of TLS before 1.3 supported compression and the list of
> compression methods was supplied in this field. For any TLS 1.3
> ClientHello, this field MUST contain only the ?null? compression method
> with the code point of 0. If a
Eric Rescorla wrote:
> Martin Rex wrote:
>> Eric Rescorla wrote:
>>>
>>> That is what the document says:
>>> "Versions of TLS before 1.3 supported compression and the list of
>>> compression methods was supplied in this field. For any TLS 1.3
Eric Rescorla wrote:
> Short, Todd wrote:
>>
>> However, for those ClientHello?s that support older versions, the
>> compression_method field may contain other values. This means that if a
>> TLSv1.3 client happened to support compression for TLSv1.2, it would be
>> unable to negotiate that via a
Joseph Salowey wrote:
>
> The chairs have read through this thread and do not see any new information
> that would cause the working group to reconsider the decision to remove
> compression from TLS 1.3.
I am (and I was) perfectly fine with removing compression from TLSv1.3.
(btw. our own implemen
Watson Ladd wrote:
>
> Why is it important that clients be permitted to signal support for
> compression and TLS 1.3 conditionally? Remember, we also want to phase
> out the use of compression in TLS 1.2.
compression in TLS is *NOT* generally bad, and not generally a problem.
It may be a problem
Matt Caswell wrote:
>
> Does anyone have any views on the below?
Yup. Interleaving application & handshake records is a
highly dangerous idea (and fortunately some TLS implementations
will abort if you try).
http://www.ietf.org/mail-archive/web/tls/current/msg07648.html
http://www.ietf.org/mai
Is the particular interop problem that you want to address
caused by a necessity to really process application data and
handshake data with arbitrary interleave,
or is it rather a problem of getting back into half-duplex operation,
i.e. a client being able to continue receiving application data
up
Eric Rescorla wrote:
> Dave Garrett wrote:
>
>> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
>>> https://github.com/tlswg/tls13-spec/issues/292
>>>
>>> Presently, RFC 4492 only specifies the EC points it can support in
>>> ServerHello, but does not let the server indicate which
Andrei Popov wrote:
>
> Then my argument would be: why send extra bytes in each ServerHello
> when TLS client auth is not used most of the time? In this case,
> CertificateRequest seems to be a better place.
I'm perfectly OK with the server _not_ sending/including a TLS extension
"Supported Ellipt
Viktor Dukhovni wrote:
> On Thu, Oct 22, 2015 at 06:40:25PM +, Salz, Rich wrote:
>>>
>>> Most applications want a simple API that hides all the complexities of
>>> TLS. If OpenSSL had done that, then it would be easy to see how enabling
>>> 1.2 won't cause problems for those apps which said "y
Martin Thomson wrote:
> On 21 October 2015 at 12:56, Viktor Dukhovni wrote:
>> Each peer MUST try to send a chain that matches an advertised
>> signature algorithm if it has a choice of chains, but otherwise
>> MUST send whatever it has.
>
> Do, or do not. There is no try.
>
> It's not like any
Matt Caswell wrote:
>
>
> On 12/11/15 08:23, Nikos Mavrogiannopoulos wrote:
> > On Wed, 2015-11-11 at 18:39 +, Mike Bishop wrote:
> >
> >> I know that BoringSSL explicitly requires that application data flow
> >> be stopped during renegotiation. If the HTTP working group adopts
> >> this dra
Yoav Nir wrote:
>> Peter Gutmann wrote:
>>
>> Eric Rescorla writes:
>>>
>>> The concern here is backward compatibility with inspection middleboxes which
>>> expect the length field to be in a particular place.
>>
>> Given that the rest of TLS 1.3 is going to break compatibility with pretty
>>
Viktor Dukhovni wrote:
> On Thu, Nov 19, 2015 at 12:05:55PM +1000, Michael Gray wrote:
>
> > > With several TLS implementations it is possible to completely seperate
> > > network communication (of the application) from the processing of
> > > TLS records (performed by the TLS protocol stack). Fo
Eric Rescorla wrote:
>
> There are presently four categories of cipher suites vis-a-vis TLS 1.3.
>
> 1. MUST or SHOULD cipher suites.
> 2. Standards track cipher suites (or ones we are making ST, like
> the ECC ones).
> 3. Non standards track cipher suites
> 4. Cipher suites you can't use at a
Jacob Appelbaum wrote:
>
> I hope that we'll hide the SNI data by default and I understand that a
> discussion about encrypted SNI is currently scheduled for some point
> in the future.
Hiding SNI data is completely silly security-wise, and any TLSv1.2
backwards-compatible ClientHello must includ
Jacob Appelbaum wrote:
> On 12/2/15, Martin Rex wrote:
>>
>> So your client will have to know a-priori, out-of-band or be configured
>> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello
>> with cleartext SNI.
>
> I think that is false. On
Jacob Appelbaum wrote:
>>
>>> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less
>>> secure
>>
>> That is a myth.
>
> Are you asserting that TLS 1.3 will be less secure or equally secure here?
Even TLSv1.0 is sufficiently secure already, so that there
are plenty of other attack su
Software Engineer 979 wrote:
>
> I'm currently developing an data transfer application using OpenSSL. The
> application is required to securely transfer large amounts of data over a
> low latency/high bandwidth network. The data being transferred lives in a
> 3rd part application that uses 1 MB bu
Tony Arcieri wrote:
[ Charset UTF-8 unsupported, converting... ]
> Peter Gutmann wrote:
>
>> The vulnerabilities shown in the SLOTH paper were based on the fact that
>> implementations still allow MD5 for authentication/integrity protection,
>> even if (for example) it's explicitly disabled in th
Salz, Rich wrote:
>
>> TLS needs an LTS version that you can just push out and leave to its own
>> devices
>
> So don't you have that with TLS 1.1 and appropriate cipher and option choices?
Actually, you already have that with TLSv1.0 plus the known mitigations.
The only cryptographical improve
Ilari Liusvaara wrote:
>
> Peter Gutmann wrote:
>
>> Salz, Rich writes:
>>
TLS needs an LTS version that you can just push out and leave to its own
devices
>>>
>>>So don't you have that with TLS 1.1 and appropriate cipher and option
>>>choices?
>>
>> Based on the feedback I've had, I'm
Ilari Liusvaara wrote:
[ Charset UTF-8 unsupported, converting... ]
> On Thu, Jan 14, 2016 at 10:40:44AM +0100, Martin Rex wrote:
> > Ilari Liusvaara wrote:
> > >
> > > To actually fix the known problems with TLS 1.2, you would at minimum
> > > need a new extens
Ilari Liusvaara wrote:
> Martin Rex wrote:
>> Ilari Liusvaara wrote:
>
>>> Then there's also similar problems with RSA. And then RSA PKCS #1
>>> v1.5 encryption is on just about every "do not use!" list. Get it
>>> wrong (good luck getting it
Karthikeyan Bhargavan wrote:
>
> Yes Hugo, you?re right that when there is no client auth,
> the situation is less problematic.
I'm not so sure.
There might be the desire of the server to keep some data confidential,
and your argument is that if the data wasn't confidential to begin with,
the s
Watson Ladd wrote:
>
> But will they call tls_send_data_replayable?
The proper name would be tls_send_data_replayable_and_NO_forward_secrecy.
-Martin
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Salz, Rich wrote:
> Absolute lifetimes seem more robust; e.g., if you find one lying around,
> you don't have enough context to know if it's still good or not.
>
> We went from relative to absolute times in ACME for this reason.
What should be memorized/stored is absolute time-of-creation.
How l
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 "Obsolete
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 f
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 Authenticode
> spec actually mad
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 people cope with communicatin
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 know
Steve Fenter wrote:
>
> To clarify for anyone who has confusion on the enterprise TLS visibility
> use case, I think enterprises need to be able to do out-of-band decryption
> anywhere in the network that they own.
This is argument is so lame.
In Germany, monitoring communications between indivi
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 un
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 nego
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 t
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 compatibility
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
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),
>>
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 Octobe
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
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
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 resumptio
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. I'd
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 the
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 securi
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 does
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
>>>>
>>>>
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:
>>
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 a
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
Hanno Böck wrote:
> Joseph Salowey wrote:
>>
>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
>> offer). Clients can advertise support for PKCS-1.5 for backwards
>> compatibility in the transition period.
>> Please respond on the list on whether you think this is a reas
Hanno Böck wrote:
> m...@sap.com (Martin Rex) wrote:
>>
>> The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA
>> signatures is that one can clearly distinguish "wrong public key"
>> from "signature does not fit plaintext" error
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 ?ha
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 wi
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.
http://www.ietf
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/ rec
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 a
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 talk
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 in fundamentally bro
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&victim of the POODLE attack.
&g
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
Mike Bishop wrote:
>
> I assume you're referring to Section 3, SNI's ServerNameList MUST NOT
> contain more than one name of a given type?
>
> Or are you referring to the (lower-case) must not resume if SNI and the
> certificate used in the resumed session differ?
My (online) copy of rfc6066 has a
Martin Thomson wrote:
> On 21 July 2016 at 18:41, Martin Rex 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 proceeds with a full handshake
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 it
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
Viktor Dukhovni wrote:
>
>> On Jul 25, 2016, at 3:08 PM, Martin Rex wrote:
>>
>> specifically, after the FF update, this new TLS ciphersuite:
>>
>> security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256 (0xcc, 0xa9)
>>
>> was the only ECDSA cipher
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
Tony Arcieri wrote:
[ Charset UTF-8 unsupported, converting... ]
> 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
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 (rfc
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, peopl
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 sh
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 (i
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 using
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 suc
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 s
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 wor
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
Salz, Rich wrote:
> > I generally agree, though we just added one small exception to NSS, and
> > have been discussing another for a while now: Respecting client preference
> > for ChaCha over GCM makes a real difference for clients that don't have AES-
> > NI.
>
> Yes, a number of net companies
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 server
Kyle Nekritz wrote:
>
> After PR #625 all alerts are required to be sent with fatal AlertLevel
> except for close_notify, end_of_early_data, and user_canceled.
This list is already missing the warning-level "unrecognized_name" alert,
and such a change would imply that all new/unrecognized alerts a
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 curren
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
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 simplistically: same octets in EE A
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 to
1 - 100 of 154 matches
Mail list logo
