On Thu, Mar 3, 2016 at 10:49 AM, Adam Langley
wrote:
> The Server Name Indication (SNI) extension in TLS has a provision to
> provide names other than host names[1]. None have even been defined to
> my knowledge, but it's there.
>
> OpenSSL (and possibly others) have had a long-standing bug[2] (f
CertificateRequest already allows you to pass an arbitrary number of
extensions by OID.
http://tlswg.github.io/tls13-spec/#certificate-request
What more do you think you need?
-Ekr
On Tue, Mar 8, 2016 at 12:22 AM, Henry Story
wrote:
> Hi,
>
>
> I was reading with interest M. Thomson and M.
This is not a TLS WG issue.
-Ekr
On Wed, Mar 9, 2016 at 6:36 AM, Henry Story wrote:
> Hi,
>
> The W3C TAG is working on a finding for Client Certificates that
> people here should find very interesting [1].
>
> One issue that comes up a lot in discussions is the use of certificates
> across
Not sure who is managing certs now that PKIX is closed. Try SAAG.
-Ekr
On Wed, Mar 9, 2016 at 8:08 AM, Henry Story wrote:
>
> On 9 Mar 2016, at 16:01, Eric Rescorla wrote:
>
> This is not a TLS WG issue.
>
>
> Where should I go to post this question? Sorry I don't
Hi Kyle,
Clever attack. I don't think it would be unreasonable to put a low
granularity time stamp in the
ClientHello (and as you observe, if we just define it it can be done
backward compatibly)
or as you suggest, in an encrypted block. With that said, though couldn't
you
also just include the in
On Sun, Mar 13, 2016 at 12:14 PM, Stephen Farrell wrote:
>
>
> However, if I'm in the rough about the above, (which seems
> to me to be the case now) then my job as AD when I get a publication
> request that includes 0rtt, will include figuring out if that's
> safe or not. And I've no clue how I'l
On Sun, Mar 13, 2016 at 2:51 PM, Stephen Farrell
wrote:
>
> > That allows
> > the
> > experts in those protocols to do their own analysis, rather than somehow
> > making it the responsibility of the TLS WG. I agree that this is a sharp
> > object
> > and I'd certainly be happy to have such a requi
On Sun, Mar 13, 2016 at 3:41 PM, Stephen Farrell
wrote:
>
> Hiya,
>
> On 13/03/16 14:01, Eric Rescorla wrote:
> >
> > This is not an accurate way to represent the situation. Those WGs can
> safely
> > move from TLS 1.2 to 1.3 *as long as they don't use 0-R
On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir wrote:
>
> > On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote:
> >
> >> I also think it is prudent to assume that implementers will turn on
> replayable
> >> data even if nobody has figured out the consequences.
> >
> > I very much agree. Customers, particu
On Sun, Mar 13, 2016 at 8:51 PM, Colm MacCárthaigh
wrote:
> On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>> With 0rtt, I think it also becomes a dangerous
>> implement. So, that's my personal opinion, while not wearing an
>> AD hat.
>>
>
> +1 for this a
On Sun, Mar 13, 2016 at 9:29 PM, Bill Cox wrote:
> On Sun, Mar 13, 2016 at 6:26 PM, Harlan Lieberman-Berg <
> hlieber...@setec.io> wrote:
>
>> Bill Cox writes:
>>
>> More generally, I strongly believe that TLS 1.3 should not
>> provide options which we think should be restricted to "admins who k
On Mon, Mar 14, 2016 at 12:25 PM, Dave Garrett
wrote:
> (This thread has gotten long and winding, so I'm replying to these two
> portions bellow under a new subject. Reply after quotations.)
>
> On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote:
> > On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCár
we'll find a
> whole range of other similar attacks using 0RTT.) An encrypted client
> timestamp could presumably be probed by the server. (ie, if the server
> response is a different size for timestamp-expired vs timestamp-not-expired
> an attacker could keep probing until they c
ates to distinguish these.
As far as process, it seemed like people were generally positive about this
in this discussion,
but I'll rely on the chairs to determine consensus.
-Ekr
On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin
wrote:
> On Fri, Jan 15, 2016 at 8:23 PM Eric Resc
On Mon, Mar 14, 2016 at 5:44 PM, Ryan Hamilton wrote:
> On Mon, Mar 14, 2016 at 2:04 PM, Colm MacCárthaigh
> wrote:
>
>> On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton wrote:
>>>
>>> On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton
>>> wrote:
>>>
0-RTT seems to be a solution looking for a
On Mon, Mar 14, 2016 at 11:38 AM, Bill Cox wrote:
> On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh
> wrote:
>
>> On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox wrote:
>>
>>> As we all know, what matters most in security is the default mode. I am
>>> suggesting making the default 0-RTT resumptio
On Mon, Mar 14, 2016 at 7:25 PM, Martin Thomson
wrote:
> On 15 March 2016 at 13:22, Bill Cox wrote:
> > In TLS 1.3, tickets are sent after the full handshake completes, after
> > encryption is enabled for the connection. Now, if an attacker has the
> > ticket encryption key, it is not possible
On Tue, Mar 15, 2016 at 12:51 PM, Bill Cox wrote:
> I think it is worth documenting what we feel would be the simplest secure
> 0-RTT mode that is safe for any company to use. I think we owe the users a
> link to such a document in the TLS 1.3 spec. Here is my attempt at
> creating the simplest
On Tue, Mar 15, 2016 at 1:46 PM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Hi Ekr, Hi all,
>
> I am not entirely sure about the PSK story in TLS 1.3.
>
> In Section 6.2.3 I read that the PSK approach has been combined with
> resumption.
>
> Appendix A4 lists the defined ciphersuites
On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin
wrote:
> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote:
>
>> David,
>>
>> Thanks for being patient with me here. Sorry it took so long
>>
>> As usual, this seems like a question of whether we'
Piling on, I can't see why we would want to do this
-Ekr
On Thu, Mar 17, 2016 at 7:09 PM, Martin Thomson
wrote:
> On 18 March 2016 at 12:37, Mike Hamburg wrote:
> > No. The goal should be to remove ciphers, not add new ones, unless we
> have
> > a really compelling reason.
>
> A necessary, b
On Wed, Mar 16, 2016 at 5:47 PM, David Benjamin
wrote:
> On Tue, Mar 15, 2016 at 7:06 PM Eric Rescorla wrote:
>
>> On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin
>> wrote:
>>
>>> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote:
>>>
>&
On Sun, Mar 20, 2016 at 4:09 AM, Ilari Liusvaara
wrote:
>
> [1] TLS 1.3 doesn't completely fix this: Even if TLS 1.3 itself has
> negotiated DHE parameter sizes, there is nothing preventing down-
> negotiation to TLS 1.2, followed by server dumping some bad para-
> meter sizes (forcing client to e
It sounds like we have general consensus here. Does anyone object to my
merging
this PR?
-Ekr
On Thu, Mar 17, 2016 at 10:34 AM, Ilari Liusvaara
wrote:
> On Tue, Mar 15, 2016 at 05:37:20PM +, David Benjamin wrote:
> > On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote:
>
Note: TLS 1.3 should significantly decrease the risk of this because the
record sequence number is used as the nonce, therefore if you fail to
increment the sequence number, you will quickly not interoperate with
other implementations which are correct.
-Ekr
On Sun, Mar 20, 2016 at 12:53 PM, Har
Atul, Kenny,
Thanks for doing this. My initial impression is that these results are
uncomfortably
close to the line for AES-GCM, especially for the scenario where we have
multiple
keys: there are probably well upward of 2^{32} HTTPS connections a day.
A few questions:
1. As I understand it, fai
Acknowledged. This will be in draft-12.
On Sun, Mar 20, 2016 at 5:27 PM, Joseph Salowey wrote:
> No objection, it looks good. I don't see any objections on the list so I
> say merge it.
>
> On Sun, Mar 20, 2016 at 10:50 AM, Eric Rescorla wrote:
>
>> It sounds like
Our long national nightmare is over.
On Mon, Mar 21, 2016 at 7:42 AM, Sean Turner wrote:
> FYI
>
> > Begin forwarded message:
> >
> > From: "Sean Turner"
> > Subject: Publication has been requested for draft-ietf-tls-falsestart-01
> > Date: March 21, 2016 at 10:42:10 EDT
> > To:
> > Cc: "Sean
On Mon, Mar 21, 2016 at 2:59 PM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Hi Ekr,
>
> ~snip~
>
> > Section 6.3.1.2 explains that the ServerHello message handling:
> >
> > "
> > The server will send this message in response to a ClientHello
> message
> > when it was a
Folks,
I've just submitted TLS 1.3 draft-12 and it should appear once it
makes its way through secretariat processing. Until then, you can find
it at:
http://tlswg.github.io/tls13-spec/
This revision is largely cleanup of a bunch of outstanding PRs and of
issues found during interop testing.
On Mon, Mar 21, 2016 at 9:22 PM, Dave Garrett
wrote:
> On Monday, March 21, 2016 06:08:45 pm Eric Rescorla wrote:
> > Ah, I see. Let me see if I can clear this up, if you wanted to send a PR,
> > that wouldn't help too.
>
> I assume you meant "wouldn't hurt&
On Tue, Mar 22, 2016 at 5:38 PM, Timothy Jackson
wrote:
> I’ve noted that many (most?) TLS implementations choose their ECDHE curves
> seemingly without regard to the cipher suite strength. Thus, they'll select
> an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then
> generat
On Fri, Mar 25, 2016 at 8:33 AM, Bill Cox wrote:
> Adding 1 byte EarlyDataType seems like a good idea.
>
> As for the CipherSuite, assuming DH-0RTT goes away, would it be simpler to
> require that the cipher suite negotiated from the original 1-RTT connection
> be used?
>
> For channel binding, t
Karthik,
Thanks for sending this. Some initial thoughts below.
> After implementing and analyzing TLS 1.3, here are a few suggestions for
discussion.
>
> 1) Early Data Extension
>
> The current early-data extension is too DH-specific.
> When using PSK, we now have to look at both early_data and p
On Fri, Mar 25, 2016 at 11:27 AM, Colm MacCárthaigh
wrote:
>
> +1 but I think we can go further here and specify 0RTT in such a way that
> it only works when the server maintains state, and so that any given 0RTT
> ticket may only be used once (to preserve forward secrecy as much as
> possible wit
On Fri, Mar 25, 2016 at 11:38 AM, Karthik Bhargavan <
karthikeyan.bharga...@inria.fr> wrote:
> Hi Eric,
>
> Yes, I now agree with Ilari and you that we should have a separate
> pre_shared_key extension
> in order to signal multiple PSKs. I wonder if we could still share the
> structure between
> P
On Fri, Mar 25, 2016 at 12:23 PM, Colm MacCárthaigh
wrote:
> On Fri, Mar 25, 2016 at 11:36 AM, Eric Rescorla wrote:
>
>> On Fri, Mar 25, 2016 at 11:27 AM, Colm MacCárthaigh
>> wrote:
>>>
>>> +1 but I think we can go further here and specify 0RTT in such a
Yes, I believe that this is what people want.
On Mon, Mar 28, 2016 at 2:47 PM, Andrei Popov
wrote:
> Not sending cookies/authz headers in 0-RTT would solve a part of the
> problem, but will browser vendors go for that? I could be wrong, but there
> seems to be considerable interest in 0-RTT Toke
On Tue, Mar 29, 2016 at 10:14 AM, Wan-Teh Chang wrote:
> On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner wrote:
> >
> > There also seems to be (rougher) consensus not to support 0-RTT via DHE
> > (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT
> mode
> > as PSK. The security
I have taken an initial look at this document, but I find myself confused
about the security
model.
Specifically, you say that you can't use SNI because customers will lie and
insert
the SNI for service A in the ClientHello when going to service B. However,
I don't
see how this token stops that, s
On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang
wrote:
> Hi, Ekr:
>
> Thanks for reviewing the draft and the comments. Please see my reply
> inline please.
>
> 发件人: Eric Rescorla
> 日期: 2016年3月30日 星期三 上午7:21
> 至: dacheng de
> 抄送: Eric Mill , Dave Garrett ,
>
dom. However in 1.3 it contains the
DH
key share, which the attacker doesn't know the corresponding private value
for.
-Ekr
On Tue, Mar 29, 2016 at 8:53 PM, Martin Thomson
wrote:
> On 30 March 2016 at 14:19, Eric Rescorla wrote:
> > That wouldn't work with TLS 1.2 but would w
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 impact of the recent paper by Jager at al. [0] on TLS 1.3 and
QUIC
On Tue, Mar 29, 2016 at 9:04 PM, Dacheng Zhang
wrote:
> Hi, Erk:
>
> My reply inline please.
>
> Cheers
>
> Dacheng
>
> 发件人: Eric Rescorla
> 日期: 2016年3月30日 星期三 上午11:19
> 至: dacheng de
> 抄送: Eric Mill , Dave Garrett ,
> tls
> 主题: Re: [TLS] 回复： A TL
I am in favor of this.
On Tue, Mar 29, 2016 at 6:53 PM, Sean Turner wrote:
> Hi!
>
> In Yokohama, we discussed changing the IANA registry assignment rules for
> cipher suites to allow anyone with a stable, publicly available, peer
> reviewed reference document to request and get a code point and
On Wed, Mar 30, 2016 at 8:37 AM, Bill Cox wrote:
> On Wed, Mar 30, 2016 at 8:22 AM, 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
&g
On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett
wrote:
> On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote:
> > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to
> > PKIX.
>
> Adding a PKIX extension to mandate a minimum threshold o
On Wed, Mar 30, 2016 at 2:47 PM, Ilari Liusvaara
wrote:
> On Wed, Mar 30, 2016 at 01:33:57PM -0700, Eric Rescorla wrote:
> > On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett
> > wrote:
> >
> > > On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote:
> > &
On Wed, Mar 30, 2016 at 3:57 PM, Martin Thomson
wrote:
> On 31 Mar 2016 5:56 AM, "Ilari Liusvaara"
> wrote:
> > Then on topic of 0-RTT, how does 0-RTT key hashes behave if
> > handshake is restarted (main handshake hash continues, but
> > 0-RTT hash context currently needs to be separate from th
On Wed, Mar 30, 2016 at 4:16 PM, Stephen Farrell
wrote:
>
> (with no hats, except the one irritated with loadsa ciphersuites:-)
>
> On 30/03/16 21:26, Yoav Nir wrote:
> > That brings up another question. How do things move from “approved”
> > to “not-approved”? Does it require a diediedie documen
On Wed, Mar 30, 2016 at 10:40 PM, Dacheng Zhang wrote:
> Thanks again for your comments. See my reply inline please. ^_^
>
>>
>> I'm not following. If you trust the device, then why do you need any kind
>> of cryptographic
>> authentication on the token.
>>
>> Dacheng：Let assume we trust the devi
Hannes,
No, the proposal is to remove both EC and non-EC DHE 0-RTT profiles.
The only way to do 0-RTT would be with a PSK (in both PSK and PSK-(EC)DHE
modes).
However, this would include PSKs established via a previous session, i.e.,
resumption-PSK.
-Ekr
On Thu, Mar 31, 2016 at 5:20 AM, Hannes
On Thu, Mar 31, 2016 at 8:33 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Hi Ekr,
>
>
> On 03/31/2016 05:05 PM, Eric Rescorla wrote:
> > Hannes,
> >
> > No, the proposal is to remove both EC and non-EC DHE 0-RTT profiles.
> >
> >
On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk wrote:
> On 03/31/2016 12:02 PM, Bill Cox wrote:
>
> On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
>> Hi Sean,
>>
>> we at ARM would find it somewhat unfortunate to remove the client
>> authentication fe
The primary purpose of this compromise is to unjam the many requests for
code
points that otherwise clog the WG and expert review process. I believe it
will at
least do that.
-Ekr
On Thu, Mar 31, 2016 at 10:14 AM, Benjamin Kaduk wrote:
> Well, "most people [in the world" do not care about any
On Thu, Mar 31, 2016 at 10:17 AM, Benjamin Kaduk wrote:
> On 03/31/2016 12:13 PM, Eric Rescorla wrote:
>
>
>
> On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk <
> bka...@akamai.com> wrote:
>
>> On 03/31/2016 12:02 PM, Bill Cox wrote:
>>
>> On Th
Hannes,
Aside from JPAKE, which algorithms are you concerned about?
-Ekr
On Thu, Mar 31, 2016 at 10:40 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> I can see some value in having this IANA registry list for ciphersuites
> in the way being proposed (even if it may be interpreted
On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk
wrote:
>
>
> On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner wrote:
>
>> All,
>>
>> To make sure we’ve got a clear way forward coming out of our BA sessions,
>> we need to make sure there’s consensus on a couple of outstanding issues.
>> So...
>>
>> Th
On Fri, Apr 1, 2016 at 7:19 AM, Stephen Farrell
wrote:
>
> > Forward secrecy can be achieved using ephemeral Diffie-Hellman or
> > ephemeral Elliptic-Curve Diffie-Hellman ...
> >
> > If we summarize these in the Introduction we’re good?
>
> No, I'm on about missing text not placement of text. Aga
Let's not do this.
See https://www.ietf.org/mail-archive/web/tls/current/msg19347.html for an
alternative design for this that does not require weakening TLS.
-Ekr
On Mon, Apr 4, 2016 at 2:24 PM, Phil Lello wrote:
> Hi,
>
> I have a use-case for allowing an MITM to monitor traffic, but not
>
On Fri, Apr 8, 2016 at 6:13 PM, Bill Cox wrote:
> On Fri, Apr 8, 2016 at 1:50 PM, Jim Roskind wrote:
>
>> The combination of DHE and TLS 1.3 session resumption via session
>> tickets, can destroy the forward secrecy property that DHE was intended to
>> provide. With the proposed removal of DHE-
On Fri, Apr 8, 2016 at 6:42 PM, Wan-Teh Chang wrote:
> On Fri, Apr 8, 2016 at 2:31 PM, Eric Rescorla wrote:
> >
> > ... TLS 1.3 supports two PSK-resumption modes:
> >
> > 1. Pure PSK, which has somewhat better security properties than in TLS
> 1.2
> > 2. P
On Fri, Apr 8, 2016 at 10:26 PM, Tanja Lange
wrote:
> Looks like this didn't make it out to the list. Forwarding
> from my email address a message by Jon Solworth.
>
> - Forwarded message from "Jon A. Solworth"
> -
>
> Date: Fri, 8 Apr 2016 17:33:57 -0500
> From: "Jon A. Solworth"
> To:
On Mon, Apr 11, 2016 at 9:36 AM, D. J. Bernstein wrote:
> Eric Rescorla writes:
> > DNS-based priming is a seemingly attractive concept but unfortunately
> isn't
> > really workable here, for several reasons:
> > 1. It requires DNS security
>
> No, it doesn&#
which
case
the attack would be limited to the 0-RTT data).
-Ekr
On Mon, Apr 11, 2016 at 10:10 AM, Eric Rescorla wrote:
>
>
> On Mon, Apr 11, 2016 at 9:36 AM, D. J. Bernstein wrote:
>
>> Eric Rescorla writes:
>> > DNS-based priming is a seemingly attractive concept
I wouldn't object in general to requiring sorting, but...
1. I wouldn't want to renumber existing extensions.
2. Servers badly handle some extension orderings (e.g., an empty extension
at the end)
So we would need to stay withing these guiderails.
-Ekr
On Thu, Apr 21, 2016 at 2:26 PM, Bill Cox
On Mon, Apr 25, 2016 at 11:07 AM, Jim Schaad wrote:
> I was looking at how TLS 1.3 was going to fit into an upgrade from the
> existing 1.2 version that is used for RADIUS and having vague memories of
> what was going on during the F2F meeting and I ended up with the following
> question.
>
> We
On Mon, Apr 25, 2016 at 12:13 PM, Jim Schaad wrote:
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Monday, April 25, 2016 11:10 AM
> *To:* Jim Schaad
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] NewSessionTicketFormat - for
I recently reviewed draft-guballa-tls-terminology-03. Comments below.
OVERALL
I'm sympathetic to concerns that TLS terminology may not be as precise
as one would like, but IMO this document doesn't make things significantly
clearer and in some cases makes it worse. Specifically:
- (D)TLS is inten
https://github.com/tlswg/tls13-spec/pull/446
Per discussion in Buenos Aires, this PR allows the server to send
SupportedGroups.
Target merge date: Monday 5/2.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara
wrote:
> Some comments:
>
Please note: this PR is still a WIP. I'll be updating it in a bit...
> - I presume 0-RTT used in retried ClientHello uses (and for the verify
> mechanism to work, that needs to be allowed!) uses ClientHello1...
>
On Thu, Apr 28, 2016 at 1:43 PM, Eric Rescorla wrote:
> On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara <
> ilariliusva...@welho.com> wrote:
>
>> Some comments:
>>
>
> Please note: this PR is still a WIP. I'll be updating it in a bit...
>
>
>
&
On Thu, Apr 28, 2016 at 2:40 PM, Ilari Liusvaara
wrote:
> On Thu, Apr 28, 2016 at 01:43:41PM -0700, Eric Rescorla wrote:
> > On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> >
> > > - I presume 0-RTT
Hi folks,
I've posted two PRs:
https://github.com/tlswg/tls13-spec/pull/444
https://github.com/tlswg/tls13-spec/pull/445
These enact several consensus decisions from Buenos-Aires:
1. Remove 0-RTT (EC)DHE leaving only PSK-based 0-RTT (444)
2. Remove 0-RTT client auth (444)
3. Enhance the NewSessi
On Fri, Apr 29, 2016 at 8:38 AM, Ilari Liusvaara
wrote:
> On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote:
> > On 29 April 2016 at 15:58, Ilari Liusvaara
> wrote:
> > >> [HRR state]
> > >
> > > That enlarges the state that needs to be kept. If one keeps extensions,
> > > one only
On Fri, Apr 29, 2016 at 8:35 AM, Guballa, Jens (Nokia - DE) <
jens.guba...@nokia.com> wrote:
> Hi Eric,
>
>
>
> See below.
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *EXT Eric Rescorla
> *Sent:* Dienstag, 26. April 2016 19:46
> *To:* tl
On Fri, Apr 29, 2016 at 10:46 AM, Ilari Liusvaara
wrote:
> On Fri, Apr 29, 2016 at 09:16:07AM -0700, Eric Rescorla wrote:
> > On Fri, Apr 29, 2016 at 8:38 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Fri, Apr 29, 2016 at
PR: https://github.com/tlswg/tls13-spec/pull/448
Targe landing date: Wednesday
In Buenos Aires we discussed moving CertificateStatus to part of the
Certificate message. In offline conversations, it started to look like that
wasn't optimal in part because it created an asymmetry wrt Signed
Certific
On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen
wrote:
> Hi,
>
>
> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla wrote:
>
> PR: https://github.com/tlswg/tls13-spec/pull/448
>> Targe landing date: Wednesday
>>
>> In Buenos Aires we discussed mov
On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen
wrote:
> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla wrote:
>
> On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen
>> wrote:
>>
>> Hi,
>>>
>>>
>>> On Mon, 02 May 2016 22:43:09 +0200
-Ekr
On Mon, May 2, 2016 at 2:45 PM, Watson Ladd wrote:
> On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla wrote:
> >
> >
> > On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen
> > wrote:
> >>
> >> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla wro
On Mon, May 2, 2016 at 3:01 PM, Yngve N. Pettersen
wrote:
> On Mon, 02 May 2016 23:54:32 +0200, Eric Rescorla wrote:
>
> Sorry, I'm responding to Yngve's "MUST" suggestion.
>>
>> I think what would be reasonable would be:
>>
>> - clients MAY
https://github.com/tlswg/tls13-spec/pull/449
In Buenos Aires, we agreed to add EncryptedExtensions from the client
in 0-RTT to carry the ticket age/elapsed_time. I have written this up in
the PR above. Comments welcome.
Target Merge date: Friday.
-Ekr
Interesting suggestion. I see what you mean about symmetry with the server
The symmetry I was optimizing for is that the PSK and non-PSK handshake,
and I think from that perspective the current design is simpler, so I see
it both ways.
WRT to the 0.5RTT data, Hugo Krawczyk has done some nice work
uest in a PSK-based cipher wasn't
> allowed. RFC 4279 explicitly says it's not allowed in plain PSK. It's not
> clear whether that applies to DHE_PSK, but I think that combined with 1.2's
> "non-anonymous" rule gives client auth => certificate-based cipher as the
PR: https://github.com/tlswg/tls13-spec/pull/454
I have uploaded a PR [technically two PRs, but one builds on the
other, so easier to just read the composition] which resolves two out
of the three significant remaining crypto issues (the remaining one is
the long-running discussion of post-handsha
Yes, I think this would be good text. PR wanted :)
-Ekr
On Thu, May 19, 2016 at 11:19 AM, Kyle Rose wrote:
> Regarding the ability for passive observers' tracking of clients
> across connections (and potentially across IPs) via a session ticket
> used more than once, should there be any languag
On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara
wrote:
> On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote:
> >
> > An additional nice point about this design is that it easily
> > accomodates additional keys. For instance, if we had some post-quantum
> &
Sorry, I think you lost me there. Can you rephrase?
-Ekr
On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara
wrote:
> On Thu, May 19, 2016 at 12:13:45PM -0700, Eric Rescorla wrote:
> > On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> >
Thanks for the clarification. Yes, I believe that is true.
-Ekr
On Thu, May 19, 2016 at 11:34 PM, Ilari Liusvaara
wrote:
> On Thu, May 19, 2016 at 02:38:35PM -0700, Eric Rescorla wrote:
> > On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara <
> ilariliusva...@welho
Merged.
On Thu, May 19, 2016 at 10:41 AM, Eric Rescorla wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/454
>
> I have uploaded a PR [technically two PRs, but one builds on the
> other, so easier to just read the composition] which resolves two out
> of the three signif
https://github.com/tlswg/tls13-spec/issues/471
http://tlswg.github.io/tls13-spec/#alert-protocol says:
"Alert messages with a level of fatal result in the immediate termination
of the connection. In this case, other connections corresponding to the
session may continue, but the session identifie
https://github.com/tlswg/tls13-spec/issues/472
http://tlswg.github.io/tls13-spec/#error-alerts says:
Therefore, warning alerts are not very useful when
the sending party wants to continue the connection, and thus are sometimes
omitted. For example, if a party decides to accept an expired ce
On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara
wrote:
> Looking at PR #468:
> - It isn't at all obvious how to use it for stateless rejection.
> - It is even less obvious how to recover (not causing non-retryable
> fault) from bad cookie (e.g. expired) remembered from previous
> connection.
On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara
wrote:
> On Sun, May 22, 2016 at 07:49:12AM -0700, Eric Rescorla wrote:
> > On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > Looking at PR #468:
> >
Folks,
I just uploaded draft-13. Changelog appended at the bottom of this
message.
The following nontrivial issues are outstanding:
- How to encrypt post-handshake messages (post-handshake client auth,
NewSessionTicket, etc.). I'm having a discussion now with the
cryptographers about this.
On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara
wrote:
> On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote:
> > On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > Actually, looking
On Sun, May 22, 2016 at 1:48 PM, Ilari Liusvaara
wrote:
> On Sun, May 22, 2016 at 12:50:38PM -0700, Eric Rescorla wrote:
> > On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Sun, May 22, 2016 a
On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed)
wrote:
>
>
> On 5/24/16, 2:42 PM, "Martin Thomson" wrote:
>
> >On 24 May 2016 at 10:46, Dang, Quynh (Fed) wrote:
> >>>We discussed this at quite some length. I originally took your
> >>>position, but the IVs add an extra layer of safety at ve
racking your key?
>
> Quynh.
> On May 24, 2016 3:05 PM, "Eric Rescorla" wrote:
>
>>
>>
>> On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed)
>> wrote:
>>
>>>
>>>
>>> On 5/24/16, 2:42 PM, "Martin Thomson" wrote:
>
901 - 1000 of 1635 matches
Mail list logo
