On Wed, Aug 17, 2022 at 11:34 AM Peter Gutmann
wrote:
> Kyle Rose writes:
>
> >IMO, the two requirements "Prohibit upgrades" and "Leverage
> general-purpose
> >network protocols with large attack surfaces" are in direct conflict.
>
> Only if you
On Wed, Aug 17, 2022 at 11:10 AM Peter Gutmann
wrote:
> See my earlier comments on this.
>
Honestly, it sounds like these devices maybe shouldn't be using internet
technologies that were designed with certain assumptions about
extensibility in mind. With such strong constraints not only on behav
On Sun, Aug 14, 2022 at 5:25 PM Hal Murray wrote:
> Thanks.
>
> > It's been a few years, but IIRC my thinking was that the degree of trust
> > required in the Roughtime servers' long-term public keys is very low:
> you're
> > trusting them only for one server's assertion of the current time, not
On Sat, Aug 13, 2022 at 11:16 PM Hal Murray wrote:
> > IIRC, this is one of the main arguments for advancing Roughtime:
>
> I took a look at draft 06. I don't see how it helps. Am I missing
> something?
>
> Here is the key section:
>
> 6.4 Validity of Response
> A client MUST check the follow
On Wed, Aug 10, 2022 at 10:13 AM Peter Gutmann
wrote:
> So we're down to mostly non-web-PKI devices and/or the ten year problem, of
> which I've encountered the latter several times with gear that sits on a
> shelf
> for years and then when it's time to provision it all the certificates have
> lo
On Tue, Aug 9, 2022 at 12:40 AM Hal Murray wrote:
> I work on NTP software. NTS (Network Time Security) uses TLS.
>
> Many security schemes get tangled up with time. TLS has time limits on
> certificates. That presents a chicken-egg problem for NTP when getting
> started.
>
IIRC, this is one
On Fri, Dec 31, 2021 at 11:24 AM tom.ripe wrote:
>
> > I'd oppose any specification of new cipher suites without a good
> > justification, and I think this is an opinion many here share.
>
> And I just see an I-D for AEGIS-128L and AEGIS-256, albeit not for TLS.
> There seems to be no limit to
>
> I'm wondering what the backhaul traffic from CDN to Origin looks like,
> even if a user-agent request to the CDN used ESNI. I noticed that many CDNs
> provide client certificates.
>
Some origins do require client certificates, but not all. This is up to the
customer.
In TLS handshakes that us
I'm struggling to understand the issue you're raising.
There's typically nothing special about the CDN to origin TLS interaction.
If the origin supports ESNI, why couldn't it advertise that? The CDN node
could just pick it up like any other TLS client would.*
The one way in which CDN to origin in
Moving tls to bcc, and adding rfc-interest. (This is the kind of discussion
that is likely to ignite a dumpster fire, and it's not specific to TLS
work.)
On Mon, Aug 19, 2019 at 11:05 AM Watson Ladd wrote:
> I see no reason why English alone should be accepted for standards
> documents we refere
On Thu, Aug 15, 2019 at 10:17 AM Paul Yang wrote:
> Hi all,
>
> I have submitted a new internet draft to introduce the SM cipher suites
> into TLS 1.3 protocol.
>
> https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
>
Corresponding to changes in the IANA registry for TLS Cipher Suites
On Mon, Jul 24, 2017 at 10:33 AM, Paul Turner wrote:
>
>
> Of course, this is precisely the point. All your proposal does is
> complicate the process of sharing sessions with a third-party: it doesn't
> stop an endpoint from surreptitiously doing evil.
>
>
>
> Is the objective to have the protoco
On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen wrote:
> Ted Lemon writes:
>
> > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
> >> What I am trying to avoid is the ability to *surreptitiously* subvert a
> protocol that’s assumed to be secure.
> >
> > Yo
On Wed, Jul 19, 2017 at 4:02 PM, Ted Lemon wrote:
> Bear in mind that what we (or at least I) want out of not publishing a
> spec is that this technology not be present by default in TLS
> implementations. If someone wants to maintain a set of patches, there's
> not much we can do about it, and
On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon wrote:
> This is exactly right. We have a *real* problem here. We should
> *really* solve it. We should do the math. :)
>
Is there appetite to do this work? If we restrict this to two paths, one of
which is spending years designing and implement
I might want to try responding to the right thread. Apologies for the
noise. ;-)
Kyle
On Sat, Jul 15, 2017 at 9:08 AM, Kyle Rose wrote:
> I've rebased from the kernel master HEAD (4.12.0+), tested, and
> force-pushed the repository.
>
> Conveniently, it looks like, sinc
I've rebased from the kernel master HEAD (4.12.0+), tested, and
force-pushed the repository.
Conveniently, it looks like, since the last time I searched for one,
someone added an ECDH implementation to the kernel. That makes this a lot
easier.
Kyle
On Sat, Jul 15, 2017 at 8:18 AM, Kyle
On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins wrote:
> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
>
> Whether it justifies a loss of security is a separate question.
>>
>
> It isn't a loss of security - it's actually a net gain for security.
Security isn't a scalar quantity, so ther
On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell wrote:
>
>
> On 12/07/17 16:27, Kyle Rose wrote:
> > The telco in the POTS case isn't either endpoint. The third-party
> > surveillance is unknown to those endpoints. Therefore: wiretapping.
>
> Same in the wordpre
On Wed, Jul 12, 2017 at 11:18 AM, Stephen Farrell wrote:
> > If one endpoint is feeding
> > cryptographic material to a third party (the only way that information
> gets
> > out to the third party, vulnerabilities notwithstanding), they are
> > collaborating, not enabling wiretapping.
>
> That's
On Wed, Jul 12, 2017 at 10:38 AM, Ted Lemon wrote:
> On Jul 12, 2017, at 10:32 AM, Richard Barnes wrote:
>
> Oh, come on. You've never seen code in a library that implements
> something that's not in an IETF RFC?
>
>
> Of course I have. I think that putting a warning in the TLS 1.3 spec as
>
On Wed, Jul 12, 2017 at 10:22 AM, Ted Lemon wrote:
> On Jul 12, 2017, at 10:18 AM, Kyle Rose wrote:
>
> We need to dispel the myth that mere inaction on our part will on its own
> prevent implementation of these mechanisms, if for no other reason but to
> redirect energy to the
On Wed, Jul 12, 2017 at 8:57 AM, Ted Lemon wrote:
> The problem is that in modern times we can't assume that collaboration is
> consensual, so the rules in RFC2804 aren't as applicable as they were.
>
Until someone comes up with a technical countermeasure for involuntary
collusion, the solution
On Tue, Jul 11, 2017 at 9:11 AM, Ted Lemon wrote:
> It’s also true that you can just exfiltrate every key as it’s generated,
> but that’s not what’s being proposed and would not, I think, suit the needs
> of the operators who are making this proposal.
>
> I don’t see how you could mitigate agains
On Fri, Jul 7, 2017 at 2:21 PM, Stephen Farrell
wrote:
> I find it really hard to believe anyone is convinced of that.
>
> Yes, one could chose to use this proposed wiretapping scheme
> like that but figure 3 in the draft makes if fully clear that
> this colluding or coerced wiretapping device ca
On Sat, May 6, 2017 at 11:12 AM, Ilari Liusvaara
wrote:
> On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote:
> > I asked this question a while back, and didn't get a satisfying answer:
> if
> > an on-path attacker replaces the early data with a replay from an earli
On Sat, May 6, 2017 at 8:22 AM, Salz, Rich wrote:
>
> What about when **part** of a request is in the 0RTT part, and the rest
> of it isn’t? I believe this will happen often for H2 initial setup.
> Imagine the “fun” when initial connection data, such as login cookies, is
> replayed in other cont
On Tue, May 2, 2017 at 10:24 AM, Salz, Rich wrote:
> > it may be a naïve question, but is it still possible to define and
> standardize new cipher suites for TLS 1.2 as an RFC, when TLS 1.3 is almost
> finished?
>
> Yes it is. It might be "informational" not "standards-track" but it's
> certainl
On Apr 6, 2017 4:08 AM, "Fries, Steffen" wrote:
You are right, I did not take that option into account. But as you
mentioned, it is non-standard and with the desire is to be interoperable as
most as possible, proprietary enhancements are likely not to be favored.
>From a security standards pers
On Wed, Oct 12, 2016 at 3:57 PM, Eric Rescorla wrote:
> The 0-RTT traffic key incorporates the ClientHello.Random which is tied
> into the full handshake.
>
Ok, so for the replayed early data to be accepted, an adversary would also
have to swap out CH.Random and the (Finished) message, which wou
On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara
wrote:
> > There's my confusion. I misinterpreted both the Zero-RTT diagram and the
> > table of handshake contexts under "Authentication Messages", specifically
> > "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm
> > guessin
On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara
wrote:
> > By this point in the connection, there is proof that early_data has not
> > been replayed. The application doesn't necessarily know this when the
> early
> > data is first delivered, but it can find out later, which may be all that
> > s
On Wed, Oct 12, 2016 at 4:11 AM, Ilari Liusvaara
wrote:
> For when 0-RTT has become boring enough for me to implement, I would
> think the server-side interface I put in would be something like the
> following:
>
> - ServerSession::getReplayable0RttReader(alp_list) -> ZRttReader
> - ZRttReader::g
>
> The 0-RTT API in NSS allows a server to detect this transition. The
> problem that I think David was referring to is that the specific
> instant of the transition is lost when the multiple layers of stack
> that sit on top of TLS get involved.
>
To David's second paragraph, if we eventually a
On Mon, Oct 10, 2016 at 1:49 PM, Watson Ladd wrote:
>
> The problem is with poorly-behaved senders and attackers resending
> 0-RTT data. Receivers should be able to ensure side-effectfull
> operations are not carried out by 0-RTT data. Making 0-RTT silent in
> APIs transforms an interoperability
On Thu, Sep 22, 2016 at 1:19 PM, BITS Security <
bitssecur...@fsroundtable.org> wrote:
> Like many enterprises, financial institutions depend upon the ability to
> decrypt TLS traffic to implement data loss protection, intrusion detection
> and prevention, malware detection, packet capture and ana
To be honest, the purist in me likes the general idea here, though I think
I prefer "kex" as I'm used to that with SSH.
Then again, that isn't even quite correct, as the most popular mechanism is
DH, which is key agreement based on the exchange of inputs to a formula: no
keys are actually exchange
On Thu, Sep 8, 2016 at 12:04 PM, David Benjamin
wrote:
> The major arguments against this change seem to be:
>
> 1. It’s inelegant to have two mechanisms.
> 2. We should fix broken servers
>
There's also:
3. Implementors will find a way to screw this up, too.
But if you follow through with you
On Thu, Sep 8, 2016 at 12:46 PM, Yoav Nir wrote:
>
> Good questions, no doubt. But I don’t think they can be answered.
>
> Someone is going to specify protocols and algorithms. This could be the
> IETF. This could be the ITU, or IEEE, or some other SDO. Makes no
> difference.
> Someone is going t
On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann
wrote:
> The only data point I have is that every time I've tried to disable DES in
> a new release (and by DES I mean single DES, not 3DES) I've had a chorus of
> complaints about it vanishing.
...
> Alarms, for example, send data
> quantities mea
On Mon, Aug 29, 2016 at 5:00 AM, Hubert Kario wrote:
>
> we have enough problems weeding out implementation mistakes in TLS, we
> don't
> need yet another protocol and two dozen implementations that come with it
>
Strongly agreed.
Focusing energy on getting "something" working for low-power dev
> it's not IETF's fault that the implementers add unspecified by IETF
> restrictions and limitations to parsers of Client Hello messages or that
> they can't handle handshake messages split over multiple record layer
> messages, despite the standard being very explicit in that they MUST
> support t
On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara
wrote:
> > Tl;dr: I think this is a good approach because it eliminates much of the
> > existing negotiation redundancy/complexity and combinatorial explosion in
> > the 1.3+ ciphersuite menu.
>
> I recently tried to write code to handle this ciphe
On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla wrote:
> There have been a lot of discussions about whether we should try to
> refactor cipher-suite negotiation to be less monolithic in the cipher
> suite. I've generally been on the "no" side of that on cost/benefit
> grounds as well as not quite
On Fri, Jul 8, 2016 at 6:09 AM, Ilari Liusvaara
wrote:
>
> There is validity start time in there, the relative end time would
> be relative to that.
>
> That is, instead of saying "this is valid from t1 to t2", saying "this
> is valid from t to t+dt".
>
> No real perference either way, it was jus
On Thu, Jul 7, 2016 at 6:13 PM, Ilari Liusvaara
wrote:
>
> I also checked if one could do some funky stuff with credential lifetime
> notation to limit the lifetime. Nothing came up (apart for using 16-bit
> count in decaseconds (das) only allowing presenting lifetimes up to 7
> days, 14 hours, 2
> I agree, and I think it is clear that client puzzles can be a useful
> addition to the DDoS defense toolbox. However, most of this can be handled
> at the higher levels above TLS, or possibly as a custom extension that does
> not complicate TLS.
>
A custom extension is a promising approach: thi
On Wed, Jul 6, 2016 at 4:23 PM, Hannes Tschofenig wrote:
> the question for me is whether it will be an effective mechanism when
> many devices just do not support it (for a number of reasons)? For IoT
> devices the reason is simple: they don't have MBs of memory.
>
> Even the regular puzzle tech
On Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig wrote:
> I agree with Brian here on this issue. This is clearly impractical for
> IoT devices. For many of those devices we are talking about 32 KB (in
> total).
I continue to feel like this is a valid objection to the wrong proposition.
I don't
Let's finish that last sentence:
I have to think a lot more about the IoT/resource-constrained client
problem, but I still don't think the existence of clients that would be
denied service by this scheme renders the concept completely inapplicable.
___
T
On Wed, Jun 29, 2016 at 5:41 PM, Christian Huitema
wrote:
> On Wednesday, June 29, 2016 2:08 PM, Kyle Rose wrote:
> >
> > Raising the cost of requests has a similar problem in that you're
> punishing
> > every client, but in doing so you do allow all clients c
On Wed, Jun 29, 2016 at 3:25 PM, Brian Smith wrote:
> Dmitry Khovratovich wrote:
> > It allows cheap and memoryless verification by the server even though the
> > puzzle solving guaranteely requires dozens of MB of RAM from a client
>
> I feel like this is impractical simply because lots of peop
I'm a big fan of the idea of a very strict qualification suite, as well, to
try to head off some of these problems before (faulty) implementations
proliferate.
Hackathon?
Kyle
On Jun 7, 2016 2:00 AM, "Peter Gutmann" wrote:
> Dave Garrett writes:
>
> >Also, as with any new system, we now have t
>
> (1) In many cases, the client can handle this unilaterally. Are there
> examples of this kind of ticket-relevant state change that the client would
> not be aware of? When the client is aware of a state change (such as client
> auth negotiation), it can purge any tickets received before the sta
On Sat, Jun 4, 2016 at 1:15 PM, Eric Rescorla wrote:
> I don't think it's principally about discarding keying material, but
> rather about allowing the server to attach state to a ticket and then have
> predictable behavior. Consider the obvious case of post-handshake client
> auth (which I know
I've modified the branch to use your wording. As Viktor said, it
doesn't address his objection, but it's still a more precise starting
point for further discussion.
Kyle
On Thu, May 19, 2016 at 4:37 PM, Martin Thomson
wrote:
> On 19 May 2016 at 16:01, Viktor Dukhovni wrote:
>> Nevertheless, som
On Thu, May 19, 2016 at 3:19 PM, Viktor Dukhovni wrote:
> It is good enough. Clients that want strong protection against
> tracking by session ids can disable session caching entirely, or
> set an idle timeout of ~5 seconds, Ensuring that session re-use
> happens only for a quick burst of connec
On Thu, May 19, 2016 at 3:05 PM, Viktor Dukhovni wrote:
> I think this is much too complicated. Simpler solution is for
> clients (browsers and the like for which tracking is an issue) to
> not reuse sessions when their IP address changes
I don't think this is sufficient. Reusing session ticket
Ekr
>
> On Thu, May 19, 2016 at 11:19 AM, Kyle Rose wrote:
>>
>> Regarding the ability for passive observers' tracking of clients
>> across connections (and potentially across IPs) via a session ticket
>> used more than once, should there be any language aroun
Regarding the ability for passive observers' tracking of clients
across connections (and potentially across IPs) via a session ticket
used more than once, should there be any language around recommended
practice here, especially for clients?
An appropriately-configured server can help the client a
>> uint16 length = TLSPlaintext.length;
>
> You can't recover the plaintext without knowing how long it is. This
> part at a minimum needs to be in the clear. At which point you need
> it to be based on TLSCiphertext.length
Is that really true? You could decrypt the first block/few bytes
How about removing the RSA/ECDSA from the cipher suite, and making the
SigAlgs extension mandatory for connections requiring authentication?
That halves the number of cipher suites and eliminates an unnecessary
redundancy, while keeping the rest of the cipher suite negotiation
logic intact.
Kyle
>>Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems
>>like comparing apples, orangles, pears and kumquants.
>>
>>Even if the nominal strengths are the same, the scaling of strengths is going
>>to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH vs.
>>
I'd like to see the bits of the cipher suite associated entirely with
ephemeral data tied together roughly by security margin, to avoid
combinations that don't make sense (e.g., straw men of RSA384 + AES256
or AES256 + CRC32). This means: the type/size of the (EC)DHE group and
the symmetric cipher
64 matches
Mail list logo
