On Tue, Jun 14, 2022 at 11:14 PM Phillip Hallam-Baker
wrote:
>
> Hmm... looks like this is a piece of brokenness in the browsers.
I don't think client certs are a priority for Browsers. That would
significantly hinder support of interception, which is a browser
design goal under Priority of Const
On Tue, May 29, 2018 at 4:21 PM, Salz, Rich
wrote:
>>There's a tradeoff between respecting the official allocation processes
> and avoiding real-world breakage. I think we can all make our own
> assessments
> on the former, but for the latter, all the evidence we have so far is a
>
On Wed, Oct 25, 2017 at 12:21 PM, Roland Zink wrote:
> It could but RFC 7469 section 2.6
> (https://tools.ietf.org/html/rfc7469#section-2.6) says:
>
> " It is acceptable to allow Pin
>Validation to be disabled for some Hosts according to local policy.
>For example, a UA may disable Pin Va
On Sat, Oct 7, 2017 at 11:25 AM, Salz, Rich wrote:
>
>
>> I suggest we not have this debate now. We'll have a lot more data towards
>> the end of the month and we can have an informed discussion then.
>
> That is what I am asking for. More information so that the entire WG can
> make an informed
On Fri, Sep 22, 2017 at 9:15 PM, Martin Thomson
wrote:
> On Fri, Sep 15, 2017 at 8:42 AM, Jeffrey Walton wrote:
>> The current models uses origins as a boundary, so they are different
>> security contexts.
>
> That's not relevant here. A certificate allows a serv
On Wed, Sep 13, 2017 at 5:57 PM, Victor Vasiliev wrote:
> Currently, TLS 1.3 specification forbids resuming the session if SNI values
> do not match. This is inefficient in multiple cases, for example, if you
> have a wildcard domain cert, and the user is likely to visit multiple
> subdomains ove
On Tue, Jul 25, 2017 at 9:21 PM, Christian Huitema wrote:
> ...
> Not sure. I am looking at the implementations of QUIC. QUIC needs its own
> set of random numbers for things like connection ID or initial sequence
> number. The most natural thing to do is do get them from the OS API,
> /dev/random
On Sun, 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.
>
On Thu, Jul 20, 2017 at 9:35 AM, Robin Wilton wrote:
>...
> If I am analysing this correctly, there are two "tampering events" involved
> here.
>
> The first is: has someone tampered at the protocol/notification level to
> prevent the client from being notified that static DH is in use?
>
> The se
On Mon, Jul 17, 2017 at 10:23 AM, Blumenthal, Uri - 0553 - MITLL
wrote:
> And why are you unable to understand that that in the case of an
> additional layer of
> attacker-generated crypto nestled within a TLS tunnel, as you posited, that
> the ability
> to simply detect the presence of su
On Sat, Jul 15, 2017 at 1:58 AM, Salz, Rich wrote:
> Unless I missed the reply, I did not see any answer to my question as to why
> it must be opt-in. Do we think evildoers will tell the truth about what
> they are doing?
Opt-in is choice. Choice for a consumer is usually a good thing.
Sunlight
On Mon, Jul 10, 2017 at 3:37 PM, Stephen Farrell
wrote:
>
> And if coercion of a server to comply with a wiretap
> scheme like this stills fanciful to you, please check
> out the history of lavabit - had there been a standard
> wiretap API as envisaged here it's pretty certain that
> would have be
On Tue, May 2, 2017 at 9:45 PM, Colm MacCárthaigh wrote:
>
> On Tue, May 2, 2017 at 5:51 PM, Viktor Dukhovni
> wrote:
>>
>> .Some choices are driven by practical engineering considerations.
>>
>> The ticket lifetime is likely to be considerably longer than the
>> replay clock window. The server
On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner wrote:
> At IETF 97, the chairs lead a discussion to resolve whether the WG should
> rebrand TLS1.3 to something else. Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf.
>
> The consensus in
> PCI requirement providing Intrusion Detection at the entrance to Cardholder
> Data Environments as well as at critical points inside the Cardholder Data
> Environment. Intrusion Detection requires decryption of TLS. For some
> large, complex organizations this can be a large number of physic
> It seems wiser for Bob to somehow monitor or log what is being done with his
> own plaintexts at his own server. I know little about existing products to
> do this, but from my theoretical perspective, it ought to be easier than
> compromising forward-secrecy (logging ciphertexts).
+1. I worked
On Fri, Sep 23, 2016 at 5:34 PM, BITS Security
wrote:
>> you can keep using TLS1.2 in your internal network, can't you?
>
> There are both public and private sector regulators arcing towards being more
> prescriptive in this area. It is possible, if not likely, in the not too
> distant future t
> Look, pretty much the entire world is being spied on by national-scale
> adversaries who are recording all traffic for eventual decryption and
> correlation. *Almost everyone* is having their traffic surveilled. The
> problems of debugging a set of enterprise apps doesn’t amount to a hill of
On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael
wrote:
> From the perspective an Enterprise that runs these applications and has
> invested HEAVILY in the debugging networks.
>
> The reason we are debugging these networks is so that "The 5-6 order of
> magnitude of folks using them"
On Mon, Sep 12, 2016 at 8:10 PM, David Benjamin wrote:
> On Mon, Sep 12, 2016 at 7:35 PM Jeffrey Walton wrote:
>>
>> On Wed, Dec 9, 2015 at 8:02 PM, Salz, Rich wrote:
>> > OpenSSL just landed our chacha/poly implementation into master. We pass
>> > the
>>
On Wed, Dec 9, 2015 at 8:02 PM, Salz, Rich wrote:
> OpenSSL just landed our chacha/poly implementation into master. We pass the
> RFC test vectors, looking for other implementations to test against.
Sorry to dig up an old thread
I tested against Bernstein/ECRYPT ChaCha and test vectors from
> Here is an extract of the paragraphs dealing with TLS in the draft, so that
> you can easily see what to comment (wording improvement, missing stuff...).
>
>The point of COMPRESS as an NNTP extension is to behave as a
>transport layer, similar to STARTTLS [RFC4642]. Compression can
>
>> That being said, I would prefer the solution to be a compliance test suite
>> that checks if servers do handle correctly future versions, future
>> extensions and future ciphersuites correctly.
>
> I agree with Hubert. The big question is how you get the bug report to the
> server operator.
>
>
On Thu, May 5, 2016 at 10:49 AM, Stephen Farrell
wrote:
>
> Thanks all. I updated the RFC editor note to add the FIPS
> reference.
>
You might also consider mentioning the interop problems that are going
to occur when diverging from Bernstein's reference implementation. Its
already creating open
>> From the browser side of things, 0-RTT is a solution to a very real
>> problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RTT resumption)
>> and converting QUIC to use the TLS 1.3 handshake as a result.
>
> ...
> TCP in the works? (does TCPCT work on the client side?). Do you have any
On Sat, Mar 12, 2016 at 12:45 PM, Karthikeyan Bhargavan
wrote:
> Hi Kyle,
>
> In my talk at TRON, I was also concerned by potential attacks from allowing
> unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers should
> implement replay protection using a cache, but requiring clients t
On Thu, Dec 31, 2015 at 1:23 AM, Alyssa Rowan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2015-12-31 03:30, Adam Langley wrote:
>
>> I don't mind if the integration of curve25519 in TLS requires a
>> zero-check or not, but what property are people hoping to gain? If
>> one wa
>> An even more executive-level lesson might be that security layers should
>> not provide non-security services, but that is not really convincing because
>> if there was a separate compression layer that you could compose with the
>> security layer in TLS, CRIME would still be possible. To compre
> I have to wonder if it’s worth it. In the last decade bandwidth has increased
> and prices for networking have gone down much faster than CPU speeds. 10
> years ago having 1 Mbps at home was the highest-end broadband you could get.
> Now you routinely get 100x that. CPU has increased, but now
>> It's a profile. Call it what you will. The rest of us call this a
>> profile. All the more so when profiles are named in an IANA registry.
>> Applications can then very trivially select an appropriate TLS profile
>> using standard profile naming.
>
> Yeah, we don't need to argue semantics. My
>> But IANAL (I Am Not A Lawyer)... I *can* understand vendors who would hold
>> until either an explicit IPR release is posted, or the (potentially!)
>> relevant patents expire.
>
> Then those hypothetical people should use RSA signatures and FFDHE key
> exchange
>
Ah, but they are not hypothetica
On Tue, Sep 1, 2015 at 1:16 PM, Dave Garrett wrote:
> On Tuesday, September 01, 2015 11:24:59 am Jeffrey Walton wrote:
>> Regarding "who would actually use it": folks in US Federal (and those
>> doing business in US Federal) don't have the choices that others have.
&
>> > > Also, if DSA was to be supported, one would need to specify how to
>> > > determine the hash function (use of fixed SHA-1 doesn't fly). And
>> > > 1024-bit prime is too small.
>> >
>> > FIPS186-4
>> > (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
>> > partially remediates the i
>
> Also, if DSA was to be supported, one would need to specify how to
> determine the hash function (use of fixed SHA-1 doesn't fly). And
> 1024-bit prime is too small.
>
FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
partially remediates the issue. DSA now includes 2048 and
On Wed, Jul 22, 2015 at 9:39 PM, Dave Garrett wrote:
> Hubert Kairo found quite a few more spots in need of explicit error
> designations, which have been amended into PR #201.
> https://github.com/tlswg/tls13-spec/pull/201
>
> I just noticed one error in the current draft text that was wrong and
>>This is possible, but you’d need to have the client and server negotiate
> based on
>>what they have. For example, if the server has a SRP verifier from the
> current
>>protocol, but the client has a stored PBKDF2 hash of the password for that
> server,
>>they cannot communicate and would need t
>> (I've been through C&A's where matching security levels were examined).
>
> An auditor who believes that we can rigourously quantify the security
> of these curves precisely enough to say which is stronger or more
> closely "matches" AES-256, should be laughed out of the room and fired.
>
Maybe
On Wed, Jul 15, 2015 at 11:48 PM, Tony Arcieri wrote:
> 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
>> >> So, should it stay or should it go now? Opinions?
>> >
>> > +1 that sect571r1 be removed.
>>
>> I also believe that it should be removed.
>
> Same here, I think in this case "less is more". There is no
> compelling reason for this curve, and needless diversity here is
> counter-productive.
>
> It seems prudent to keep some diversity of the gene pool and not only have
> curves defined over prime curves. Similarly, one should perhaps have some
> diversity of gene pool criteria within the set of recommend curves and not
> only include special primes. Should some problem with a particular
40 matches
Mail list logo
