Re: [TLS] Commentary on the client authentication presentation slides

On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara ilari.liusva...@elisanet.fi wrote: On Tue, Jul 28, 2015 at 6:28 PM David Benjamin david...@google.com wrote: Are you intending that this mechanism be enabled by default for HTTP/2 or would the prohibition against renego still apply

Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00

On Tue, Aug 4, 2015 at 12:20 PM Salz, Rich rs...@akamai.com wrote: Personally, I would rather see the nonce construction follow the form defined in the respective TLS version. [DB: Adding back in for context: That means including redundant bytes in TLS 1.2 and only getting the full

Re: [TLS] Commentary on the client authentication presentation slides

On Mon, Aug 10, 2015 at 3:05 PM Andrei Popov andrei.po...@microsoft.com wrote: Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. Correct, anything less than this will create deployment problems. But

Re: [TLS] Application data during renegotiation handshake

On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir wrote: > > > On 12 Nov 2015, at 3:32 AM, Adam Langley wrote: > > > > The TLS 1.3 post-handshake client-auth was intended, as I recall, to > > support HTTP/1.1 over TLS 1.3. > > No, it was (and is) presented

Re: [TLS] PR for anti-downgrade mechanism

On Mon, Oct 19, 2015 at 11:10 AM Eric Rescorla wrote: > On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote: > >> Does the sentinel have to be the first N bytes? >> >> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time >> value and 28 random

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On Wed, Oct 14, 2015 at 4:05 PM Matt Caswell wrote: > On 14/10/15 16:44, Martin Rex wrote: > > Matt Caswell wrote: > >> > >> Does anyone have any views on the below? > > > > Yup. Interleaving application & handshake records is a > > highly dangerous idea (and fortunately some

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On Wed, Oct 14, 2015 at 4:42 PM Martin Thomson <martin.thom...@gmail.com> wrote: > On 14 October 2015 at 13:29, David Benjamin <david...@chromium.org> wrote: > > If you really absolutely must support interleave and can't avoid it, I > think > > it being allowed

Re: [TLS] Version in record MAC

What purpose does putting the version in the AD serve? It's not harmful, sure, but just using the sequence number is simplest. It seems the only reason we'd consider putting it into the AD is because historically the record version was in there as part of the record header. In a vacuum, I'm having

Re: [TLS] Should we require implementations to send alerts?

(Resending from the right address, again. Possibly I should have subscribed with the other one...) On Thu, Sep 17, 2015 at 6:23 PM David Benjamin <david...@google.com> wrote: > On Thu, Sep 17, 2015 at 5:46 PM Brian Smith <br...@briansmith.org> wrote: > >> On Thu, Sep 1

Re: [TLS] Fresh results

On Fri, Dec 4, 2015 at 1:17 PM Hubert Kario wrote: > On Friday 04 December 2015 00:52:08 Hanno Böck wrote: > > * Fully deprecate RSA key exchange. > > The compatibility costs of this one are high. They are even higher > > considering the fact that chrome wants to deprecate dhe

Re: [TLS] chacha/poly interop?

BoringSSL has an implementation of the AEAD itself you could test against. It's the EVP_AEAD named EVP_aead_chacha20_poly1305_rfc7539 (to be renamed to EVP_aead_chacha20_poly1305 later). On Wed, Dec 9, 2015 at 8:02 PM Salz, Rich wrote: > OpenSSL just landed our chacha/poly

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and it's likely that enterprise deployments are much worse. I started gathering numbers on ServerKeyExchange hashes back in November. The code isn't on

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 12:27 PM Peter Bowen wrote: > The gaps seem to be: > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated > (BoringSSL has an implementation using cipher suite 0xca,0xfe) > 0xca,0xfe has since been removed as nothing was using it. I'm not

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir wrote: > > > On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote: > > > > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: > >> I’m not sure this helps. > >> > >> I’ve never installed a server that is version intolerant.

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

I think I could be convinced in either direction right now. It is definitely ugly and more of a nuisance to implement. The alternative is a fallback and then painfully driving it out later. We've done that before and we have FALLBACK_SCSV and the server_random trick now. At the same time, I am

Re: [TLS] PR #493: Multiple concurrent tickets

I'm not sure I follow why the additional "generation" machinery is necessary. What do we gain from having the server to tell us to discard a ticket beyond what the ticket lifetime already gives? This doesn't seem an effective way to discard key material since, unlike the ticket lifetime, we need

Re: [TLS] Downgrade protection, fallbacks, and server time

On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario <hka...@redhat.com> wrote: > On Wednesday 01 June 2016 22:29:06 David Benjamin wrote: > > In case folks hoped we could bump the ClientHello version without > > those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

On Thu, Jun 2, 2016 at 11:07 AM David Benjamin <david...@chromium.org> wrote: > On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario <hka...@redhat.com> wrote: > >> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: >> > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannop

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote: > On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos > > > wrote:> > > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > > >> 2% is actually

Re: [TLS] Downgrade protection, fallbacks, and server time

On Thu, Jun 2, 2016 at 11:20 AM Hubert Kario wrote: > > > Speaking of version number, does the text say that a server _MUST_ > > > accept any version higher than the one that is specified in the RFC, > > > but reply with 0x03,0x04 in case it doesn't support any future > > >

[TLS] Downgrade protection, fallbacks, and server time

In case folks hoped we could bump the ClientHello version without those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much exists. (Maybe we should just give up on ClientHello.version and use an extension? Extensions have rusted less.) I picked a large list of top sites and

Re: [TLS] Downgrade protection, fallbacks, and server time

in RSA for a long while.) David > > On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin <david...@chromium.org> > wrote: > >> In case folks hoped we could bump the ClientHello version without those >> dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very m

Re: [TLS] Simpler backward compatibility rules for 0-RTT

On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote: > > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson < > martin.thom...@gmail.com> > > wrote: > > > > &

Re: [TLS] Remove EncryptedExtensions from 0-RTT

On Thu, Jun 23, 2016 at 6:35 AM David Benjamin <david...@chromium.org> wrote: > On Thu, Jun 23, 2016 at 6:35 AM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote: >> > When implementing 0-

Re: [TLS] chacha/poly for http/2

Chrome is also expecting to ship the cipher in Chrome 49. It's available in Canary and Dev channel right now. It should interop with OpenSSL's master branch as of when I last tested this. David On Wed, Jan 13, 2016 at 12:48 PM Salz, Rich wrote: > We (OpenSSL) have already

[TLS] Simplifying signature algorithm negotiation

Hi folks, This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS 1.2, signature algorithms are spread across the handshake. We have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in independent registries. NamedGroup is sent in one list, also used for

Re: [TLS] Simplifying signature algorithm negotiation

On Fri, Jan 15, 2016 at 7:08 PM Brian Smith <br...@briansmith.org> wrote: > David Benjamin <david...@chromium.org> wrote: > >> 4. Deprecate ecdsa_sha256, etc., in favor of new >> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_* >>

Re: [TLS] Simplifying signature algorithm negotiation

On Fri, Jan 15, 2016 at 8:10 PM David Benjamin <david...@chromium.org> wrote: > If changing the existing meaning is a nuisance, another option is to > continue to allocate new values but only define ecdsa_p256_sha256, > ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

On Mon, Jan 11, 2016 at 6:17 PM David Benjamin <david...@chromium.org> wrote: > In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing > around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and > it's likely that enterprise deployments are mu

Re: [TLS] 0-RTT, server Application Data, and client Finished

On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrote: > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson < > martin.thom...@gmail.com> > > wrote: > > >

Re: [TLS] 0-RTT, server Application Data, and client Finished

On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <martin.thom...@gmail.com> wrote: > On 27 January 2016 at 14:11, David Benjamin <david...@chromium.org> wrote: > > Why do you say it's an optimization? They're exactly the same except the > > simplified one reduces t

Re: [TLS] 0-RTT, server Application Data, and client Finished

On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Thu, Jan 28, 2016 at 05:36:22PM +0000, David Benjamin wrote: > > On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > >

Re: [TLS] Simplifying signature algorithm negotiation

On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <e...@rtfm.com> wrote: > On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <david...@chromium.org> > wrote: > >> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <davemgarr...@gmail.com> >> wrote: >> >

Re: [TLS] Simplifying signature algorithm negotiation

On Fri, Jan 15, 2016 at 10:13 PM Brian Smith <br...@briansmith.org> wrote: > David Benjamin <david...@chromium.org> wrote: > >> (Whether such certificates exist on the web is probably answerable via CT >> logs, but I haven't checked.) >> > > Me neither, a

Re: [TLS] Simplifying signature algorithm negotiation

Sorry, sent from the wrong address. On Tue, Jan 19, 2016 at 5:19 PM David Benjamin <david...@google.com> wrote: > On Sat, Jan 16, 2016 at 5:00 AM Hanno Böck <ha...@hboeck.de> wrote: > >> Hi, >> >> I generally like the idea of simplifying the diffe

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

BoringSSL has a pair of implementations ready (in C and in our fork of Go's TLS stack for testing). We're using the value in the TLS 1.3 draft, so 29. It's not currently enabled in any Chrome builds, but I'm expecting to change this soon. David On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey

Re: [TLS] Simplifying signature algorithm negotiation

can be used for signing but also what curves can get signed. > > Or are you saying that the NamedGroup would stay, and would now specify > only the supported parameters for the key exchange, not how they are > authenticated (as it is now)? > Yes. > On Friday 15 January 2016 20:45

Re: [TLS] Simplifying signature algorithm negotiation

PM David Benjamin <david...@chromium.org> wrote: > Hi folks, > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > 1.2, signature algorithms are spread across the handshake. We have > SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm,

Re: [TLS] Simplifying signature algorithm negotiation

algorithms. The other benefits from incorporating curve preferences into the negotiation also still apply. David On Fri, Jan 22, 2016 at 5:25 PM David Benjamin <david...@chromium.org> wrote: > I've put together a pull request with some initial text for this proposal > if folks dec

[TLS] 0-RTT, server Application Data, and client Finished

It's possible I'm reading the draft wrong, so this thread may be a very short one. (t here is in units of RTT, so t=0 is when the client sends ClientHello and t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is when the client receives ServerHello, etc.) Looking at the

Re: [TLS] Backwards-compatibility of 0-RTT data

On Tue, Jan 26, 2016 at 9:11 PM Eric Rescorla <e...@rtfm.com> wrote: > On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin <david...@chromium.org> > wrote: > >> Instead of putting 0-RTT data in a ClientHello extension, the current >> draft has the client send extra r

Re: [TLS] Simplifying signature algorithm negotiation

On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario <hka...@redhat.com> wrote: > On Friday 15 January 2016 20:45:34 David Benjamin wrote: > > Hi folks, > > > > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In > > TLS 1.2, signature algorithms ar

Re: [TLS] Simplifying signature algorithm negotiation

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 <david...@chromium.org> > wrote: > >> On Fr

Re: [TLS] Tickets and cross protocol attacks

It's probably better to reject this fallback when the client has chosen to > explicitly use a TLS 1.3 feature with 0-RTT in general. > > Subodh > ________ > From: Martin Thomson [martin.thom...@gmail.com] > Sent: Tuesday, March 29, 2016 6:29 PM &

Re: [TLS] Tickets and cross protocol attacks

On Tue, Mar 29, 2016 at 12:57 PM Subodh Iyengar wrote: > Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown that > attacks on previous version of TLS can be used to attack new version of > TLS. > > One thing that is not mandated by TLS 1.3 is separation of

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

If the WG agrees with this change, I've put together a PR here: https://github.com/tlswg/tls13-spec/pull/462 On Tue, May 17, 2016 at 4:14 PM David Benjamin <david...@chromium.org> wrote: > Reviving this thread, I also think it would also be a good idea if 1.3 did > not stripping

[TLS] In-handshake CertificateRequest and 0-RTT

The 0-RTT handshake originally had two places with a client Certificate + CertificateVerify: in the 0-RTT flow and in the second Finished block in response to a server CertificateRequest. We've dropped the first now. I propose we drop the second too. Client auth with 0-RTT is solely carried over

Re: [TLS] In-handshake CertificateRequest and 0-RTT

h. (This would just be for re-asserting the private key and not switching certificates, right?) > On 12 May 2016 at 06:44, David Benjamin <david...@chromium.org> wrote: > > The 0-RTT handshake originally had two places with a client Certificate + > > CertificateVerify: in the

Re: [TLS] In-handshake CertificateRequest and 0-RTT

resume, it's just not clear to > me why you wouldn't > allow in-handshake client-auth. I'm not sure it's a hill I'm willing to > die on though. > > -Ekr > > > > On Thu, May 12, 2016 at 9:06 PM, David Benjamin <david...@chromium.org> > wrote: > >> Which PS

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

Reviving this thread, I also think it would also be a good idea if 1.3 did not stripping zeros from Z. Having this logic is rather dubious w.r.t. treating secret data in constant-time. And as Bill Cox mentioned elsewhere in this thread, this odd behavior has caused interoperability issues in the

Re: [TLS] PR#449

This change has a non-obvious consequence for server implementation complexity. I don't have an especially good alternate proposal though. Putting ticket_age in EncryptedExtensions means there are two ways a server may reject 0-RTT. It might reject ClientHello because the ticket is invalid (or if

Re: [TLS] Keeping TLS extension points working

On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > On Mon, Jul 25, 2016 at 10:32:29PM +0000, David Benjamin wrote: > > > I'm not sure how this process usually works, but I would like to reserve > a > > bunch of values in the TLS regis

Re: [TLS] Keeping TLS extension points working

On Mon, Jul 25, 2016 at 6:32 PM David Benjamin <david...@chromium.org> wrote: > Hi folks, > > I'm not sure how this process usually works, but I would like to reserve a > bunch of values in the TLS registries to as part of an idea to keep our > extension points working. H

Re: [TLS] Server-side missing_extension MUSTs

On Wed, Jul 13, 2016 at 11:06 AM Hubert Kario <hka...@redhat.com> wrote: > On Wednesday 13 July 2016 14:43:58 David Benjamin wrote: > > To be clear, I am not at all opposed to useful errors or strict policing > of > > what the peer sends. That's all great. Indeed the

Re: [TLS] Keeping TLS extension points working

On Tue, Jul 26, 2016 at 6:56 AM Hubert Kario <hka...@redhat.com> wrote: > On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote: > > I would like to fix this by reserving a few values in our registries so > > that clients may advertise random ones and regularly exercis

Re: [TLS] Keeping TLS extension points working

技术有限公司 Huawei Technologies Co., Ltd. >> [image: Company_logo] >> >> Phone: >> Fax: >> Mobile: >> Email: >> Huawei Technologies Co., Ltd. >> Bangalore, India >> >> http://www.huawei.com >> -- >> &g

Re: [TLS] Keeping TLS extension points working

limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > *From:* David Benj

[TLS] Server-side missing_extension MUSTs

Hey folks, I would like to remove the missing_extension MUSTs on the server side. Full justification in the PR. https://github.com/tlswg/tls13-spec/pull/544 On the client, it is perfectly feasible to mandate a particular alert value. The check is very straight-forward. On the server, however,

Re: [TLS] Thoughts on Version Intolerance

t of compatibility by > >> using extension based mechanism to indicate TLSv1.3, > > Just quick: This was discussed yesterday, David Benjamin had an > > interesting proposal, but it was largely met with resistance. So from > > I had some follow-up discussion wi

Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2

On Tue, Jul 12, 2016 at 1:47 PM David Benjamin <david...@chromium.org> wrote: > [Changing subject since the other thread is about something else.] > > On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> > ### Signatu

[TLS] TLS 1.3 signature algorithms in TLS 1.2

[Changing subject since the other thread is about something else.] On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara wrote: > > ### Signature Algorithms > > > > * In TLS 1.2, the extension contained hash/signature pairs. The pairs are > > encoded in two octets, so

Re: [TLS] Server-side missing_extension MUSTs

entHello to get > reliable 1RTT (with the exception of HRR). On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario <hka...@redhat.com> wrote: > On Wednesday 13 July 2016 05:23:53 David Benjamin wrote: > > I don't believe an implementation which fails to send supported_groups,

Re: [TLS] Server-side missing_extension MUSTs

code passes #1 (the special-case is not useful and such a peer would not be able to handshake against correct implementations anyway), so I'm not willing to sacrifice #2 for it. On Wed, Jul 13, 2016 at 10:02 AM David Benjamin <david...@chromium.org> wrote: > On Wed, Jul 13, 2016 at 3:3

Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2

On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Tue, Jul 12, 2016 at 05:47:26PM +0000, David Benjamin wrote: > > [Changing subject since the other thread is about something else.] > > > > I believe, as the text stands righ

Re: [TLS] draft-rescorla-tls-subcerts

On Thu, Jul 7, 2016 at 7:29 PM Watson Ladd wrote: > I don't think we can use name constraints here. Yes, they are opt-in > and clients can indicate support, but it may well be that a TLS > implementation doesn't know if its X509 validation code will support > them as it

Re: [TLS] judging consensus on keys used in handshake and data messages

On Wed, Jul 6, 2016 at 2:11 PM Yoav Nir wrote: > Hi, Joe > > > On 6 Jul 2016, at 8:39 PM, Joseph Salowey wrote: > > > > We are the unenviable position of calling consensus between three > choices [0]: > > > > - Option 1 - use the same key for both

Re: [TLS] judging consensus on keys used in handshake and data messages

On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <e...@rtfm.com> wrote: > On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarr...@gmail.com> > wrote: > >> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: >> > I'm also curious which post-hands

Re: [TLS] Reminders

OpenSSL determines which certificate to use during ClientHello processing, but it has a mode where, if intermediates were not explicitly configured and only a leaf, it path-builds right before sending the Certificate message. But I don't see any reason why it can't be changed to compute this

Re: [TLS] Downgrade protection, fallbacks, and server time

On Wed, Jun 1, 2016 at 6:57 PM Eric Rescorla <e...@rtfm.com> wrote: > On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin <david...@chromium.org> > wrote: > >> On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla <e...@rtfm.com> wrote: >> >>> 2% is actually p

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

I think this is much clearer, except for one bullet point below: On Thu, Feb 2, 2017 at 10:22 AM Russ Housley wrote: > [...] > - If PSK and (EC)DH are being used together, then the server will: > > -- sends a "pre_shared_key" extension to indicate the selected >

Re: [TLS] Question about unrecognized extension types in the TLS 1.3 client hello message

On Mon, Jan 30, 2017 at 4:45 PM Adam Langley wrote: On Mon, Jan 30, 2017 at 1:41 PM, Scott Fluhrer (sfluhrer) wrote: > My question: in TLS 1.3, if the client inserts an extension of a type that > the server does not recognize, how must the server

[TLS] ecdh_ prefix in draft-ietf-tls-rfc4492bis-12

This is a minor comment and purely aesthetic thing. Apologies for the lateness in noticing. Hopefully it's not too late: In TLS 1.3, we dropped the "ecdh_" prefix on ecdh_x25519 and ecdh_x448 when we split signatures from NamedCurve/Group. The documents should probably match in naming one way or

Re: [TLS] stapling OCSP/CT for client cert?

Looks like TLS 1.3 already allows this for CT, though not OCSP. Would take all of four characters to fix. See this table: https://tlswg.github.io/tls13-spec/#rfc.section.4.2 One of the nice things about using TLS-style extensions in CertificateRequest is any ClientHello => (Server)Certificate

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

NewSessionTicket always includes in-handshake client auth. The resumption secret can't even be derived without it. On Tue, Feb 14, 2017 at 10:21 AM David Wong wrote: > I can see this problem even in the case where the client sends an empty > Certificate message

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

On Wed, Feb 15, 2017 at 2:49 PM David Wong wrote: > On Feb 15 2017, at 7:27 pm, Andrei Popov > wrote: > > Yes, I agree that it is useful to mention this in the spec. > > > > > It would be nice is to have two different PRs solving this

Re: [TLS] adopted: draft-davidben-tls-grease

Done. Let me know if I did any of that incorrectly. (Sorry about the delay. I've been some combination of suffering from a cold, on vacation, or at conferences for the past month---usually more than one at a time!) On Tue, Jan 3, 2017 at 8:59 AM Sean Turner wrote: I appears

Re: [TLS] GREASE and TLS 1.3

On Wed, Jan 18, 2017 at 8:15 PM Martin Thomson wrote: On 19 January 2017 at 14:04, Kazu Yamamoto wrote: > Should we also add grease values for key_share? supported_groups code points should cover that, but if you are asking if we should spend bytes on

[TLS] GREASE and TLS 1.3

So, having uploaded draft-ietf-tls-grease-00, I would now like to rewrite large chunks of it. The draft is currently defined for TLS 1.2, but it probably makes sense to order it after TLS 1.3. TLS 1.3 also adds a many new extension points, and we can expect new TLS 1.3 implementations popping up

Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

On Fri, Aug 19, 2016 at 2:35 PM Geoffrey Keating wrote: > Peter Gutmann writes: > > > The problem is that 7919 doesn't say "I want to do DHE, if possible > > with these parameters", it says "I will only accept DHE if you use > > these parameters,

Re: [TLS] KeyUpdate and unbounded write obligations

On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk <bka...@akamai.com> wrote: > On 08/17/2016 11:29 PM, David Benjamin wrote: > > However, we lose the "free" (really at the cost of this unboundedness > problem) generation-based bidirectional KeyUpdate sync. Dep

Re: [TLS] Keeping TLS extension points working

ServerHello. The first message may even not be ServerHello and instead HelloRetryRequest. David On Wed, Jul 27, 2016 at 4:02 PM Sean Turner <s...@sn3rd.com> wrote: > > > On Jul 26, 2016, at 11:11, David Benjamin <david...@chromium.org> wrote: > > > > 1) “Updates: 5246

Re: [TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions

Huh. I agree that text is weird. We should probably remove it. I think we actually get something akin to what you suggest basically implicitly: Servers aren't allowed to send unsolicited extensions, so your SH and EE parsers should be rejecting any unknown extensions. If you combine that with not

Re: [TLS] draft-davidben-tls-grease-01

On Mon, Sep 5, 2016 at 10:59 AM Hubert Kario <hka...@redhat.com> wrote: > On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote: > > On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario <hka...@redhat.com> wrote: > > > On Friday, 2 September 2016 18:53:45 CEST Davi

Re: [TLS] draft-davidben-tls-grease-01

On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario <hka...@redhat.com> wrote: > On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote: > > I've finally gotten to uploading > > https://tools.ietf.org/html/draft-davidben-tls-grease-01 which hopefully > > resolves th

Re: [TLS] CertficateRequest extension encoding

On Mon, Sep 5, 2016 at 5:46 PM Andrei Popov wrote: > Ø A CertificateExtension is a hint to the client about what kind of > certificates are acceptable. We have a registry of u16s for them. Clients > ignore extensions they don't understand, so it is ultimately on the

Re: [TLS] Finished stuffing

I think this is a good idea. It's kind of weird, but it avoids giving the early Finished such a strange relationship with the handshake transcript. Also a fan of doing away with multiple PSK identities if we don't need it. As a bonus, this removes the need to route a "phase" parameter into the

Re: [TLS] KeyUpdate and unbounded write obligations

On Thu, Sep 1, 2016 at 5:29 PM Ilari Liusvaara wrote: > On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote: > > On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > I tried to implement this, and discovered an

Re: [TLS] 0-RTT encrypted data limits

On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla wrote: > On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara > wrote: > >> On Thu, Sep 01, 2016 at 05:48:02AM -0700, Eric Rescorla wrote: >> > On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario

Re: [TLS] CertficateRequest extension encoding

I have no involvement in systems that would want this (our implementation just ignores it), but it seems a TLS-style registry would be better than using OIDs anyway. Concretely: A CertificateExtension is a hint to the client about what kind of certificates are acceptable. We have a registry of

Re: [TLS] CertficateRequest extension encoding

Apologies, I hit 'Send' too early. Finished a sentence below: On Sun, Sep 4, 2016 at 1:41 PM David Benjamin <david...@chromium.org> wrote: > I have no involvement in systems that would want this (our implementation > just ignores it), but it seems a TLS-style registry would be

Re: [TLS] Finished stuffing

> Antoine > > > Le 2016-09-07 05:49, Joseph Salowey a écrit : > > Hi Folks, > > The chairs want to make sure this gets some proper review. Please > respond with comments by Friday so we can make some progress on this > issue. > > Thanks, > > J > > O

Re: [TLS] 0-RTT encrypted data limits

On Thu, Sep 1, 2016 at 11:25 AM Eric Rescorla <e...@rtfm.com> wrote: > On Thu, Sep 1, 2016 at 8:22 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> On Thu, Sep 01, 2016 at 02:29:00PM +, David Benjamin wrote: >> > On Thu, Sep 1, 2016 at 10:01 AM

[TLS] Version negotiation, take two

Hi folks, I’d like to revisit the question of version negotiation. EKR wrote up some text for moving version negotiation to an extension: https://github.com/tlswg/tls13-spec/pull/632 I would like us to adopt this proposal. In Berlin, this really got framed as a pragmatic question: the current

Re: [TLS] Version negotiation, take two

On Wed, Sep 14, 2016 at 11:46 AM Benjamin Kaduk wrote: > On 09/14/2016 04:56 AM, Hubert Kario wrote: > > First, I don't think that the argument that the current version scheme doesn't > lend itself to future-proofing is correct. Just as with GREASE, browsers can > send much

Re: [TLS] chacha/poly interop?

On Mon, Sep 12, 2016 at 7:35 PM Jeffrey Walton wrote: > On Wed, Dec 9, 2015 at 8:02 PM, Salz, Rich wrote: > > OpenSSL just landed our chacha/poly implementation into master. We pass > the > > RFC test vectors, looking for other implementations to test

Re: [TLS] CertficateRequest extension encoding

context<1..2^8-1>; CertificateRequestExtension certificate_extensions<0..2^16-1>; } CertificateRequest; Nick On Thu, Sep 22, 2016 at 6:26 PM David Benjamin <david...@chromium.org> wrote: On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov <andrei.po...@microsoft.com> wrote:

Re: [TLS] BoringSSL's TLS test suite

On Sun, Sep 25, 2016 at 5:49 PM Adam Langley wrote: > On Sun, Sep 25, 2016 at 2:35 PM, Henrick Hellström > wrote: > > Then again, the ASN.1 module in > https://datatracker.ietf.org/doc/rfc5280/ > > says differently. Strictly speaking, RFC 3279 does

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

We were also expecting to want to bound how much traffic a server could be compelled to skip over without making progress. It actually didn't occur to me we could let the client know the bounds, rather than just making up a conservative bound (there's only so much data you can get into an RTT) and

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara wrote: On Sat, Oct 08, 2016 at 01:03:21AM +, Nick Sullivan wrote: > There has been a lot of discussion lately about post-handshake messages > that do not contain application data and how to handle them. This PR is an >

Re: [TLS] Application layer interactions and API guidance

To add to that, in out-of-order transports, whether a message was sent over 0-RTT or not may not even be very well-defined. If QUIC originally sent data over 0-RTT but had to retransmit it after the full connection parameters are available, I believe it will use those. Even in an in-order

  1   2   3   4   5   >