On Tue, Mar 20, 2018 at 7:42 PM, Hubert Kario wrote:
> On Monday, 19 March 2018 14:38:05 CET Eric Rescorla wrote:
> > On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos <
> n...@redhat.com>
> >
> > wrote:
> > > On Fri, 2018-03-16 at 14:45 -0500, Benja
Eric Rescorla has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however
Speaking as an individual, as I said in the meeting, I don't think this is
a helpful change.
-Ekr
On Wed, Mar 21, 2018 at 1:05 PM, Paul Wouters wrote:
>
> I think the below change would address my issue, without stepping on the
> things people brought up today (other then suggesting, not manda
First, just for clarification, you mean the TLS record MAC on the Finished
rather than the TLS Finished MAC, right?
Assuming that is correct, then I believe this is reasonable behavior. It
makes the protocol somewhat more resistant to damaged bits on the wire.
Note that QUIC takes this position ev
ure that this is just a slower failure
> detection. I agree that this is less of an issue for a simple rotate the
> keys problem. I am slightly worried about having the same problem on a
> re-negotiation though.
>
How would that happen unless you had an implementation defect.
-Ek
We (Firefox/NSS) intend to not use 0304 until the RFC is published. Of
course, it might be safe for Wireshark to start earlier as its compat story
is different.
-Ekr
On Thu, Mar 29, 2018 at 7:38 AM, Benjamin Kaduk wrote:
> On 03/29/2018 09:30 AM, Peter Wu wrote:
> > Hey all,
> >
> > With draft
Hi folks,
TLS 1.3 has been approved by the IESG and it's on its way to the RFC
Editor, so
I don't really see this changing any time soon for the base RFC.
I think there's some debate about whether this is a good idea, but in any
case,
the right way to pursue it would be to publish a new draft, pr
Thinking through this some more, I'm skeptical that this is going to be
that useful as a debugging-only feature.
In my experience, there are four major scenarios for diagnosing this kind
of failure. Under the assumption that you control one end, the other end
can be:
1. A live endpoint.
2. A test
Eric Rescorla has entered the following ballot position for
draft-ietf-tls-iana-registry-updates-04: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Eric Rescorla has entered the following ballot position for
draft-ietf-tls-record-limit-02: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
On Sat, Mar 31, 2018 at 10:29 PM, Peter Gutmann
wrote:
> Eric Rescorla writes:
>
> >In my experience, there are four major scenarios for diagnosing this kind
> of
> >failure. Under the assumption that you control one end, the other end can
> be:
> >
> >
On Mon, Apr 2, 2018 at 6:21 PM, Martin Thomson
wrote:
> Nits are on the editor's copy.
>
> https://github.com/tlswg/tls-record-limit/commit/
> 8c6307f63d5c3e34d3da1747fcdfbcc54aa290f6
>
> On Sun, Apr 1, 2018 at 5:31 AM, Eric Rescorla wrote:
> > This text is a b
On Wed, Apr 4, 2018 at 7:15 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 4, 2018, at 10:07 PM, Martin Thomson
> wrote:
> >
> > Given what we've learned about pinning (it is being removed from
> > browsers), this seems like a bad plan to me.
>
> Question, are you thinking of HPKP or STS? HPKP pins
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
> > representation in HSTS is simply "I support HSTS". The representation
>
On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams wrote:
> 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 a
On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams wrote:
> 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:
> > > >
On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams wrote:
> 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
> >
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 hijacking attacks, the hijacker
>> wi
On Thu, Apr 5, 2018 at 2:06 AM, Paul Wouters wrote:
> On Wed, 4 Apr 2018, Eric Rescorla wrote:
>
> 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's
>> a pain). This rationale was stronger back before Let's Encrypt, but
>> I suppose some
On Thu, Apr 5, 2018 at 7:08 AM, Viktor Dukhovni
wrote:
>
>
> > On Apr 5, 2018, at 9:33 AM, Eric Rescorla wrote:
> >
> > However, that doesn't mean that hijacking isn't a problem (though I
> agree a less
> > serious one). If I have no provisions for DN
On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard
wrote:
> Hi,
>
> We are implementing DTLS with PSK over UDP and I would like to know how
> "unknown identity" and "bad psk" should be handled
>
> Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
> (https://tools.ietf.org/html/rfc
On Fri, Apr 6, 2018 at 4:11 PM, Viktor Dukhovni
wrote:
> On Fri, Apr 06, 2018 at 12:10:35PM +, Salz, Rich wrote:
>
> > >For debugging messages, I'm with Peter, they'll only be implemented
> if they're
> > > simple enough to support. I can't see having to have localization
> files on th
On Mon, Apr 9, 2018 at 2:16 PM, Joseph Birr-Pixton
wrote:
> Hello,
>
> PR#1163 in draft-26 seems to have broken interop with previous drafts
> with a variety of deployed implementations. draft-26 and later clients
> fail with a protocol_version alert.
>
> Affected Internet servers include:
>
> cl
On Thu, Apr 12, 2018 at 3:09 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 5:47 PM, Martin Thomson
> wrote:
> >
> > If this is indeed about adding [goo], what prevents Viktor or Paul
> > from proposing a new addition to the protocol in the form of a new I-D
> > that enacts the changes t
On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 6:44 PM, Willem Toorop wrote:
> >
> > Well... I find it unfortunate that the line you were quoting from
> > section 3.4 could be interpreted as prohibiting the possibility of
> > denial of existence. So I am ope
On Thu, Apr 12, 2018 at 4:14 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 7:10 PM, Eric Rescorla wrote:
> >
> > The difficulty here is what the server knows about the clients behavior.
> > Specifically, if the server serves TLSA records and then ce
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,
> > but I do feel strongly that pinning belongs in a separate document.
> > As
Hi Tony,
Thanks for forwarding these.
I haven't had time to give them a thorough review, but on a quick skim I
notice that this seems to be based on TLS 1.2 and to use a bunch of
algorithms we are trying to deprecate (e.g., CBC). Is there a reason not to
start with TLS 1.3 and more modern algorit
ts are those of pioneers like David Naylor
> and Justine Sherry. (Her slogan that "middleboxes are the drama queens of
> networking" has become legend.)
>
> Tony
>
> On Apr 13, 2018 11:36 AM, Eric Rescorla wrote:
>
> Hi Tony,
>
> Thanks for forwarding these.
&g
I am not aware of anywhere this is documented, primarily because it's so
application-specifiic.
-Ekr
On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom
wrote:
> Hi dear TLS experts,
>
>
>
> Apologies for my stupid question for advise:
>
> I am currently working on some design requirements for mut
+1
On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner wrote:
> All,
>
> tl;dr: If you object to the following early code point assignments 1) add
> the compress_certificate in the TLS ExtensionType Registry and 2)
> compressed_certificate in the TLS HandshakeType Registry, then please let
> the list k
Hi Victor,
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
space for an extension in some PDU, because it's hard to add la
On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni
wrote:
>
>
> > On Apr 26, 2018, at 2:30 AM, Eric Rescorla wrote:
> >
> > If you look at HPKP and Expect-CT, you will note that there are a number
> of
> > other fields besides just lifetime (report-uri, include su
On Thu, Apr 26, 2018 at 8:05 AM, Viktor Dukhovni
wrote:
>
>
> > On Apr 26, 2018, at 10:50 AM, Eric Rescorla wrote:
> >
> >> If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we
> >> find:
> >>
> >> * a lifetime field
> >
On Thu, Apr 26, 2018 at 8: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 >
> > wrote:
> > > On Apr 26, 2018, Eric Rescorla wrote:
> > >
> > >
On Wed, May 2, 2018 at 4:57 PM, Benjamin Kaduk wrote:
> On Mon, Apr 23, 2018 at 01:45:34PM +0200, Daiki Ueno wrote:
> > Hello,
> >
> > I have a question about handling the psk_key_exchange_mode extension.
> >
> > 4.2.9. Pre-Shared Key Exchange Modes says:
> >
> > This extension also restricts t
Note that this is different from Token Binding because that's negotiated by
an extension, so per S 9.3, non-supporting middleboxes need to strip out
the extension
-Ekr
On Mon, May 7, 2018 at 8:06 AM, Roelof duToit wrote:
>
> > On May 4, 2018, at 5:48 PM, Benjamin Kaduk wrote:
> >
> > On Fri,
Regardless of where it goes in the document, I think there's a real
deployment
consideration here: if you run this mechanism through a conventional MITM
proxy, what will happen will be that the secondary cert auth will appear to
just
fail with a bogus signature. If clients respond to that by termin
But it actually sends an SH? That seems odd and kind of an ambiguous point
in the spec.
-Ekr
On Wed, May 9, 2018 at 10:14 AM, Roelof duToit wrote:
> In one of our tests OpenSSL 1.1.1-dev sends an unrecognized_name warning
> alert before a TLS 1.3 (draft 26) ServerHello. Alert level is suppose
egotiation..
>
> In h2, we could do as much as 4 octets of confirmation for cheap, and maybe
> we should.
> https://github.com/httpwg/http-extensions/issues/617
> On Wed, May 9, 2018 at 11:28 PM Eric Rescorla wrote:
>
> > Regardless of where it goes in the document, I think there
On Thu, May 10, 2018 at 2:23 AM, Martin Thomson
wrote:
> On Thu, May 10, 2018 at 2:11 PM Viktor Dukhovni
> wrote:
> > TLS 1.3 allows clients to send multiple PSK identities, with the server
> > choosing one. When, if every, might it make sense for the client to
> > send multiple session tickets
On Thu, May 10, 2018 at 6:46 AM, Viktor Dukhovni
wrote:
>
>
> > On May 10, 2018, at 7:48 AM, Eric Rescorla wrote:
> >
> > The option for multiple PSKs is something that is used in pure PSK modes,
> > but I confess to not fully understanding the reasons you mig
On Thu, May 10, 2018 at 8:46 AM, Viktor Dukhovni
wrote:
>
>
> > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote:
> >
> >> Do you prepend some new "magic" to the (RFC5077 or similar) session
> >> tickets? Or just look for a matching STEK key na
On Tue, May 22, 2018 at 6:11 AM, Hubert Kario wrote:
> On Monday, 21 May 2018 15:47:37 CEST Ion Larranaga Azcue wrote:
> > I would say it's unfair to expect other people to diagnose the problem by
> > claiming "that information was all that was available" because you had
> > access to:
> >
> > -
On Thu, May 24, 2018 at 10:42 AM, Adam Langley
wrote:
> On Thu, May 24, 2018 at 9:52 AM Viktor Dukhovni
> wrote:
> > It might still be prudent to get the new code point re-assigned. I
> > can see some TLS-LTS stacks also supporting TLS 1.3, with TLS-TLS
> > preferred when using TLS 1.2.
>
> It'
Well, this is a bit premature because the document hasn't actually been
published, just approved.
In any case, I don't think we should assign code point 26 to this
extension. I recognize that you have existing implementations that happen
to use it, but that's a result of the unfortunate decision t
Based on this, I propose that IANA allocates a new !26 Early Data code
point for compressed certificates (that's mechanical).
As noted earlier, it's premature for TLS-LTS to request a code point
because the enabling document has not yet been published, so we can defer
the question of its use of 26
On Thu, May 31, 2018 at 7:10 PM, Peter Gutmann
wrote:
> Eric Rescorla writes:
>
> >As noted earlier, it's premature for TLS-LTS to request a code point
> because
> >the enabling document has not yet been published,
>
> And yet -compression was allocated a codep
Hi folks,
I just submitted:
https://tools.ietf.org/html/draft-rescorla-tls-esni-00
This draft describes a DNS-based approach to doing encrypted SNI.
Previously, we had thought this wouldn't work because only sites that
were particularly vulnerable would do it, and so the use of ESNI marks
you
On Mon, Jul 2, 2018 at 8:53 PM, Paul Wouters wrote:
> On Mon, 2 Jul 2018, Eric Rescorla wrote:
>
> https://tools.ietf.org/html/draft-rescorla-tls-esni-00
>>
>
> This is at a pretty early stage, so comments, questions, defect
>> reports welcome.
>>
>
>
&g
On Tue, Jul 3, 2018 at 8:40 AM, Paul Wouters wrote:
> On Mon, 2 Jul 2018, Eric Rescorla wrote:
>
> It is strongly recommended not to use TXT records. Why not use a new
>> RRTYPE? Everything these days knows how to serve unknown record
>> types
>>
hat
> can not be unscrambled is an egg."
>
>
>
> ### Copied content from the PATIENT discussion
>
>
> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty at gmail.com> wrote:
>
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla wrote:
>> >
>> &
On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian wrote:
> Looks neat.
>
> 1) TFO DOS vector: is the idea servers will disable TFO under strain but
> not be able to disable ESNI?
>
I hadn't thought about it, but that seems right. I'm not really seeing why
this is a DOS vector? At present, if you're
On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara
wrote:
> On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=
> > I am working on an implementation for NSS/Firefox and I know some
> > others are working on their own implementations, so hopefully we can
> > do som
I think it's a close call, because the length is sort of external to the
language. That's why, for instance, NSS sends "illegal_parameter". So,
absent specific text about this value, I think this is something we can
leave to the implementations.
-Ekr
On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kari
On Wed, Jul 4, 2018 at 6:27 AM, Hubert Kario wrote:
> On Wednesday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote:
> > On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote:
> > > All the implementations I deal with in my day-to-day work fail to
> handle
> > > the 0-RTT client hello corr
On Wed, Jul 4, 2018 at 6:08 AM, Ilari Liusvaara
wrote:
> On Wed, Jul 04, 2018 at 05:56:07AM -0700, Eric Rescorla wrote:
> > On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Mon, Jul 02, 2018 at 04:39:14PM
On Wed, Jul 4, 2018 at 6:36 AM, Hubert Kario wrote:
> On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote:
> > I think it's a close call, because the length is sort of external to the
> > language.
>
> which language? the decode_error alert description literal
Stephen,
Thanks for your comments.
On Wed, Jul 4, 2018 at 6:01 AM, Stephen Farrell
wrote:
>
> Hiya,
>
> On 03/07/18 00:39, Eric Rescorla wrote:
> > Hi folks,
> >
> > I just submitted:
> >
> > https://tools.ietf.org/html/draft-rescorla-tls-esni-00
&g
Hi Kathleen,
On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
> I’m also fine with the work going forward, however it was only in March
> that EKR assured people concerned that they don’t need to worry about SNI
> being encrypted repeating similar stat
On Wed, Jul 4, 2018 at 11:07 AM, Stephen Farrell
wrote:
>
> Hiya,
>
> Just on this bit...
>
> On 04/07/18 18:20, Eric Rescorla wrote:
> > The structure started a bit simpler and got new features to
> > deal with new issues. Specifically:
> >
> > - The ch
On Mon, Jun 25, 2018 at 9:20 PM, Joseph Salowey wrote:
> Hi Folks,
>
> There has been some discussion with a small group of folks on github -
> https://github.com/tlswg/dnssec-chain-extension/pull/19. I want to make
> sure there is consensus in the working group to take on the pinning work
> an
On Wed, Jul 4, 2018 at 7:33 PM, Viktor Dukhovni
wrote:
> On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:
>
> > > 1. Do you support the working group taking on future work on a pinning
> > > mechanism (based on the modifications or another approach)?
>
On Wed, Jul 4, 2018 at 8:16 PM, Viktor Dukhovni
wrote:
> On Wed, Jul 04, 2018 at 07:46:13PM -0700, Eric Rescorla wrote:
>
> > > > Do we have a count of major implementors who say they will do so?
> > >
> > > Well, what is a "major implementation&
On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd wrote:
> Fundamentally, unless this type of protection is baked into the protocol
> from the beginning, and is not an add-on option, any one/thing in the path
> can prevent the use of optional security features.
>
> Don’t want people to access site XYZ
On Fri, Jul 6, 2018 at 2:41 PM, Brian Sniffen wrote:
> Eric Rescorla writes:
>
> > On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian
> wrote:
> >
> >> Looks neat.
> >>
> >> 1) TFO DOS vector: is the idea servers will disable TFO under strain but
On Fri, Jul 6, 2018 at 7:17 PM, Short, Todd wrote:
>
> (Pardon phone typos below.)
> --
> -Todd Short
> // Sent from my iPhone
> // "One if by land, two if by sea, three if by the Internet."
>
>
> On Jul 6, 2018, at 4:43 PM, Eric Rescorla wrote:
>
>
Thanks for writing this.
I would be in favor of deprecating old versions of TLS prior to 1.2.
Firefox Telemetry shows that about 1% of our connections are TLS 1.1 (on
the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.
This is probably a higher number than we'd be comfortable turning
On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla wrote:
> Thanks for writing this.
>
> I would be in favor of deprecating old versions of TLS prior to 1.2.
> Firefox Telemetry shows that about 1% of our connections are TLS 1.1
>
This should be 1.0.
(on the same data set, TLS 1.
On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario wrote:
> On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote:
> > On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:
> > > Is there any reason why we wouldn't also consider deprecating cipher
> > > suites we don't like? For inst
Foillowing up: of course this doesn't protect you from 1.2 -> 1.0 downgrade
unless you backport the mechanism to your 1.2 implementation, which I
expect many people will not do, despite the specs.
-Ekr
On Tue, Jul 10, 2018 at 7:03 AM, Eric Rescorla wrote:
>
>
> On Tue, Jul 10
I'd like to distinguish between two different questions:
1. Whether or not the IETF should recommend that people stop using older
versions of TLS.
2. Whether or not vendors should stop accepting/supporting older versions
of TLS.
The former one of these is just exhorting people to stop, which peop
On Fri, Jul 13, 2018 at 5:24 AM, nalini elkins
wrote:
> Stephen,
>
> Sorry for the late reply. I was travelling to Montreal from India and
> was jet lagged.
>
> >
> >> I am thinking the following:
> >>
> >> Location: U.S. / Canada (possibly U.K.)
> >>
> >> - 3 banks (hopefully from the top 5)
Well, I note that the text also says "or have had very little usage,"
-Ekr
On Tue, Jul 17, 2018 at 7:57 AM, Dan Brown wrote:
> It's mainly due to CFRG's advice, isn't it?
> Calling other curves potentially unsafe or inappropriate for general use
> is a bit harsh and outside the scope of TLS, i
On Tue, Jul 17, 2018 at 8:04 AM, Johannes Merkle <
johannes.mer...@secunet.com> wrote:
> Hi,
>
> > There's a very strong reason against this: It creates complexity. More
> > opportunities for attacks, more fragmentation of the ecosystem. I
> > believe I speak for a lot of people here when I say th
On Tue, Jul 17, 2018 at 9:45 AM, Johannes Merkle <
johannes.mer...@secunet.com> wrote:
> Eric Rescorla schrieb am 17.07.2018 um 17:47:
> > We've
> > generally decided to limit the number of algorithms we recommend (the
> > Recommended) column in the registry. I h
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 connection delivered DANE TLSA records and a
>non-zero extension support
On Fri, Jul 20, 2018 at 12:29 AM, Nikos Mavrogiannopoulos
wrote:
> On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote:
> > Hi all,
> >
> > As I mentioned at the mic today, there is a question that has been
> > raised about whether it's wise to reuse an existing (TLS 1.2) PSK
> > directly in
On Fri, Jul 20, 2018 at 3:43 AM, Ilari Liusvaara
wrote:
> On Fri, Jul 20, 2018 at 10:43:48AM +0100, Matt Caswell wrote:
> >
> >
> > On 20/07/18 10:38, Eric Rescorla wrote:
> > > The issue is not cross-protocol attacks; it's the reuse of PSKs with
> >
On Fri, Jul 20, 2018 at 4:39 AM, Nikos Mavrogiannopoulos
wrote:
> On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote:
> > >
> > > > This is somewhat timely, as if we do want to introduce a
> > > restriction,
> > > > it
> > > >
John,
Thanks for your comments. It's good to know that someone has already done
this!
On Fri, Jul 20, 2018 at 12:52 PM, John Mattsson
wrote:
> Hi,
>
> I looked through the draft, mainly focusing on the crypto parts. This is
> more or less ECIES, but with a more modern style of key derivation
Unsurprisingly, I support adoption
On Tue, Jul 24, 2018 at 8:08 PM, David Benjamin
wrote:
> I too support adoption and am happy to review it.
>
>
> On Tue, Jul 24, 2018 at 10:19 PM David Schinazi
> wrote:
>
>> I support adoption, and I'm happy to review it.
>>
>> David
>>
>>
>> On Jul 24, 2018,
Ben,
Thanks for focusing on this issue.
Chris and I have been discussing an alternative design which we think
is more consistent with the existing structure, which we call PSK
Importers. As with your design, we have an input universal PSK, but
instead of using explicitly as part of the connection
On Thu, Jul 26, 2018 at 11:38 AM, Benjamin Kaduk wrote:
> On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
> > Ben,
> >
> > Thanks for focusing on this issue.
>
> Just trying to make sure loose ends get wrapped up before TLS 1.3 goes
> final.
On Fri, Jul 27, 2018 at 12:18 AM, Ilari Liusvaara
wrote:
> On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
>
> > Here’s a specific construction, but we’re flexible about the details:
> >
> >struct {
> >opaque base_identity<1...2^16-
On Fri, Jul 27, 2018 at 6:43 AM, Karthikeyan Bhargavan <
karthik.bharga...@gmail.com> wrote:
>
> As with Universal PSKs (UPSKs), each input key is a triplet of
> (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity
> as used today. To use a UPSK, an implementation takes the set of
Dear TLS WG members.
I am doing my final copy-edits for the TLS 1.3 RFC and I noted one
technical point and two points I would like to edit for clarity but I
wanted more eyes on.
1. https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.2
If the client is attempting a PSK key
On Sat, Jul 28, 2018 at 12:48 AM, Ilari Liusvaara
wrote:
> On Fri, Jul 27, 2018 at 04:20:43PM -0700, Eric Rescorla wrote:
> > Dear TLS WG members.
> >
> > I am doing my final copy-edits for the TLS 1.3 RFC and I noted one
> > technical point and two points I would lik
Thanks!
On Sun, Jul 29, 2018 at 8:10 AM, Ilari Liusvaara
wrote:
> On Sat, Jul 28, 2018 at 06:41:09AM -0700, Eric Rescorla wrote:
> >
> > The text here isn't totally generic, as it refers to scalar
> multiplication
> > and u-coordinate
> > point input. So, i
Eric Rescorla has entered the following ballot position for
draft-ietf-tls-tls13-vectors-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Awesome. Thanks!
-Ekr
On Tue, Jul 31, 2018 at 4:30 PM, Salz, Rich wrote:
>
> Has anyone checked these besides MT?
>
> Yes, openssl:
>
> commit d6ce9da49b131cad85da8c94c617febf6c8d9073
> Author: Matt Caswell
> Date: Thu Jul 19 12:46:02 2018 +0100
>
> Update the TLSv1.3 test vectors
>
ls-tls13-vectors/draft-
> ietf-tls-tls13-vectors.html
>
> The diff isn't particularly enlightening because the handshakes are
> completely different each time, but you should be able to find the
> specific changes if you look for them.
>
> On Wed, Aug 1, 2018 at 9:14 AM Eric Rescorla
On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell wrote:
>
>
> On 08/08/18 14:21, Benjamin Kaduk wrote:
> > On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Caswell wrote:
> >> Draft 28 defines the inappropriate_fallback alert as follows:
> >>
> >> inappropriate_fallback Sent by a server in response to
01 AM, Benjamin Kaduk wrote:
> On Wed, Aug 08, 2018 at 02:52:27PM +0100, Matt Caswell wrote:
> >
> >
> > On 08/08/18 14:45, Eric Rescorla wrote:
> > >
> > >
> > > On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell > > <mailto:m...@openssl.org>&
On Wed, Aug 8, 2018 at 7:11 AM, Matt Caswell wrote:
>
>
> On 08/08/18 15:06, Eric Rescorla wrote:
> > The spec is actually extremely clear on this point
> > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3
> > <https://tools.ietf.org/html/draft-i
On Thu, Aug 9, 2018 at 1:07 AM, Peter Gutmann
wrote:
> Eric Rescorla writes:
>
> >The spec is actually extremely clear on this point
> >https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3
>
> I hadn't looked at this bit too closely before, but since i
On Thu, Aug 9, 2018 at 4:57 AM, Peter Gutmann
wrote:
> Benjamin Kaduk writes:
>
> >A 1.2-capable implementation that is configured to only offer 1.1 should
> be
> >able to behave similarly.
>
> Except that it can't, because as soon as the server indicates use of TLS
> 1.1,
> the client is requir
On Thu, Aug 9, 2018 at 7:41 AM, Hubert Kario wrote:
> I've noticed that while there is an explicit requirement for extension
> types
> to be unique for any given message:
>
> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-43:
>
>There MUST NOT be more than one extension of the
>
Finally! Huge thanks to everyone who worked on this. We're already seeing a
lot of deployment in advance of the RFC, too, so great to see everyone's
hard work paying off.
-Ekr
On Fri, Aug 10, 2018 at 4:54 PM, wrote:
> A new Request for Comments is now available in online RFC libraries.
>
>
>
I support adoption
On Fri, Aug 17, 2018 at 10:32 AM, Sean Turner wrote:
> At the TLS@IETF102 session, there seemed to be some interest in adopting
> draft-moriarty-tls-oldversions-diediedie as a WG item. This email is to
> determine whether there is WG consensus to adopt this draft as a WG item.
601 - 700 of 1635 matches
Mail list logo
