Thanks for this draft, i'm definitely interested in seeing it push
forward.
On Wed 2015-07-01 05:58:20 +0200, Viktor Dukhovni wrote:
> Instead, there would need to be in various cases:
>
> * A validated chain of CNAMEs (possibly synthesized via validated
> DNAME RRs) leading from the cli
On Thu 2015-07-09 15:43:16 +0200, Nikos Mavrogiannopoulos wrote:
> This draft uses the rfc6091 cert_type extension. If that is not
> intentional, rfc6091 was made obsolete by rfc7250 which uses the
> server_certificate_type and client_certificate_type extensions (even
> though the text doesn't men
On Tue 2015-08-11 19:59:35 -0400, Martin Thomson wrote:
> On 11 August 2015 at 16:38, Clemens Hlauschek
> wrote:
[ MT wrote: ]
>>> NSS (incorrectly) adopts the posture that _ECDH_ suites are
>>> half-static: the server share is in the certificate, but the client
>>> side is fully ephemeral. Thi
On Tue 2015-09-15 21:00:39 -0400, Joseph Salowey wrote:
> There has been some discussion to remove anonymous DH as described in
> https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think
> ekr's message sums up the pros and cons well. I don't think we have
> consensus on this issu
On Wed 2015-09-16 20:21:11 -0400, Viktor Dukhovni wrote:
> The difference between raw public keys (RFC7250 RPK) and anon is:
>
> - PRO: Dropping anon simplifies the implementation and reduces
> cipher count.
>
> - PRO: Raw keys may facilitate TOFU pinning.
>
> - CON: Raw keys are
On Wed 2015-09-16 13:48:27 -0400, Martin Thomson
wrote:
> On 16 September 2015 at 08:30, Ilari Liusvaara
> wrote:
>> As then the application needs to ensure that the authentication
>> occurs between TLS handshake and actually starting up the protocol.
>
> I'm not sure that is necessarily a prob
On Fri 2015-09-18 15:47:27 -0400, "Salz, Rich" wrote:
> Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression
> feature you need? What TLS 1.3 feature is compelling here?
I think this line of argument is worrisome -- we should try to avoid
leaving behind protocols that need TLS, i
Hey TLS folks--
apologies for the delay in sending these pull requests.
encrypted content type:
---
https://github.com/tlswg/tls13-spec/pull/51
This should be uncontroversial, and just needed freshening against the
current draft.
padding:
We're now proposing that
On Sun 2015-09-20 22:38:45 -0700, Karthikeyan Bhargavan
wrote:
> As dkg points out, dynamically authenticating clients later in the connection
> brings up
> API issues of how to notify the application about the scope of this new
> authentication event.
>
> I think it is inevitable that implemen
On Mon 2015-09-21 04:43:27 -0700, Watson Ladd wrote:
> Is this actually true in the second pull request? No: a moment of
> actually reading reveals that the string is inside an AEAD encrypted
> packet. There is no way in which this padding could be modified for
> use in a side-channel attack.
In
On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni
wrote:
> So the client would now need to cache some session data by transport
> address, and other data by name and port. That's rather complex.
This is already done by HTTP/2 clients, since they can access multiple
servers at the same address:p
On Fri 2015-10-02 11:24:10 -0400, Salz, Rich wrote:
>> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?
>
> They are equivalent. If you use AES-GCM and ECDHE, and you don't need 0RTT,
> then there is no compelling reason to use TLS 1.3.
...and you use session-hash, and you either do
On Fri 2015-10-02 12:24:24 -0400, Martin Rex wrote:
> The value of real padding is highly dependent of whether and how it
> will actually get used, and is far from automatic.
Sure, but we have no existing mechanism to do that in TLS 1.2 or
earlier. We need the mechanism before anyone can establis
Hi Yaron--
On Sun 2015-10-11 15:57:38 -0400, Yaron Sheffer wrote:
> We have a standard for certificate pinning (RFC 7469), but it is rather
> hard to use and as a result is rarely deployed. This draft proposes a
> lightweight alternative that allows TLS clients to authenticate the
> server they
On Mon 2015-10-12 09:18:17 -0400, Yaron Sheffer wrote:
> I'm not familiar enough with TACK at the moment. I can write something
> up, or if you'd like to contribute text, that'll be awesome.
i'm not up-to-speed yet either, and am unlikely to be able to get to
this soon, sorry!
> IMO persisting t
On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote:
> The concern here is backward compatibility with inspection middleboxes which
> expect the length field to be in a particular place. We agreed in Seattle to
> wait for early deployment experience before modifying the header to move
> the lengt
On Mon 2016-01-25 14:10:13 -0500, Yoav Nir wrote:
>> On 25 Jan 2016, at 5:08 PM, Salz, Rich wrote:
>>
>>> But any system running a TLS stack is already going to have a high quality
>>> entropy source for client/server randoms and IVs and such
>>
>> That's assuming a constraint that isn't accura
On Wed 2022-01-19 16:57:07 +0200, Yaron Sheffer wrote:
> * Add a SHOULD-level requirement (for TLS 1.3 implementations,
> possibly also TLS 1.2 implementations) to fail the handshake if the
> OCSP response is missing or invalid. (As far as we can tell, RFC 8446
> is silent on this.)
This sounds a
Hi Ryan--
I share your skepticism, but i'm still trying to salvage something
useful -- for the purpose of defending against CA malfeasance -- from
the mechanisms we have available.
On Thu 2022-01-20 23:51:22 -0500, Ryan Sleevi wrote:
> There are good reasons that clients have not, and potentially
On Fri 2022-01-21 15:23:56 +, Salz, Rich wrote:
> Second, there is the history of poor behavior by some CA's, which
> leads to the primary user agent (browsers, or perhaps TLS runtimes)
> not being able to just completely trust them. Perhaps that historic
> era has passed, and it is time for us
On Fri 2022-01-21 11:56:04 -0500, Viktor Dukhovni wrote:
>> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor
>> wrote:
>
>> Do you think that DNSSEC should be soft-fail for CAA checks, or should
>> we urge the CAs to be more strict here? Perhaps that would be another
On Mon 2022-01-24 13:06:13 +, John Mattsson wrote:
> I think another omission in RFC7525 that should be fixed in RFC7525 is
> a discussion on certificate life-times, which is often discussed
> together with revocation checking- Short-lived certificates is an
> improvement over long-lived certif
On Wed 2022-06-08 14:17:03 -0400, Sean Turner wrote:
> 1) Whether you are willing to review and contribute to this I-D, and
> 2) Whether you support adopting this I-D as a WG item.
>
> Please include any additional information that is helpful in understanding
> your position.
>
> [0] https://datat
On Thu 2018-03-01 21:52:51 +, Paterson, Kenny wrote:
> I think there's a possible timing attack on a naïve implementation of
> de-padding.
Thanks for observing this, Kenny! I think this came up when we were
designing the padding originally, and iirc, the general consensus was:
(a) this sche
On Thu 2018-03-15 20:10:46 +0200, Yoav Nir wrote:
>> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue wrote:
>>
>> I fail to see how the current draft can be used to provide visibility
>> to an IPS system in order to detect bots that are inside the bank…
>>
>> On the one hand, the bot would never o
On Sun 2018-03-18 12:08:13 -0400, Viktor Dukhovni wrote:
> The devices that might use external PSKs will likely be unavoidably
> fingerprinted by source IP address and the target mothership.
I'm not convinced that this is the case -- it's not at all clear that
IoT devices will be attached to a st
On Wed 2018-09-12 07:58:43 -0700, Christopher Wood wrote:
> https://ietf.webex.com/ietf/onstage/g.php?MTID=e02cf108b5a24e348e10132497d5def9
when i visit this, i get a page that says::
This link to the event is no longer valid.
This may be because the event has been cancelled, the event h
0496
UK +44.121.468.3154
US +1.512.402.2718
--dkg
> On Fri, Sep 14, 2018 at 10:05 AM, Daniel Kahn Gillmor
> wrote:
>
>> On Wed 2018-09-12 07:58:43 -0700, Christopher Wood wrote:
>> > https://ietf.webex.com/ietf/onstage/g.php?MTID=e02
Hi all--
I'm disappointed in how long this WG is taking to get
draft-ietf-tls-dnssec-chain-extension out the door.
I agree with both Tom and Viktor that the current draft seems to be
misaligned between the goals and the stated scope.
I wanted the draft to be done by now because i think it will b
On Thu 2018-11-08 18:31:28 -0800, Ryan Carboni wrote:
> Encrypting common knowledge is cargo cult fetishism for cryptography. The
> files could be sent unencrypted, and protected using subresource integrity.
> If you are sharing the same data to multiple second parties to serve to a
> single third
On Sat 2018-12-01 10:02:44 -0800, Christian Huitema wrote:
> Which is indeed a huge problem. Security conscious implementations of
> TLS should detect the use of such "enhancements", and either abort the
> session or automatically treat it as insecure.
This certainly looks like a case of forum-sho
On Wed 2018-12-05 17:08:44 +0900, Bret Jordan wrote:
> Now this WG is finally starting to talk about a solution to a real
> problem and need. We can either address the use case and need here in
> the IETF, or we can let the solutions be done else where. I would
> personally prefer we take this wor
On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote:
>> On Dec 5, 2018, at 7:33 PM, Stephen Farrell
>> wrote:
>>> On 05/12/2018 10:22, Bret Jordan wrote:
>>> I think we should be more open minded and look at the needs from a
>>> 360 degree deployment perspective.
>>
>> I think we should avoid m
Hi Andrei--
On Thu 2018-12-06 02:10:06 +, Andrei Popov wrote:
> I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will
> cost servers some perf:
>
>"Given the concerns in Section 2 and the necessary client mitigations
>in the subsections above, servers need to avoi
On Thu 2018-12-06 02:10:06 +, Andrei Popov wrote:
> In our tests, we see significant drop in handshakes/sec on a busy TLS
> server with ephemeral DH share reuse time < 1 sec.
hm, thinking about this optimization approach, i would really like to
know what implementations are doing this. It occ
On Thu 2018-12-06 21:08:00 +, Andrei Popov wrote:
> In a specific quick test that I did, there was no significant perf
> impact with key reuse time > 1 sec. And I could probably get it down
> to sub-seconds on my HW. But HW specs differ between TLS servers; our
> current "ephemeral" key lifetim
On Wed 2018-12-05 18:59:07 +, Stephen Farrell wrote:
> it's feasible and not easily defeated.
TLS endpoints can share their data (key material, cleartext, etc) with
whoever they choose -- that's just how the universe is implemented.
They can even do it out of band, on a channel that the peer
On Fri 2018-12-07 07:14:17 +, Peter Gutmann wrote:
> I appreciate that people feel strongly about this, and I support the idea of
> non-ephemeral DHE detection in principal [0] (along with many, many other
> measures to strengthen TLS), but this draft reads a lot like the IETF blowing
> raspber
I was trying to sort out concrete, specific advice for OCSP stapling
that provides security benefits for the server (and not just performance
and privacy benefits). Either i'm easily confused, or it's a mess. I
hope it's the former, please unconfuse me!
Given the IAB's statement from nearly two
On Mon 2018-12-10 02:24:29 +, Salz, Rich wrote:
>> * the status_request TLS extension doesn't provide a mechanism for
>stapling OCSP for intermediate certs.
>
> Nobody does this. There's a handful of reasons, but the end result is:
> nobody does this.
I'd be interested in hear
On Sun 2018-12-09 18:35:20 +0100, Kurt Roeckx wrote:
> On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote:
>> One mitigating factor of the ETSI standard, i suppose, is that the
>> CABForum's Baseline Requirements forbid issuance of a certificate with
>>
On Thu 2019-02-21 00:16:54 +, Peter Gutmann wrote:
> (A side-note about the 3526 values, they've been independently verified
> outside of their publication in the RFC, has anyone done this for the 7919
> ones? Not saying they're suspicious, but it'd be good to get independent
> verification t
On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote:
> Right. What about defining a set of extensions (e.g., 2 extensions) of
> flags as:
>
> struct {
>uint64 flags;
> } Flags;
If we're going to be doing this kind of bit-shaving, this is the way to
go, starting with a single Common
On Wed 2019-07-03 16:01:21 +0100, Stephen Farrell wrote:
> It doesn't take much to encourage me so I just
> pushed out that idea in I-D form:-) [1]
[…]
> [1] https://tools.ietf.org/html/draft-farrell-tls-wkesni-00
Thanks for this (and for the -01 update for the draft). I like this
work, and i th
On Fri 2019-11-22 05:13:13 +, Stephen Farrell wrote:
> I'm not sure if this draft ought specify behaviour for
> such clients, but I can try add text describing the various
> cases I guess. (If that text were to stay in, then I'd
> guess that it'll make this document too long to include
> in the
On Tue 2016-03-29 21:53:13 -0400, Sean Turner wrote:
> 1. The IANA registry rules for the TLS cipher suite registry [1] will be
> changed to specification required.
>
> 2. A new “IETF Recommended” column will be added with two values: “Y” or “N”.
> Y and N have the following meaning:
>
> Cipher
On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote:
> I am not sure that we want to be in the business of explicitly marking
> things as insecure other than our own RFCs, though -- there could be an
> implication of more review than is actually the case, which is what this
> proposal is trying
On Wed 2016-03-30 11:22:15 -0400, Eric Rescorla wrote:
> This got a lot of discussion early in the design process and the consensus
> was that the risk of having the default mode (with existing certs) allow the
> creation of a long-term delegation was too high. See, for instance, the
> relative imp
On Wed 2016-03-30 15:20:08 -0400, Ilari Liusvaara wrote:
> On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote:
>> On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote:
>> > I am not sure that we want to be in the business of explicitly marking
>> > th
On Fri 2016-06-03 17:54:53 -0400, Joseph Salowey wrote:
>Trial decryption has serious implementation problems
>-
>Double-encrypting handshake messages in both the handshake key and the
>application key does not actually provide the required key separation
>-
>Separately encr
On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
> 1. Use the same key for handshake and application traffic (as in the
> current draft-13)
>
> or
>
> 2. Restore a public content type and different keys
Given this choice, i prefer (1).
--dkg
On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote:
> I disagree that this is a low level crypto decision, or at least that this is
> mainly so.
>
> There is the question of whether using the same key for application data and
> handshake is harmful. That question is mainly low level crypto and cou
On Wed 2016-06-15 12:23:38 -0400, Ilari Liusvaara wrote:
> On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote:
>> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote:
>>
>> To be clear, we're being asked to trade these things off against each
>>
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 talking about the possibility of changin
On Tue 2016-08-30 16:14:06 -0400, Hubert Kario wrote:
> On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote:
>> * Keep the version ID as { 3, 4 } (already weird counting; changing risks
>> more intolerance)
>
> IMNSHO this alone is enough of a reason not to do this
>
> it's enough explaini
On Wed 2016-08-31 03:35:38 -0400, Julien ÉLIE wrote:
> Following a recent discussion about how to name the successor of TLS
> 1.2, I wish to share an idea about a possible terminology clarification.
> I believe it could help to conciliate people understanding of SSL & TLS.
>
> We would have 3 noti
On Tue 2016-10-11 13:26:02 -0400, Nick Sullivan wrote:
> The major thing that this proposal achieves is that it makes post-handshake
> auth an optional part of the implementation. Instead of this, I would also
> be in favor of a simpler change that modifies the text to say that
> post-handshake Cer
On Wed 2016-11-09 03:31:22 -0600, 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.
Martin, you keep saying things like "without value"
On Fri 2016-12-02 03:33:21 -0500, Peter Gutmann wrote:
> If no-one from Microsoft has any objections, can we just rename it back to
> what it's always been for everyone but us, SSL?
fwiw, the industry (and stackexchange) uses "SSL" to mean all sorts of
things, not only TLS. Yesterday i got an e-m
On Tue 2017-05-02 14:57:54 -0500, Nico Williams wrote:
> Well, I did say that to me there's not much difference to _me_ between
> "connections reusing the same ticket can be correlated to each other"
> and "connections reusing the same ticket can be correlated to each other
> and the connection whe
On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
> It certainly was. But then the clear text SNI is a gaping privacy hole
> in TLS, the kind of issue that should keep us awake at night until it is
> resolved. We need to make sure that we make progress, rather than rehash
> the old argumen
On Thu 2017-05-11 00:03:15 +0200, Roland Zink wrote:
> Not necessarily as you may for example use the path part of a URL to
> distinguish between services.
if we're talking about HTTPS, this approach raises a series of potential
security issues thanks to the same-origin policy and other host- or
On Fri 2017-07-14 10:51:14 -0400, Sean Turner wrote:
> The Secretariat has allocated us the Monday @ 13:30-15:30 slot.
hm, that's disappointing for those of us who had other things we'd
planned on going to already in that slot. :/ But it's not on the agenda
yet, so maybe it has been changed alrea
On Sat 2017-07-15 05:58:31 +, 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?
Because presumably the people who do *not* want to do evil want to avoid
s
On Fri 2017-07-07 16:04:20 -0400, Russ Housley wrote:
> In some industries, there are regulatory requirements that cannot be
> met without access to the plaintext.
This is surely true, but it's not clear to me that any regulator
requires access to the plaintext *from direct network capture*.
Cou
On Sat 2017-07-15 11:55:44 +0300, Ilari Liusvaara wrote:
> Oh, and like any backdoor, this backdoor too has variety of security
> problems. And your adversaries would absolutely love to be able to
> exploit _you_ using these problems, as that would make their lives much
> easier.
I'd like to hear
On Sat 2017-07-15 07:42:58 +, Dobbins, Roland wrote:
>> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor
>> wrote:
>>
>> Could you point to an example of any regulation that requires plaintext
>> from network capture specifically?
>
> It often isn't f
On Sat 2017-07-15 07:38:57 +, Dobbins, Roland wrote:
>> On Jul 15, 2017, at 13:14, Daniel Kahn Gillmor
>> wrote:
>>
>> * This proposed TLS variant is *never* acceptable for use on the public
>> Internet. At most it's acceptable only between two endpoin
On Sun 2017-07-16 12:44:04 +0300, Wartan Hachaturow wrote:
> On Sat, Jul 15, 2017 at 01:23:35PM +0200, Daniel Kahn Gillmor wrote:
>
>> > Not to mention the security & troubleshooting applications which
>> > require insight into the cryptostream on the wire.
&g
On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote:
> At our IETF 99 session, there was support in the room to adopt
> draft-huitema-tls-sni-encryption [0]. We need to confirm this support
> on the list so please let the list know whether you support adoption
> of the draft and are willing to rev
On Fri 2017-08-11 18:43:15 +0200, Nikos Mavrogiannopoulos wrote:
> I don't argue with this but this is not the approach TLS 1.3 took. It
> provides a generic padding mechanism to be used across application
> protocols.
The design approach that TLS 1.3 took was to provide a mechanism for
padding at
On Wed 2017-08-09 22:54:46 -0700, Tony Arcieri wrote:
> - The gateway authenticates clients (using e.g. a TLS client certificate)
> and authorizes the outbound hostnames against an ACL. This way we can
> control which clients are allowed to reach which external endpoints.
While i think i understan
On Wed 2017-06-21 21:25:21 -0700, Christian Huitema wrote:
> We has many discussions of SNI encryption on this list recently, and
> that was enough motivation to write a draft about it. I am pretty sure
> that this will be met with wide approval and no discussion at all :-).
This is my (hopefully
73 matches
Mail list logo
