On Mon, Jul 13, 2015 at 06:10:52PM +0200, Martin Rex wrote:
> Dave Garrett wrote:
> > On Monday, July 13, 2015 10:30:06 am Martin Rex wrote:
> >> Section 7.4.1.4 Hello Extensions and its subsections are clearly
> >> IRRELEVANT for a client that does not use Hello Extensions.
> >
> > If you want to
On Tue, Jul 14, 2015 at 05:23:44PM +0200, Simon Josefsson wrote:
> Hubert Kario writes:
>
> > So unless the PKIX and TLS parts are defined at the same time, in the same
> > document, we definitely need to keep them apart.
>
> It is conceivable to reuse the NamedCurve values for TLS authenticati
Let's review: draft-ietf-tls-tls13-07
This is abridged version of mail I sent earlier, but was too large for
the list due to its sheer size.
(Note: I omitted some stuff I saw recently discussed (e.g. pruning
unused crypto algorithms) or I remember discussed. I didn't explicitly
check issue list w
On Wed, Jul 15, 2015 at 02:29:09PM -0700, Eric Rescorla wrote:
Firstly, the 0-RTT binding and how does server know it ended thing:
Assume that if 0-RTT is accepted, the contents affect crypto keys,
channel binding values, finished messages, etc...
>From this it follows that server needs to recei
On Sat, Jul 18, 2015 at 09:22:12PM -0400, Dave Garrett wrote:
> There's two issues (basically duplicates) for this topic, as well as an
> inline TODO.
> https://github.com/tlswg/tls13-spec/issues/66
> https://github.com/tlswg/tls13-spec/issues/72
> https://tlswg.github.io/tls13-spec/#server-hello
On Sat, Jul 18, 2015 at 02:28:40PM -0400, Dave Garrett wrote:
> On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote:
> > This is not really what I was intending when I suggested the feature. I was
> > intending for their to be an indication, in the ClientHello, that the
> > server should not d
On Mon, Jul 20, 2015 at 12:55:37PM +0200, Hubert Kario wrote:
> On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote:
> >
> > Compare how we "reuse" the ECDHE ciphersuite values to refer to
> > Curve25519 (instead of defining new ciphersuites for Curve25519), and
> > how we are "reusing" the "unc
On Mon, Jul 20, 2015 at 01:42:01PM +0200, Hubert Kario wrote:
> On Monday 20 July 2015 14:39:03 Ilari Liusvaara wrote:
> > On Mon, Jul 20, 2015 at 12:55:37PM +0200, Hubert Kario wrote:
> >
> > There are other shortcomings tho:
> > - If Ed25519 is supported, one also
Some commentary on client authentication slides (there is no linked draft
nor other material yet).
- Mechanism like proposed looks dangerous when combined with HTTP/2.
Multiplexed protocols are in general not safe to authenticate without
application-layer signaling (which can be implicit via s
On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson
> wrote:
>
> > On 21 July 2015 at 04:12, Eric Rescorla wrote:
> > >
> > > Yes, that's an issue. Not entirely sure what to do about other than
> > > have the server provide its negotia
On Tue, Jul 21, 2015 at 02:55:33PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara <
> ilari.liusva...@elisanet.fi> wrote:
>
> > For 0-RTT/Early handshake data you want cipher that the server
> > supports and accepts. If it is about th
On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote:
> On 21 July 2015 at 06:08, Ilari Liusvaara wrote:
> > Well, if it is about supported ciphers, there could be multiple, and
> > the proposal has slot for only one.
>
> The proposal is for what the client sel
On Tue, Jul 21, 2015 at 04:39:17PM +0200, Johannes Merkle wrote:
>
> I absolutely back up this position. Currently, the TLS 1.3 draft only permits
> curves over special primes. It has become
> quite clear in the discussions in CFRG and at the NIST ECC workshop that some
> parties (major hardware
On Tue, Jul 21, 2015 at 05:09:31PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara <
> ilari.liusva...@elisanet.fi> wrote:
> >
> > Also, with regard to ending 0RTT, even without encrypted content
> > types. Either I am misunderstanding s
On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrote:
> On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote:
> > I thought that Brainpool curves weren't removed (even if those aren't
> > explicitly in), which are random prime curves.
> >
> >
On Wed, Jul 22, 2015 at 02:16:43AM -0700, Martin Thomson wrote:
> On 22 July 2015 at 01:50, Kyle Rose wrote:
> > I'd like to see the bits of the cipher suite associated entirely with
> > ephemeral data tied together roughly by security margin
>
> I've seen this argument several times, but there a
On Wed, Jul 22, 2015 at 04:10:27PM -0400, Dave Garrett wrote:
> Consensus was my current WIP proposal is not viable, for some of the
> following main reasons:
>
> 1) cost/benefit analysis doesn't seem to be worth it
> 2) backwards compatibility handling
> 3) some argue harder to implement; others
On Fri, Jul 24, 2015 at 05:01:37AM +, Andrei Popov wrote:
>
> > - The certificate_types field in CertificateRequest is pretty much
> > useless, since all supported algorithms are of signature type.
> If the signature_algorithms extension officially becomes MTI, then
> perhaps we can discus ge
On Thu, Jul 23, 2015 at 06:06:04PM +0100, Stephen Farrell wrote:
>
>
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> >
> > Right now, the restriction
On Thu, Jul 23, 2015 at 07:10:30PM +0200, Eric Rescorla wrote:
> On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
> wrote:
>
> > A suggestion - could we remove mention of anything that
> > is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> > and then have someone write a separate draf
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
> resumption problem, which anyways, should be fixed by the session hash)
> and easy to underst
> On Tue, Jul 28, 2015 at 6:28 PM David Benjamin wrote:
>
> > Are you intending that this mechanism be enabled by default for HTTP/2 or
> > would the prohibition against renego still apply? Without any way for the
> > client to tie the CertificateRequest to the HTTP request that triggered it,
> >
On Sun, Aug 02, 2015 at 03:38:00PM +, David Benjamin wrote:
> On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara
> wrote:
> >
> > What I think would be very useful: A way for client to signal it has a
> > client certificate it expects to use, regardless of if valid configu
On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote:
>
>
> We agreed on how to do this in Prague. The sticking point was establishing
> the cipher suite. I have WIP text on my machine for both of these which I
> will be
> sending early next week, once I get enough sleep to be able to cl
On Tue, Aug 04, 2015 at 10:35:30AM -0700, Martin Thomson wrote:
>
> As for the wasted bytes, I don't care for that. We will fix that later.
It is not just wasted bytes.
It is also increased auditing requirements: Auditing that the nonce
generation is sound (e.g. not random).
And in constructs
This is about adding a new signature primitive (such as the
(eventual) CFRG scheme).
There are basically two issues:
1) Do we allocate new ciphersuite codepoints or not? So far
each certificate algorithm in ciphersuite has corresponded
to only one signature algorithm.
Implications of new codepoi
On Fri, Aug 07, 2015 at 02:50:14PM -0700, Eric Rescorla wrote:
> I've updated the PR based on feedback from Dave, Ilari, and Martin.
>
> https://github.com/tlswg/tls13-spec/pull/211
>
> I'll merge this PR on 8/11 unless there are serious objections. As usual
> please send minor changes as github
On Tue, Aug 04, 2015 at 12:37:47AM +, Andrei Popov wrote:
> > Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS.
> > There one likely "preconfigures" client certificates if needed.
> The proposed client authentication mechanism specifically addresses
> the case where the c
On Mon, Aug 10, 2015 at 07:33:53PM +, David Benjamin wrote:
>
> Why not do this using HTTP's own auth framework? Have the client sign
> something which includes a channel binding, placing it and the certificate
> chain in an Authorization header. You could even transition to it in TLS
> 1.2 de
On Tue, Aug 11, 2015 at 11:29:12AM -0700, Martin Thomson wrote:
> On 11 August 2015 at 11:25, Karthikeyan Bhargavan
> wrote:
> > No, a regular ECDSA certificate would do.
> > That is, the attack would work as long as
> > - a client has an ECDSA certificate, and
> > - it enables any static TLS_ECDH
On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:
>
> Below a long list of comments, generally minor. The document is
> already very good - we're making great progress!
> The record length field is limited by encrypted-length+2048.
> Shouldn't it be 1024? - "Eac
On Fri, Aug 28, 2015 at 07:17:39PM +, Dang, Quynh wrote:
> Hi all,
>
> DSA is supported in the previous versions of TLS. It would be nice
> if someone who uses DSA can use it in TLS 1.3 as well.
Well, at least for the web, DSA is no longer an option because
major browsers have dropped support
On Tue, Sep 01, 2015 at 05:58:33PM +, Salz, Rich wrote:
> There is a third option: you don't get to use TLS 1.3 until the
> government requirements are updated.
>
> I'm fine with that.
I think they already have, with NSA seemingly saying RSA3k is OK for
up to TOP SECRET (unless I misundersto
On Tue, Sep 15, 2015 at 08:17:56PM +, Andrei Popov wrote:
> Perhaps we can simplify the protocol by pulling client auth out of the
> handshake as follows:
Problem with pulling client auth out of the handshake is that it
complicates applications that can't change identities involved with
active
On Wed, Sep 16, 2015 at 10:48:27AM -0700, Martin Thomson wrote:
> On 16 September 2015 at 08:30, Ilari Liusvaara
> wrote:
> > Problem with pulling client auth out of the handshake is that it
> > complicates applications that can't change identities involved with
> >
On Mon, Sep 21, 2015 at 07:38:45AM +0200, Karthikeyan Bhargavan wrote:
>
> In other words, if we do allow this change to client authentication,
> to be safe, we must analyze the resulting protocol *as if*
> applications will use the authentication event to attest to all data,
> past and present, t
On Tue, Sep 22, 2015 at 04:27:35PM -0700, Sean Turner wrote:
> I’ve gone ahead and posted the minutes/list of decisions to:
>
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3
Minutes:
> ## Issue 223 - absolute or relative time
>
> Leave as-is because
On Wed, Sep 23, 2015 at 01:43:29PM +, Dang, Quynh wrote:
> I am just curious why we need the content type here?
The "outer" content type is needed for backward compatiblity. The
"inner" content type is needed for stuff like handshake vs. alert or
appdata vs. alert.
-Ilari
_
On Wed, Sep 23, 2015 at 08:50:16AM -0700, Eric Rescorla wrote:
> On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara <
> ilari.liusva...@elisanet.fi> wrote:
>
> > investigate: using the same construct for server/client sigs.
> >
> > Huh? Don't both currently
On Wed, Sep 23, 2015 at 10:33:29AM +0200, Simon Josefsson wrote:
> Hi all,
>
> I have pushed out a new version of the document describing EdDSA public
> keys, signatures and certificates for PKIX. The change in -03 include
> the addition of the prehash mode, test vectors generated by GnuTLS, and
On Thu, Sep 24, 2015 at 04:03:28PM +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, 2015-09-24 at 15:27 +0300, Ilari Liusvaara wrote:
>
> > 4) For TLS PoP signatures, does it make sense to use HashEdDSA at
> > all?
> > Another way would to always use PureEdDSA and perform
On Sat, Oct 03, 2015 at 12:02:38PM -0400, Daniel Kahn Gillmor wrote:
> On Fri 2015-10-02 12:24:24 -0400, Martin Rex wrote:
>
> > But the collateral damage is that you break stuff that feeds on the
> > outer record layer structure and state, which can easily push adoption
> > of TLSv1.3 from the 5-
On Thu, Oct 08, 2015 at 12:04:51PM +0200, Eric Rescorla wrote:
>
> Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF.
>
> With that said, I don't really understand the structure of your draft:
> Instead of referencing the PRF and session_hash directly, why not instead
> use RFC 5
On Sat, Oct 10, 2015 at 07:44:04PM +0200, Eric Rescorla wrote:
> On Sat, Oct 10, 2015 at 7:37 PM, Dave Garrett
> wrote:
>
> > In light of completely unsurprising recent events [0], I think it's time
> > to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3.
> > Currently, it's
On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote:
> > *From:* internet-dra...@ietf.org
> >
> > Name: draft-vanrein-tls-kdh
> > Revision: 00
>
> Hello TLS WG,
>
> I would like to propose new CipherSuites for TLS. The cryptography is
> founded on Kerberos authentication
On Mon, Oct 12, 2015 at 07:14:05AM +0200, Rick van Rein wrote:
> Hello,
>
> Thanks for the feedback. Responding to it:
>
> Ilari> - The signed DH share does not look to be bound to anything (crypto
> Ilari> parameters negotiation, randoms, server key exchange, etc..).
>
> This is indeed ea
On Mon, Oct 12, 2015 at 04:48:08AM -0700, Eric Rescorla wrote:
> On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote:
>
> > aren't we still missing the 0-RTT mode?
>
> It's in the current draft though there are a few details that we're
> going to need to nail down over the next few weeks and in
On Mon, Oct 12, 2015 at 08:04:37AM -0700, Eric Rescorla wrote:
> On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara
> wrote:
> >
> > 1) It seems to me that if server key is compromised, MITM can
> > substitute 0-RTT data with its own (at least if original and modified
>
On Mon, Oct 12, 2015 at 10:47:58PM +0200, Simon Josefsson wrote:
>
> The following document adds new EdDSA key/signature OIDs directly:
>
> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04
The certificate example seems to contain OID 1.3.101.100.1... Is that
intended or should it be 1.3
On Tue, Oct 13, 2015 at 10:12:45AM +0100, Matt Caswell wrote:
>
> On 30/09/15 11:06, Matt Caswell wrote:
> > Hi all
> >
> > I have a question on how to interpret RFC 5246 with regards to the
> > interleaving of app data and handshake records.
>
> Hello,
>
> Does anyone have any views on the below?
As you might know, CFRG has been working on new curves (the document
has been sent to IRSG) and is working on signatures (main issues seem
to be selecting prehash for prehashed version of 448-bit signatures
and KDF for 448-bit signatures).
I have been thinking how to integrate this work into TLS.
On Thu, Oct 15, 2015 at 04:09:39PM +0300, Ilari Liusvaara wrote:
>
> Diffie-Hellman:
> ---
> There is already a WG draft about this. The one remaining technical
> issue seems to be wheither to share the curves with signatures or
> dedicate those for DH.
Okay, did
On Sat, Oct 17, 2015 at 07:25:46PM -0400, Sean Turner wrote:
> On Oct 17, 2015, at 08:30, Ilari Liusvaara wrote:
>
> > Okay, did a review of draft-ietf-tls-curve25519 (since it still
> > doesn't seem to have been WGLC'd):
>
> Note that draft-ietf-tls-curve25
On Mon, Oct 19, 2015 at 06:58:52PM +0300, Yoav Nir wrote:
> Hi
>
> I’ve submitted version -04 of this draft, incorporating the new curves
> Curve25519 and Curve448.
>
> I’m sorry to say that I have made the merge far too quickly and the result is
> quite sketchy, but I did beat the deadline.
>
From: Ilari Liusvaara
---
On Tue, Oct 20, 2015 at 10:42:14AM +0300, Yoav Nir wrote:
> Hi Ilari
>
> > - Is this document meant to also include the CFRG signatures
> > work? The interfaces to functions are already known.
>
> That is the intention. A PR is welcome.
Well
On Wed, Oct 21, 2015 at 09:11:51AM +0300, Yoav Nir wrote:
> LGTM. Can you push this to GitHub?
>
> > On 20 Oct 2015, at 8:35 PM, Ilari Liusvaara
> > wrote:
> >
> > From: Ilari Liusvaara
> >
> > ---
> > On Tue, Oct 20, 2015 at 10:42:14AM +0300
On Wed, Oct 21, 2015 at 11:17:10AM -0700, Eric Rescorla wrote:
> On Wed, Oct 21, 2015 at 11:13 AM, Short, Todd wrote:
>
> > I like the idea. If the functionality is to be merged, perhaps harmonizing
> > the names and contents of the messages (if possible)?
> >
>
> Yes. My plan is to name it Hell
On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote:
> Folks,
>
> At the Seattle interim, we decided to have a small ad hoc design team
> go and figure out how to harmonize the various forms of client
> authentication. I've posted a WIP version of the output of that work
> at:
>
>
On Thu, Oct 22, 2015 at 01:18:37PM -0500, Benjamin Kaduk wrote:
> On 10/22/2015 01:00 PM, Salz, Rich wrote:
> >> That is, the library update can be transparent to the end-user, who will
> >> continue to expect normal functionality and expect everything to work.
> > Should all applications suddenly
On Wed, Oct 21, 2015 at 10:32:59AM -0700, Eric Rescorla wrote:
>
> It seems natural to try to merge these mechanisms, but this raises
> the question of whether the handshake hashes should continue through
> the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104).
> The tension here
On Tue, Oct 27, 2015 at 08:49:35AM -0400, Eric Rescorla wrote:
> Thinking about this a little more:
>
> If we ever change the nonce construction to have an explicit nonce or
> otherwise
> not depend on the RSN (e.g., something like SIV) we're going to be sad if
> we don't have the RSN in the AD. O
On Sat, Oct 31, 2015 at 11:19:20AM +, Sam Scott wrote:
> Dear all,
>
> While revision 10 does not yet appear to permit certificate-based client
> authentication in PSK (and in particular resumption using PSK), we modelled
> what we believe is the intended functionality.
Eh, I thought that usi
On Sat, Oct 31, 2015 at 10:55:24PM +0900, Eric Rescorla wrote:
> Sam,
>
> Thanks for posting this. It's great to see people doing real formal
> analysis of the TLS 1.3 draft; this is really helpful in guiding the design.
>
> This result motivates and confirms the need to modify the handshake hashe
On Sun, Nov 01, 2015 at 04:36:43AM +0900, Eric Rescorla wrote:
>
> I've been planning to do a big rewrite of the security "analysis" sections
> and while I don't think it's worth having a real analysis in the protocol
> (the literature is going to do a much better job here than we can), this
> see
I forward-ported the merged RFC4492bis changes (with explicit numbers
added[1], in style of rsapss(4)) as PR #333.
This also includes the ECDH stuff, which IIRC was in RFC4492bis
before my PR.
I tried to align everything as close as possible (the only difference
should be PMS getting replaced by
On Wed, Nov 04, 2015 at 06:30:26AM -0500, Watson Ladd wrote:
> This draft needs to say that Curve25519 can only be used along with
> extended master secret. Alternatively we can completely remove the
> cofactor and reject zero keys.
X25519 and X448 specifications say zero keys MUST be rejected (an
On Wed, Nov 04, 2015 at 06:56:15AM -0500, Watson Ladd wrote:
> On Wed, Nov 4, 2015 at 6:34 AM, Ilari Liusvaara
> wrote:
> >
> > X25519 and X448 specifications say zero keys MUST be rejected (and
> > the functions are also internally specified to clear the cofactor).
>
I thought of following scenario:
Client: ClientHello+0RTT
Server: 0RTT rejected. Fallback to 1RTT.
Server: (Drains 0-RTT records)
Client: Finished (corrupted in transit)
Client: Appdata (request for something)
Server: (Drains corrupt finished as 0-RTT record)
Server: (Drains appdata as 0-RTT recor
On Sat, Nov 14, 2015 at 10:14:53AM -0800, Adam Langley wrote:
> The IESG conflicts review for
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ has now
> completed without issue[1].
>
> The editor's copy of the 1.3 spec contains code points for these
> curves[2], specifically:
>
>
On Tue, Nov 17, 2015 at 07:06:52PM +, Viktor Dukhovni wrote:
> On Tue, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote:
>
> > My proposal is that we:
> >
> > - List all the Standards Track cipher suites that are compatible with TLS
> > 1.3 in Appendix A.
> >
> > - Mark all the cipher su
On Mon, Nov 23, 2015 at 10:28:41AM -0800, Martin Thomson wrote:
> >From the issue:
>
> I don't want to see this change to a relative time. That will mess
> with our ability to create ServerConfiguration objects that live
> outside of the handshake.
>
> I have no real objection to expanding this
On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote:
> On 23 November 2015 at 12:56, Yoav Nir wrote:
> > It’s been suggested that as long as the CFRG signature curves
> > document is not finalized, we should wait with the eddsa_* ones.
> > I don’t believe so. Anything in any draft is su
On Mon, Nov 23, 2015 at 02:20:15PM -0800, Martin Thomson wrote:
> On 23 November 2015 at 14:08, Ilari Liusvaara
> wrote:
> > Also, the prehashes might not be the same for Ed25519ph and Ed448ph,
> > plus I consider interfaces that let one use this dangerous (IUF
> &
On Thu, Nov 26, 2015 at 09:52:37PM +0800, Xuelei Fan wrote:
> Hi,
>
> Per the latest draft of TLS 1.3, both "supported_groups" and "key_share"
> extensions are REQUIRED for DHE or ECDHE cipher suites (Section 8.2). Both
> extension need to provide the supported named groups in preference order.
>
On Thu, Nov 26, 2015 at 11:37:12PM +0800, Xuelei Fan wrote:
> > This wouldn't work if one had to downnegotiate TLS 1.2. That is going to
> > happen A LOT.
> >
> > I think, "supported_groups" extension still can be sent for TLS 1.2, but
> can be ignored for TLS 1.3. And "key_share" extension can be
On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote:
>
> Are we happy that we will only be needing the PureEdDSA variants and
> that no-one will be asking for the HashEdDSA versions? I ask because
> I've heard it suggested (I think Karthik mentioned this) that we might
> want to sign t
On Mon, Nov 30, 2015 at 06:07:19PM -0800, Bill Cox wrote:
> I don't think even I agree with this idea, but I'll put it out there anyway.
>
> We're seeing some new secure computing modes in ARM and Intel processors.
> Arm has TEE, and Intel has SGX. Both modes basically run at the same speed
> as
On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote:
>
> This clears out the big pipeline stall from PR#316, but probably has
> created some bustage. Expect a series of cleanup commits and some
> other things that were head-of-line blocked this week and then
> draft-11 in the next week o
On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote:
>
> 3. The server provides g^y in his ServerHello and then g^xy and g^xs
> are jointly used to produce the traffic keys and also to form a MAC over
> the handshake. As Hugo pointed out originally, this alone should
> be sufficient to a
On Wed, Dec 02, 2015 at 05:53:40PM +, Jacob Appelbaum wrote:
>
> I think that is false. One could easily use the "cleartext" SNI field
> and insert an encrypted value. A hash of the name would be a simple
> example but not a secure example, of course.
Furthermore, SNIs have name type, so even
On Wed, Dec 02, 2015 at 09:29:23AM -0800, Eric Rescorla wrote:
> On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara
> wrote:
>
> > On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote:
> > >
> > > 3. The server provides g^y in his ServerHello and then g^x
On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote:
> Hi,
>
> Any one know why the negotiated FFDHE draft hang on MISSREF state for more
> than 180 days?
>
> http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/
Normatively depends on the false-start draft that isn't sent
This came up while writing serializers/deserializers for various TLS
1.2 and 1.3 stuff... Didn't see issues/pull requests for any of
these...
1) ServerConfiguration has field early_data_type, which is of type
EarlyDataType. I don't see definition of that type anywhere. I
guess it was missed when t
When looking at stuff some more, I noticed that extension
status_request_v2, which is used by OCSP stapling and is not deprecated
[1].
Now, that extension uses additional handshake message type
(certificate_status), which is specified to go between Certificate
and SKE. Now, TLS 1.3 does not have S
On Sat, Dec 12, 2015 at 03:54:36PM +1100, Martin Thomson wrote:
> I think that the best way to deal with the status_request_v2 extension
> is to make it a proper part of the TLS 1.3 messages, probably
> Certificate or CertificateVerify. This is a fairly heavily important
> extension.
If one wants
On Mon, Dec 14, 2015 at 12:29:25PM +, Rob Stradling wrote:
> On 12/12/15 15:02, Salz, Rich wrote:
> >>I think that the best way to deal with the status_request_v2 extension is to
> >>make it a proper part of the TLS 1.3 messages, probably Certificate or
> >>CertificateVerify. This is a fairly
On Thu, Dec 17, 2015 at 02:14:18PM -0500, James Cloos wrote:
> Given the issues w/ gcm currently under discussion, and that poly1305
> was originally proposed to use w/ aes, should tls recommend aes-poly1305
> instead of aes-gcm for those who want to continue to use aes?
>
> Or does chacha-poly130
On Thu, Dec 24, 2015 at 08:08:25PM -0500, Eric Rescorla wrote:
> On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett
> wrote:
> >
> > This last bit stops this, yes. I would prefer the spec say this very
> > explicitly, as right now it doesn't and all I see is a line saying:
> > "If any of these checks f
On Mon, Dec 28, 2015 at 08:51:01PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> When too much plaintext has been encrypted with the same key, the
> key needs to be changed. When the key is changed, the change
> procedure should involve new randomness.
>
> What's the confusion here???
OTOH, you
On Mon, Dec 28, 2015 at 06:46:02AM -0500, Eric Rescorla wrote:
> On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema
> wrote:
>
> > For DTLS, we have to consider the packet injection threat. It is fairly
> > easy to send some random bytes with a fake source to a UDP destination.
> > Such attacks
On Mon, Dec 28, 2015 at 02:52:49PM -0500, Eric Rescorla wrote:
> Folks,
>
> In the spirit of making a useful checkpoint, I just posted the latest
> version of the
> editor's draft as draft-11. Here's the major changes:
>
>
> - Unify authentication modes. Add post-handshake client authentication.
On Mon, Dec 28, 2015 at 06:59:48PM -0500, Eric Rescorla wrote:
> On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara
> wrote:
> >
> > Also, on topic of DTLS 1.3... It occurs to me that naively doing it
> > would leave it open to "fragementation attacks" a'la I
On Tue, Dec 29, 2015 at 09:05:17AM -1000, Brian Smith wrote:
> On Tue, Dec 22, 2015 at 2:09 PM, Brian Smith wrote:
>
> > If an implementation only implements ECDHE cipher suites then
> > implementing the session hash extension is not necessary, according to RFC
> > 7627. I believe there are also
On Wed, Dec 30, 2015 at 11:52:07AM +0100, Kurt Roeckx wrote:
> On Tue, Dec 29, 2015 at 10:10:47PM +0200, Karthikeyan Bhargavan wrote:
> > As mentioned before, validating Curve25519 public values is necessary in
> > TLS 1.2 without session hash.
> > Otherwise, as we pointed out in [1], the triple h
On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote:
> On 30 December 2015 at 22:16, Ilari Liusvaara
> wrote:
> >> Would it make sense to have session hash as a requirement in TLS
> >> 1.2 when you want to use Curve25519?
> >
> > I don't think
On Wed, Dec 30, 2015 at 07:23:12PM -0500, Watson Ladd wrote:
> On Dec 30, 2015 7:08 PM, "Ilari Liusvaara" wrote:
> >
> > I also think I figured out a way to truly force contributory behaviour
> > without any checks:
> >
> > It is a bit nasty hack: Thro
On Thu, Dec 31, 2015 at 06:23:08AM +, Alyssa Rowan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2015-12-31 03:30, Adam Langley wrote:
>
> > I don't mind if the integration of curve25519 in TLS requires a
> > zero-check or not, but what property are people hoping to gain?
On Fri, Jan 01, 2016 at 06:22:00AM +1100, Martin Thomson wrote:
> On 31 December 2015 at 17:54, Ilari Liusvaara
> wrote:
> > Zero checks can already be unit-tested/interop-tested just as well.
>
>
> What ekr said applies, but also this:
I thought the ekr's poin
On Wed, Dec 30, 2015 at 09:16:12PM -0500, Watson Ladd wrote:
> On Wed, Dec 30, 2015 at 7:47 PM, Brian Smith wrote:
> > Watson Ladd wrote:
> >
> > Actually, because the check for non-zero result can/should/is in the
> > X25519/X448 functions themselves, the check for non-zero result is the least
>
On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote:
> On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara
> wrote:
>
> 2. Implementations which only do new algorithms can mandate EMS and not
> implement old derivation at all, provided we make that a rule here.
Wel
1 - 100 of 781 matches
Mail list logo
