On Fri, Jul 31, 2015 at 07:42:12PM +0300, Ilari Liusvaara wrote:
> On Fri, Jun 26, 2015 at 01:41:29PM -0500, Nico Williams wrote:
> > tls-unique depends on the Finished message strongly binding the entire
> > transcript up to that point. I find this elegant (despite the
> &g
On Fri, Aug 28, 2015 at 06:33:17PM +, Viktor Dukhovni wrote:
> On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:
> Furthermore, anon-DH has strong privacy properties, the server
> sends no identity information, not even a public key. Any
> channel-binding at the next layer is pri
On Mon, Aug 31, 2015 at 09:18:34AM -0700, Eric Rescorla wrote:
> On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams
> wrote:
> > I'm not sure how I feel about this. The idea that we always do a DH key
> > exchange and always have a server signature means we can greatly r
On Mon, Aug 31, 2015 at 09:48:10AM -0700, Eric Rescorla wrote:
> On Mon, Aug 31, 2015 at 9:45 AM, Nico Williams
> wrote:
> > How would we get rid of PSK [without DH]? What would the impact be on
> > IoT devices? Could we have a fake-DH-and-signature PSK scheme to make
&
On Tue, Sep 15, 2015 at 03:18:30PM +0200, Florian Weimer wrote:
> On 09/12/2015 10:49 PM, Eric Rescorla wrote:
> > Issue: https://github.com/tlswg/tls13-spec/issues/242
> >
> > In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
> >
> > "Nobody must ever be *required* to send an
On Wed, Sep 16, 2015 at 12:02:57PM +0200, Florian Weimer wrote:
> On 09/15/2015 06:29 PM, Nico Williams wrote:
> > But if you have a fatal error you'll be closing immediately anyways.
>
> I'm trying to explain that any requirement to send fatal alerts will be
> diffi
On Wed, Sep 16, 2015 at 03:29:40PM -0400, Dave Garrett wrote:
> I'd be fine with phrasing it as: implementations MUST send all alerts
> when indicated, and SHOULD make a best-effort to ensure they get
> delivered to the peer.
+1.
Perhaps some text explaining the difficulty in the latter and offer
On Wed, Sep 16, 2015 at 10:40:28AM -0700, Martin Thomson wrote:
> On 15 September 2015 at 18:00, Joseph Salowey wrote:
> > remove anonymous DH
>
> +1
>
> It's not like we're making the use case impossible, just that the
> solution will look different.
And will be more costly.
I'm neutral on th
On Wed, Sep 16, 2015 at 01:20:37PM -0700, Brian Smith wrote:
> I think it is a good idea to remove DH_anon_* and similar ECDH_anon_*
> cipher suites.
>
> This isn't an endorsement of the raw public key modes.
Sure, one can always use self-signed certs (at an even higher cost to do
anonymity). If
On Wed, Sep 16, 2015 at 02:12:07PM -0700, Tony Arcieri wrote:
> On Wednesday, September 16, 2015, Eric Rescorla wrote:
>
> > In addition, they are already part of TLS, so the question would be if we
> > have
> > consensus to remove them
> >
>
> I see a bunch of +1s and zero -1s. Just saying.
On Wed, Sep 16, 2015 at 02:25:52PM -0700, Brian Smith wrote:
> On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote:
>
> > In addition, they are already part of TLS, so the question would be if we
> > have
> > consensus to remove them
> >
>
> This thread is about the removal of DH_anon_*, n
On Wed, Sep 16, 2015 at 06:37:21PM -0400, Dave Garrett wrote:
> On Wednesday, September 16, 2015 05:38:27 pm Viktor Dukhovni wrote:
> > On Wed, Sep 16, 2015 at 03:03:54PM -0400, Dave Garrett wrote:
> > > The suggestion that started this thread was to have a "Standard TLS
> > > Profile"
> > > that
On Wed, Sep 16, 2015 at 07:07:31PM -0400, Dave Garrett wrote:
> This appears to just be a miscommunication.
It is not.
> The current poll is to remove anon ciphers in favor of raw public
> keys. We're not considering removing raw public keys, as far as I
> know, and I think most of us would be ag
On Wed, Sep 16, 2015 at 06:40:47PM -0700, Bill Frantz wrote:
> I agree with both Nico and Viktor. For me the big win of RPK over
> anon_(EC)DH is it allows TOFU. If TOFU isn't needed, short public
> keys should ease many of Viktor's cons. I also like the idea of
> simpler implementations.
Eh, cert
On Wed, Sep 16, 2015 at 12:53:53PM -0700, Brian Smith wrote:
> Further, the alerting mechanism has encouraged the unsafe practice of
> "version fallback." It is clear from looking at the bug databases of
> Firefox and Chrome that their attempts to make security decisions based on
> what alerts they
On Thu, Sep 17, 2015 at 02:46:39PM -0700, Brian Smith wrote:
> On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams
> wrote:
> > Do we think that silent connection closings wouldn't also lead to
> > version fallback?
>
> Let's ask the browser vendors:
>
> Brow
On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote:
> On Thursday, September 17, 2015 03:27:10 pm Brian Smith wrote:
> > (We should focus on conformant implementations because non-conformant
> > implementations can do whatever they want, by definition).
>
> The flaw in your logic here is
On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote:
> Issue: https://github.com/tlswg/tls13-spec/issues/242
>
> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
>
> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an alert should be SH
On Thu, Sep 17, 2015 at 03:00:05PM -0700, Brian Smith wrote:
> On Thu, Sep 17, 2015 at 2:55 PM, Nico Williams
> wrote:
> > On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote:
> >
> > Yes, exactly. Thanks.
> >
>
> There's no evidence that t
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 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 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 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 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 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 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 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 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 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 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
+1
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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
On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote:
> On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote:
> > Several of us were well aware of this during the early days of the
> > draft, but perhaps many folks did not fully appreciate the impacts
> > until I elaborated on them last ye
On Tue, Feb 27, 2018 at 05:36:12PM -0600, Nico Williams wrote:
> On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote:
> > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote:
> > > Several of us were well aware of this during the early days of the
> > > draft,
IF there's an objection to modifying the extension in order to add a
pin-to-DANE TTL field, I would propose the following instead:
Make the pin-to-DANE be "forever" but make it so it can easily be
cleared if DANE is undeployed for the service.
That would look like this:
- if the server
On Wed, Apr 04, 2018 at 10:50:15AM -0700, Joseph Salowey wrote:
> Some objections were raised late during the review of
> the draft-ietf-tls-dnssec-chain-extension. The question before the working
> group is either to publish the document as is or to bring the document back
> into the working group
On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
> I don't think that this comparison is particularly apt.The
> representation in HSTS is simply "I support HSTS". The representation
> in HPKP is "I will use either consistent keying material *or* a
> consistent set of CAs". The represe
On Thu, Apr 05, 2018 at 12:07:57PM +1000, Martin Thomson wrote:
> Given what we've learned about pinning (it is being removed from
> browsers), this seems like a bad plan to me.
You can use this TTL, or not. You're not required to set it to any
value other than the max ("infinity") or min (zero)
On Wed, Apr 04, 2018 at 05:33:27PM -0400, Paul Wouters wrote:
> On Wed, 4 Apr 2018, Joseph Salowey wrote:
> >A) Recommendation of adding denial of existence proofs in the chain provided
> >by the extension
> >B) Adding signaling to require the use of this extension for a period of
> >time (Pinnin
On Thu, Apr 05, 2018 at 02:39:43AM +, Richard Barnes wrote:
> Re-adding the list.
Removing one level of quotes.
> On Wed, Apr 4, 2018, 22:34 Nico Williams wrote:
>> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
>> > I don't think that this comparis
On Wed, Apr 04, 2018 at 07:44:53PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 7:20 PM, Nico Williams wrote:
>
> > On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
> > > I don't think that this comparison is particularly apt.The
> > >
On Wed, Apr 04, 2018 at 07:56:37PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams wrote:
> > We cannot be serious about security while promoting a protocol with a
> > glaring downgrade attack.
>
> Unfortunately, you are conflating the assertiv
On Thu, Apr 05, 2018 at 03:04:03AM +, Richard Barnes wrote:
> And just to be clear, by "downgrade attack", you mean "normal PKI
> authentication that we rely on today". There's nothing in here that
It's NOT that using WebOKI is a downgrade.
It's that if an operator wants to use DANE (with an
On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams wrote:
>
> > > HPKP had a TTL and yet as a practical matter, people found it very
> > > problematic.
> >
> > I can see why: you have to commit
On Thu, Apr 05, 2018 at 06:33:10AM -0700, Eric Rescorla wrote:
> On Thu, Apr 5, 2018 at 2:02 AM, Paul Wouters wrote:
> > On Wed, 4 Apr 2018, Eric Rescorla wrote:
> >> HPKP had a TTL and yet as a practical matter, people found it very
> >> problematic.
> >> And, of course, if you're concerned with
On Wed, Apr 04, 2018 at 08:39:37PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams wrote:
> > Either way it's the same impact: you cannot roll that key over.
> >
> > Whereas with pin-to-DANE there's no such problem. I thought I made th
On Thu, Apr 05, 2018 at 02:46:12AM -0400, Viktor Dukhovni wrote:
> So I rather suspect that even the DPRIV use-case, which supposedly does not
> need
> the proposed changes, actually does need them for meaningful security from
> using
> DANE, and we've not just not looked at the details closely e
On Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote:
> Yes. I support the publication of the document as is.
>
> and would like to explain my position a bit.
>
> I'm very sympathetic to Viktor's desire to enhance this protocol
> to provide downgrade resistance against PKIX attacks, and I
On Tue, Apr 10, 2018 at 11:48:58AM -0500, Benjamin Kaduk wrote:
> On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote:
> > > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote:
> > > But I would also like to publish a document that has the solid
> > > consensus of the community that is on
On Tue, Apr 10, 2018 at 04:17:14PM -0800, Melinda Shore wrote:
> On 4/10/18 3:53 PM, Nico Williams wrote:
> > The earlier consensus is not just applicable, as if it were, we would
> > not be having this LC.
>
> I have no idea what that even means, to be honest. We'r
Let me synthesize one new argument, though I've implied it before, but I
think making it explicit may be useful:
The cost of making the requested changes is fixed and can be estimated
-- measured even, after the fact. I argue that cost is low. But the
cost/risk of not making the requested
On Thu, Apr 12, 2018 at 04:40:25AM -0400, Paul Wouters wrote:
> On Wed, 11 Apr 2018, Benjamin Kaduk wrote:
>
> >I don't really agree with that characterization. To state my understanding,
> >as responsible AD, of the status of this document: this document is in the
> >RFC Editor's queue being pro
On Thu, Apr 12, 2018 at 09:51:12PM -0700, Eric Rescorla wrote:
> On Thu, Apr 12, 2018 at 9:40 PM, Viktor Dukhovni
> wrote:
> > > On Apr 13, 2018, at 12:07 AM, Melinda Shore <
> > melinda.sh...@nomountain.net> wrote:
> > >
> > > I'm okay with putting denial-of-existence in there as a should,
> > >
On Thu, Apr 12, 2018 at 04:10:27PM -0700, Eric Rescorla wrote:
> On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni
> wrote:
> > Proposed text:
> >
> >When the server has DNSSEC-signed TLSA records, the first RRset in
> >the chain MUST contain the TLSA record set being presented.
> >Howe
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
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 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 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 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 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 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 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 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 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: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 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 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 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 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: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, 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 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 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 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 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
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 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
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 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 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
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 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
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 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 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 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 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 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 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 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 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 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
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 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
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 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 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 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 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 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
1 - 100 of 182 matches
Mail list logo
