On Fri, Jun 20, 2025 at 03:38:25PM -0400, David Benjamin wrote:
> On Fri, Jun 20, 2025, 15:27 Nico Williams wrote:
> (I continue to be speaking individually.)
>
> I'm not the person to be asking about this. What I wrote was specifically
> about this draft and not the overa
On Tue, Jun 17, 2025 at 02:16:19PM -0400, David Benjamin wrote:
> (As always, wearing an individual hat here. In particular, I am *not*
> speaking on behalf of the Chrome Root Program.)
Can we somehow inquire as to the Chrome Root Program's rationale for
this change? What alternatives were consid
On Fri, Jun 20, 2025 at 07:01:08AM +, ml+ietf-...@esmtp.org wrote:
> On Fri, Jun 20, 2025, Nico Williams wrote:
> > Weird. Let's Encrypt could tell Google to take a hike on this and
> > Google would abandon their position. So why is LE going along? Do they
>
>
On Fri, Jun 20, 2025 at 04:16:57PM +1000, Viktor Dukhovni wrote:
> On Thu, Jun 19, 2025 at 10:04:47PM -0500, Nico Williams wrote:
> > Does Google's change break previously-working use cases?
>
> Yes. Let's Encrypt intermediate issuers no longer vend EE certs with a
&
On Thu, Jun 19, 2025 at 11:51:54AM +0200, Filippo Valsorda wrote:
> 2025-06-19 09:52 GMT+02:00 Viktor Dukhovni :
> > One might, for example, instead dedicate to this end
> > intermediate issuer CAs having a serverAuth EKU, that will in many (be
> > they for now ad hoc, rather than RFC5280-blessed)
On Thu, Apr 17, 2025 at 05:56:56PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Since It looks like 3/4 of the audience holds position similar to mine
> - frankly, I don’t see why 3/4 must convince 1/4 that their position
> is valid (usually, it’s the other way around).
We don't "vote" because m
On Thu, Apr 17, 2025 at 02:35:19PM -0700, Benjamin Kaduk wrote:
> [trimming heavily since the text/plain component is made of lies and I don't
> want to misattribute nested quotes]
Yeah, if you're using a text-based MUA HTML gets painful.
> On Thu, Apr 17, 2025 at 09:17:29PM +, Blumenthal, Ur
On Wed, Apr 16, 2025 at 02:15:03AM +, Salz, Rich wrote:
> > If "move to PQ" meant no hybrid stuff for TLS, I'd really wonder why.
>
> That’s easy to answer: “many of our members have very
> hardware-constrained PoS devices.” Is that okay?
It might be possible to design the key exchange such
On Tue, Apr 15, 2025 at 10:33:23PM -, D. J. Bernstein wrote:
> Nico Williams writes:
> > there were no objections with technical reasons that were fatal to the
> > work in question
>
> I disagree. For example, the draft's regression from ECC+PQ to just PQ
> is
To begin with, the call for adoption has not ended yet as there are
still a couple of hours left.
On Tue, Apr 15, 2025 at 08:57:47PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> “Consensus” is not about reaching no dissenters. It’s about the
> “prevailing” opinion of majority, which in this case
On Thu, Oct 06, 2022 at 05:09:21PM +, John Gray wrote:
> For a use case like an HSM or TPM where private keys can never leave
> rules out option 1 (plus who wants to send their private key anyway
> unless it is for server backup or escrow purposes). Option 3 would
> work but is bad for CT log
+1
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Sun, Mar 07, 2021 at 11:47:45PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I'm not sure what it is you're imagining. What actually happens in the
> cases I'm familiar with is . . . . .
>
> Well-put - the point being that the cases you're familiar with do not
> cover the entire
On Sun, Mar 07, 2021 at 11:19:49PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> On 3/7/21, 17:36, "TLS on behalf of Nico Williams" behalf of n...@cryptonector.com> wrote:
> >
> >On Sun, Mar 07, 2021 at 09:57:40AM +, Peter Gutmann wrote:
> >> N
On Sun, Mar 07, 2021 at 09:57:40AM +, Peter Gutmann wrote:
> Nico Williams writes:
> > When expirations are short, you will not forget to renew. That's
> > part of the point of short-lived certificates.
>
> So instead of getting one chance a year for your control s
On Sat, Mar 06, 2021 at 01:21:14AM -0500, Viktor Dukhovni wrote:
> I suspect that in at least some cases the motivation to revalidate the
> server certificate is only requested because it could be done in
> principle, and ticks some checkbox about using CRLs, because they
> exist, rather than from
On Sat, Mar 06, 2021 at 06:55:52AM +, Peter Gutmann wrote:
> Nico Williams writes:
>
> >I've seen 5 day server certificates in use.
>
> For IEC-62351 work you're far more likely to see certificates issued with an
> expiry date of never, because the last th
On Fri, Mar 05, 2021 at 04:46:15PM -0800, Eric Rescorla wrote:
> This leaves us with the case where Bob's certificate is no longer valid but
> Bob has a new certificate [0]. In this case, just re-validating does not
> help. Does that happen so often that we need protocol machinery other than
> just
On Fri, Mar 05, 2021 at 01:13:57PM -0500, Viktor Dukhovni wrote:
> This harks back to another recent thread where it was noted that one
> needs to make a distinction between authentication and authorisation.
>
> The integrity of a TLS 1.3 session (which always performs ephemeral key
> agreement th
On Fri, Mar 05, 2021 at 06:42:40PM +, John Mattsson wrote:
> >While renegotiation will never be re-added, there is post-handshake
> >authentication (RFC 8446, section 4.6.2), and while that is currently
> >about authenticating the _client_ to the server, it should be trivial to
> >extend the pr
On Fri, Mar 05, 2021 at 05:01:04PM +, John Mattsson wrote:
> On Friday, 5 March 2021 at 15:02, Fries, Steffen wrote:
> > I've got a question regarding application of TLS 1.3 to protect long
> > lasting connections. Specifically on the trigger to perform a
> > revocation check for the utilized
On Wed, Sep 30, 2020 at 10:17:53PM +1000, Martin Thomson wrote:
> The costs you describe are trivial. And we limit replay with a binding
> to remote address, and a short timer. But the benefit is mostly down
> to reduced code variations. We also implement DTLS where this is
> properly useful.
You
On Tue, Jul 07, 2020 at 09:22:24PM -0700, Benjamin Kaduk wrote:
> There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently
> in IESG Evaluation):
>
>The protocol convention specified in the current document assumes
>there can be no more than one concurrent TLS session per TCP
On Sat, Jun 27, 2020 at 06:17:18PM +, Salz, Rich wrote:
> >Ah - Post-Handshake Authentication?
>
> Yeah, that.
There's no limit to how many of those there can be, correct?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinf
On Fri, Jun 26, 2020 at 10:41:02PM +, Salz, Rich wrote:
> >What has been pointed out is that TLS can renegotiate client
> >authentication.
>
> Not in TLS 1.3. And with TLS 1.0 and TLS 1.1 on their way out the
> door ...
That's what I thought. So there's just the header compression
BTW, thanks for the something-something-certificate work. Looking at
the I-D, draft-bdc-something-something-certificate-04, I see there's no
way to send the certificate chain on. I understand the motivation
(compression), but it really would be best to send on the full chain
sent by the client.
I wonder if an extension could be used to signal the client's and
server's ability to handle unexpected alerts.
So, for example, if a client TLS implementation and the application
using it can't handle new tickets, then don't send them.
Of course, implementors should get advice about these proble
On Fri, May 29, 2020 at 06:35:58PM -0400, Watson Ladd wrote:
> In my experience the issues are thorniest when dealing with blocking
> sockets. Libraries using nonblocking sockets have to signal to the
> application that they want IO to happen during the handshake, and can
> use that same mechanism
On Thu, Mar 05, 2020 at 04:21:56PM -0800, Watson Ladd wrote:
> On Thu, Mar 5, 2020 at 3:08 PM Nico Williams wrote:
> > > My skepticism is entirely a function of this being a late breaking
> > > [...]
> >
> > What is late breaking to you?
> >
> > The c
On Thu, Mar 05, 2020 at 06:15:26PM -0500, Viktor Dukhovni wrote:
> It isn't just the impact on client ticket cache processing, whatever it
> might be. Tickets can be quite large when client certs are in use,
> because various TLS APIs promise server applications the ability to
> return the client
On Thu, Mar 05, 2020 at 02:49:23PM -0800, Watson Ladd wrote:
> On Thu, Mar 5, 2020 at 12:55 PM Nico Williams wrote:
> > unless both parties agree. It takes two to agree.
>
> As far as I am aware session tickets being single use isn't enforced
> by any server right no
On Fri, Mar 06, 2020 at 08:35:07AM +1100, Martin Thomson wrote:
> On Fri, Mar 6, 2020, at 07:55, Nico Williams wrote:
> > unless both parties agree. It takes two to agree.
>
> RFC 8446 says:
>Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of
&g
On Thu, Mar 05, 2020 at 09:40:24PM +, Salz, Rich wrote:
> I think several participants in these threads are taking SHOULD NOT
> re-use as a MUST NOT. Servers in datacenters seem to fall outside
> that concern, no?
Indeed, RFC2119 defines SHOULD NOT:
4. SHOULD NOT This phrase, or the phr
unless both parties agree. It takes two to agree.
What are the problems with ticket reuse? Well:
1) session linkage
2) early data doesn't get rekeyed, so you get key reuse and the early
data is replayable
In the case of SMTP, however, (1) is not a problem for obvious reasons,
and (2)
On Wed, Mar 04, 2020 at 08:32:45PM -0800, Watson Ladd wrote:
> On Wed, Mar 4, 2020 at 6:07 PM Stephen Farrell
> wrote:
> > On 04/03/2020 16:06, Sean Turner wrote:
> > > Must the ticket reuse use case be addresses
> > > in draft-ietf-tls-ticketrequests?
> >
> > Yes. I think Viktor's use case is o
The ticketrequests I-D is likely to be the second time Viktor (and
others including me) have been told "do your own extension, we won't
oppose it, make it an individual submission, whatever, have fun and
leave us alone!".
There are several ways in which this attitude by the WG, by the relevant
I-D
On Wed, Mar 04, 2020 at 03:22:33PM -0500, Sean Turner wrote:
> > On Mar 4, 2020, at 15:15, Nico Williams wrote:
> > On Wed, Mar 04, 2020 at 05:09:35PM +, Salz, Rich wrote:
> >>>Must the ticket reuse use case be addresses
> >> in draft-ietf-tls-ticketre
On Wed, Mar 04, 2020 at 05:09:35PM +, Salz, Rich wrote:
> > Must the ticket reuse use case be addresses
> in draft-ietf-tls-ticketrequests?
I'm missing this post in my inbox, so I shall reply to Rich Salz's
reply. Thanks for having this LC.
Can we also ask why or why not? Of course
On Sat, Feb 29, 2020 at 04:29:38PM -0800, David Schinazi wrote:
> On Sat, Feb 29, 2020 at 2:57 PM Nico Williams wrote:
> > On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> > > However, I don't think we should add a second count in this extension.
> &g
On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> However, I don't think we should add a second count in this extension.
> Allowing ticket reuse is not something we have consensus for in the
^^^
Did I miss a consensus call or s
On Tue, Feb 25, 2020 at 08:32:48AM +0100, Rick van Rein wrote:
> We have prepared the following draft, and request feedback on it. The
> main points are
>
> * Introduction of (anonymous) Kerberos tickets as added entropy to mix
> with ECDH, and thereby provide Quantum Relief; it generalises this
On Sun, Feb 02, 2020 at 09:08:17AM -0800, Eric Rescorla wrote:
> I'm sorry to say that I'm not that sympathetic to this position. I
> appreciate that it's inconvenient for Postfix to have frequent writes
> to the ticket cache, but what you propose to do is hoist this
> implementation idiosyncracy i
On Fri, Jan 31, 2020 at 05:59:23PM -0800, Tommy Pauly wrote:
> As a point on the process, I don't think anyone is proposing
> rubber-stamping. We are instead only suggesting that a set of work
> that has consensus does not need to be held up by adding new work that
> does not have consensus.
A sub
On Fri, Jan 31, 2020 at 07:47:57PM -0600, Nico Williams wrote:
> On Fri, Jan 31, 2020 at 05:43:36PM -0800, Rob Sayre wrote:
> > On Fri, Jan 31, 2020 at 5:24 PM Viktor Dukhovni
> > wrote:
> >
> > > > On Jan 31, 2020, at 8:15 PM, Rob Sayre wrote:
> > > &
On Fri, Jan 31, 2020 at 05:43:36PM -0800, Rob Sayre wrote:
> On Fri, Jan 31, 2020 at 5:24 PM Viktor Dukhovni
> wrote:
>
> > > On Jan 31, 2020, at 8:15 PM, Rob Sayre wrote:
> > >
> > > If the scope of a document can be continually expanded during last call,
> > it can be indefinitely postponed.
>
On Fri, Jan 31, 2020 at 05:15:40PM -0800, Rob Sayre wrote:
> If the scope of a document can be continually expanded during last call, it
> can be indefinitely postponed.
There is no attempt to postpone, and the WGLC has finished. No new
issues will be raised. But the ones that were raised _will_
On Fri, Jan 31, 2020 at 04:58:07PM -0800, Rob Sayre wrote:
> On Fri, Jan 31, 2020 at 3:56 PM Nico Williams wrote:
> > Viktor's comment came before the end of WGLC, so the WG needs to
> > consider his comments,
>
> Yes.
>
> > and needs to reach consensus.
>
On Fri, Jan 31, 2020 at 09:06:12AM -0800, Tommy Pauly wrote:
> First off, thanks for the lively discussion on ticket reuse! I think
> it's a valid use case and something that should continue to be
> discussed.
>
> However, for the purposes of the WGLC for this draft,
> draft-ietf-tls-ticketrequest
On Thu, Jan 23, 2020 at 09:43:21AM -0800, Watson Ladd wrote:
> Sending a new ticket doesn't force clients to store it.
Sure, but if the old ticket will not be accepted again then the client
will incur a full handshake later. The client doesn't know if the old
ticket will or will not be accepted a
On Wed, Jan 22, 2020 at 10:33:48PM -0600, Nico Williams wrote:
> On Wed, Jan 22, 2020 at 05:12:34PM -0800, Watson Ladd wrote:
> > > Now the first alternative would be infeasible to adopt because it would
> > > require new OpenSSL callback APIs, and anyways would be a more inv
On Wed, Jan 22, 2020 at 05:12:34PM -0800, Watson Ladd wrote:
> > Now the first alternative would be infeasible to adopt because it would
> > require new OpenSSL callback APIs, and anyways would be a more invasive
> > change to TLS than the ticketrequest extension makes.
>
> Nothing says you have t
On Tue, Jan 21, 2020 at 06:19:23PM +, Salz, Rich wrote:
> Viktor and I spoke in more detail. The use-case he brings up makes
> more sense to me now. The key observation is that this is not about a
I also spoke to Viktor, and he explained the motivation in detail. He
really should have done s
On Thu, Nov 21, 2019 at 11:19:36AM +0800, David Schinazi wrote:
> Regarding Viktor's suggestion, I personally believe it would increase the
> complexity of the proposal, and I don't see use-cases compelling enough
> to warrant that complexity. I would rather keep this proposal as simple as
> possib
On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote:
> I've read the draft, it looks quite useful and reasonable. It would
> be good to see this published.
+1
> I have one idea (implemented in OpenSSL 1.1.1 on the server side)
> that may be worth mentioning in this context (and perha
On Thu, Sep 19, 2019 at 06:03:44PM -0400, Richard Barnes wrote:
> On Thu, Sep 19, 2019 at 5:49 PM Nico Williams wrote:
> > On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> > > I don't think anyone's asking for these cases to be differentiable on the
On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> I don't think anyone's asking for these cases to be differentiable on the
> wire. The question is whether the *server* can differentiate, in
> particular, the application running on the server.
And the answer to that one is "yes",
On Thu, Sep 19, 2019 at 08:06:26AM -1000, Christian Huitema wrote:
> There is also a privacy angle. From a privacy point of view, it is
> very nice that PSK cannot be distinguished from session resumption.
This.
PSK is the right way to, for example, integrate Kerberos into TLS 1.3
now. But it's
On Fri, Dec 14, 2018 at 08:53:47PM -0600, Nico Williams wrote:
> Figure 1: Alternative ESNI w/o active protection
Figure 1 was expositional. Please forget it.
> Figure 2: Alternative ESNI w/ active protection
> Figure 3: Alternative ESNI
On Tue, Dec 18, 2018 at 01:58:53AM +, Stephen Farrell wrote:
> On 17/12/2018 23:33, Nico Williams wrote:
> > Maybe we do both, the current ESNI proposal and this as an alternative
> > for when ESNI keyshare orchestration is difficult, and in that case you
> > don&#
On Sat, Dec 15, 2018 at 01:08:50PM +, Stephen Farrell wrote:
> On 15/12/2018 02:53, Nico Williams wrote:
> > OpenSSL extracts and uses SNI from session resumption tickets.
> >
> > This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here
> > on th
On Fri, Dec 14, 2018 at 08:01:35PM -0800, Eric Rescorla wrote:
> On Fri, Dec 14, 2018 at 6:54 PM Nico Williams wrote:
> > OpenSSL extracts and uses SNI from session resumption tickets.
> > This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here
> > on
OpenSSL extracts and uses SNI from session resumption tickets.
This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here
on their behalf.
Also, while we're at it, I'd like to note that SNI is not the only thing
requiring privacy protection from the client. There's also the PSK
iden
On Fri, Dec 14, 2018 at 10:11:38PM +0100, Martin Rex wrote:
> 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 Go
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 resumption, it fails to
> send the S
On Fri, Dec 07, 2018 at 07:14:17AM +, Peter Gutmann wrote:
> It depends on what those resources are, at one end you've got proper DHE with
> a full modexp required, at the other end if you can fake it with something as
> lightweight as a mod-add or similar it's essentially free while defeating
On Fri, Dec 07, 2018 at 06:31:21AM +, Peter Gutmann wrote:
> Aren't you going to get into an adversarial machine learning problem where
> your recogniser has to be smarter than the other side's DH-reuse code? In
> other words if the server just reuses the same DHE public value again and
> agai
On Fri, Dec 07, 2018 at 03:37:25AM +0300, Daniel Kahn Gillmor wrote:
> 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 univers
On Fri, Dec 07, 2018 at 12:04:02AM +, Andrei Popov wrote:
> > I don't think the TLS WG or IETF can win this skirmish.
>
> That's what I'm thinking as well, although I agree with the goals of
> draft-dkg-tls-reject-static-dh-01.
Yes. What we can, and IMO should do, is say that if you must do
On Wed, Dec 05, 2018 at 06:59:07PM +, Stephen Farrell wrote:
> My main concern is that a server playing a
> draft-green-like game could just choose DH
> values more cleverly and avoid detection.
We can forbid static server DH keys, and should attempt to preclude them
by encouraging clients to
On Tue, Dec 04, 2018 at 05:39:30PM +0100, Jonathan Hoyland wrote:
> Isn't there a lower bar at the IETF for defining new cipher suites, as long
> as you're not seeking a "recommended" setting?
Yes, but then you have to get interoperability using them, which means
patching clients and servers. You
On Tue, Dec 04, 2018 at 04:34:08PM +0100, Jonathan Hoyland wrote:
> Is it necessarily true that any key escrow system must allow resumptions?
>
> Just to play devil's advocate, consider defining a new cipher suite that
> appended a MAC to each message before applying one of the other cipher
> suit
On Sat, Dec 01, 2018 at 07:59:45AM -0800, Tony Arcieri wrote:
> This does not seem to address a problem which was brought up when the
> similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any
> system in possession of one of the non-ephemeral-ECDHE private keys,
> ostensibly for the
On Thu, Nov 08, 2018 at 11:49:45AM -0500, Paul Wouters wrote:
> I wanted to thank Ben for the outreach he did in the last six months on
> the tls dnssec chain extension. It has been a difficult issue and I do
> wish the outcome was different. But during this time Ben put a lot of
> effort in trying
We've had a couple of conference calls to discuss the I-D.
One call ended up causing the consensus on the I-D to collapse.
The second call ended too soon, but it was not unproductive. Indeed, I
think at that call and in the subsequent off-list threads we identified
the concerns with pinning:
-
On Mon, Nov 05, 2018 at 07:01:57AM -0600, Benjamin Kaduk wrote:
> Once we start talking about pinning of any sort, we move from this
> extension just being "transport some DNS records" into conveying some
> sort of additional semantics.
The I-D lost consensus over one issue. We should resolve tha
On Tue, Oct 30, 2018 at 09:53:47PM -0400, Sean Turner wrote:
> > On Oct 30, 2018, at 17:41, Nico Williams wrote:
> > On Wed, Oct 24, 2018 at 08:19:33PM -0400, Sean Turner wrote:
> >> Proposed Charter Text
> >
> > +1, but see comments below.
> >
>
On Wed, Oct 24, 2018 at 08:19:33PM -0400, Sean Turner wrote:
> Proposed Charter Text
+1, but see comments below.
First off, suppose we wanted to write a successor to RFC2712 for TLS
1.3, should we pursue that in the TLS WG, or KITTEN WG? I'm amenable to
either, and even both.
> [...]
>
> The se
On Mon, Oct 08, 2018 at 05:09:40PM -0700, Christopher Wood wrote:
> Notes from the TLS interim meeting held in September are now online
> [1]. To recap, the meeting attempted to focus on three primary
> questions:
>
> 1. What is the fundamental security issue? What is the purpose of this
> extensi
Shortening the link works. Basically you can join with the app or web
page, using the 9-digit meeting code. You end up having to register.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Thu, Jul 19, 2018 at 12:16:18PM -0400, Viktor Dukhovni wrote:
> On Wed, Jul 18, 2018 at 10:23:49PM -0500, Nico Williams wrote:
> > > At yesterday's WG meeting, Sam Weiler suggested that the pinning
> > > information could be conveyed via the DNS. That way you woul
On Wed, Jul 18, 2018 at 08:41:59AM -0400, Shumon Huque wrote:
> At yesterday's WG meeting, Sam Weiler suggested that the pinning
> information could be conveyed via the DNS. That way you would not need new
> holes/fields in the TLS extension. Paul said it doesn't work. But Willem
> Toorop and I dis
On Wed, Jul 18, 2018 at 01:54:09AM -0700, Eric Rescorla wrote:
> On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni
> wrote:
> >
> > c. Testing is not a good fit at this layer, all that's
> >pinned is the ability to deliver the extension, after a
> >previous connectio
On Mon, Jun 25, 2018 at 09:20:16PM -0700, Joseph Salowey wrote:
> 1. Do you support the working group taking on future work on a pinning
> mechanism (based on the modifications or another approach)?
Yes with a caveat: I don't much care whether pinning work gets done as
an individual submission, a
On Thu, May 24, 2018 at 09:30:59AM -0700, Adam Langley wrote:
> On Wed, May 23, 2018 at 8:23 PM Peter Gutmann
> wrote:
> > That's going to cause clashes with implementations that use that value for
> > TLS-LTS, it would be better to use a value other than 26 that isn't
> already in
> > use.
>
> O
On Thu, Apr 26, 2018 at 11:53:29AM -0400, Viktor Dukhovni wrote:
> Of course given evermore sophisticated BGP attacks:
>
> https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/
>
> you might actually want to consider DNSSEC, implement it properly
> and monitor, and the bricking won't hap
On Thu, Apr 26, 2018 at 08:41:18AM -0700, Eric Rescorla wrote:
> On Thu, Apr 26, 2018 at 8:22 AM, Nico Williams
> wrote:
> > Because we'd pin only to the use of this extension, the TTL is
> > sufficient.
>
> I explained in my response to Victor why this isn't so
On Thu, Apr 26, 2018 at 11:41:05AM -0400, Richard Barnes wrote:
> On Thu, Apr 26, 2018 at 11:22 AM, Nico Williams
> wrote:
>
> > On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote:
> > > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni > >
> > &g
On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote:
> On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni
> wrote:
> > On Apr 26, 2018, Eric Rescorla wrote:
> >
> > * a lifetime field
> > * enforce vs. test
> > * a report URI
We will need only the TTL. We will not need anything el
On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote:
> Thanks for producing some text. I understand why one might think that
> having a reserved 16-bit field is useful here, but I don't really
> agree.
>
> The conventional reason to reserve this kind of field is that you need
> to leave
On Wed, Apr 25, 2018 at 09:13:37PM -0700, Joseph Salowey wrote:
> This proposal is quite a bit more than just a two byte reserved field.
What, Viktor's text? Most of it has to do with the denial of existence,
not with those two bytes.
___
TLS mailing l
On Wed, Apr 25, 2018 at 10:40:02AM -0500, Nico Williams wrote:
> On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote:
> > On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote:
> > > On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> > > > Perhaps a
On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote:
> On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote:
> > On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> > > Perhaps a concrete proposal will make it
> > > easier to reach a mutually-agreeable cons
On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote:
> On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> > Perhaps a concrete proposal will make it
> > easier to reach a mutually-agreeable consensus position, and make it
> > clear that the requested 16-bits are a reasonable consensus outcome.
On Wed, Apr 18, 2018 at 11:34:14PM -0400, Viktor Dukhovni wrote:
> > On Apr 18, 2018, at 11:25 PM, Peter Gutmann
> > wrote:
> >> That's just silly. Really, 7.5 years (relative, not absolute) measured in
> >> hours is plenty good enough, and more than outlives current device
> >> obsolescence. T
On Wed, Apr 18, 2018 at 05:01:54PM -0400, Richard Barnes wrote:
> On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni
> wrote:
> > > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote:
> > >
> > > Secondary point. Still don't think we should deliberately include
> > undefined fields, e.g., because p
On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote:
> On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni
> wrote:
>
> >
> >
> > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
> > >
> > > I do not support adding a field to the protocol with semantics to be
> > defined later. Espe
On Mon, Apr 16, 2018 at 04:21:27PM -0400, Paul Wouters wrote:
> On Mon, 16 Apr 2018, Viktor Dukhovni wrote:
> >>* We might want to say that if the TTL is zero then the clients MUST NOT
> >> pin and must clear any pin. And we might do this in spite of not
> >> describing any pinning semantics -- ex
On Mon, Apr 16, 2018 at 11:38:28AM -0700, Tony Arcieri wrote:
> On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni
> wrote:
> > A major obstacle to making access control decisions during the TLS
> > handshake is that at that time the server often does not yet have enough
> > information to determine
On Fri, Apr 13, 2018 at 12:16:43PM -0700, Jim Fenton wrote:
> From reading the abstract and introduction to this draft, it appears to
> be proposing mostly a performance improvement for retrieving web pages
> using DANE authentication. There is some security improvement, but that
> seems to be inci
On Fri, Apr 13, 2018 at 04:38:55PM -0400, Richard Barnes wrote:
> On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams
> wrote:
> > It's better to send the denial of existence than no extension -- the
> > client could just as well be pinning (because the I-D said it could, or
1 - 100 of 192 matches
Mail list logo
