Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

Hi Roman, Thank you for the good suggestions. Comments addressed here https://github.com/tlswg/tls-subcerts/pull/108 Best, Nick On Tue, May 31, 2022 at 5:49 PM Roman Danyliw via Datatracker < nore...@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for >

Re: [TLS] Francesca Palombini's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

Francesca and Christian, Thank you for the review. Answers inline below and changes in Github ( https://github.com/tlswg/tls-subcerts/pull/108/files). Best, Nick On Tue, May 31, 2022 at 11:49 AM Francesca Palombini via Datatracker < nore...@ietf.org> wrote: > Francesca Palombini has entered

Re: [TLS] Lars Eggert's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

Hi Lars, Comments addressed inline and changes to the document are in Github ( https://github.com/tlswg/tls-subcerts/pull/108/files). Best, Nick On Wed, May 25, 2022 at 5:20 AM Lars Eggert via Datatracker < nore...@ietf.org> wrote: > Lars Eggert has entered the following ballot position for >

Re: [TLS] [Last-Call] Genart last call review of draft-ietf-tls-subcerts-12

Thanks Elwyn, I've updated the document in Github to address your nits ( https://github.com/tlswg/tls-subcerts/pull/108/files). Best, Nick On Wed, May 25, 2022 at 5:20 AM Lars Eggert wrote: > Elwyn, thank you for your review. I have entered a No Objection ballot for > this document. > > Lars

Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

Hi Éric, Thank you for your review. Responses inline and edits in Github ( https://github.com/tlswg/tls-subcerts/pull/108/files). > -- > COMMENT: > -- > > #

Re: [TLS] (bonus) AD review draft-ietf-tls-subcerts

Thanks, Paul. -13 is Submitted. Nick On Wed, May 11, 2022 at 9:22 PM Paul Wouters wrote: > > On Wed, May 11, 2022 at 1:08 PM Nick Sullivan wrote: > >> Hi Paul, >> >> Thank you for the review. I've put up a PR to address your points: >> >> https://git

Re: [TLS] (bonus) AD review draft-ietf-tls-subcerts

Hi Paul, Thank you for the review. I've put up a PR to address your points: https://github.com/tlswg/tls-subcerts/compare/nick/wouters-review-may22?expand=1 Comments inline. On Mon, May 9, 2022 at 9:03 PM Paul Wouters wrote: > > As this document already saw an AD review by Ben Kaduk, I will

Re: [TLS] [response[ AD review of draft-ietf-tls-subcerts-11

FYI, I've put my proposed changes up as a PR: https://github.com/tlswg/tls-subcerts/pull/98 Nick On Tue, Mar 1, 2022 at 10:22 AM Nick Sullivan wrote: > TLSWG, > > Benjamin Kaduk sent a review to the list of draft 11 of Delegated > Credentials. Somehow I didn't get the email, so I

[TLS] [response[ AD review of draft-ietf-tls-subcerts-11

TLSWG, Benjamin Kaduk sent a review to the list of draft 11 of Delegated Credentials. Somehow I didn't get the email, so I'm restating his points here with responses. Ben, thanks for the thorough review. If there's consensus around my proposed responses to the changes, I'll put together an

Re: [TLS] [Uta] OCSP in RFC7525bis

For additional context, here's s research study we published a few years back on OCSP must-staple in the Web context: https://cbw.sh/static/pdf/chung-imc18.pdf Nick On Wed, Jan 19, 2022 at 11:58 AM Mohit Sahni wrote: > Hi, > > So for the new BCP, we have three options: > > > > Add a

Re: [TLS] [re-send] draft-ietf-tls-exported-authenticator IESG review

The text in the PR has been updated to incorporate Sean and Rich's suggestions. If there are no more comments I'll merge and close at the end of the week. Nick On Fri, Oct 22, 2021 at 10:05 AM Salz, Rich wrote: > Made an editorial suggestion at >

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-11.txt

; This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Delegated Credentials for TLS > Authors : Richard Barnes > Subodh Iyengar > Nick Sullivan >

[TLS] [re-send] draft-ietf-tls-exported-authenticator IESG review

Hello TLSWG and IESG reviewers, This is a compendium of responses to the various reviews of the document. There are a few remaining open questions to address that I hope we can resolve in this thread. I’ve compiled the changes to the document in response to the comments in Github:

[TLS] draft-ietf-tls-exported-authenticator IESG review

Hello TLSWG and IESG reviewers, This is a compendium of responses to the various reviews of the document. There are a few remaining open questions to address that I hope we can resolve in this thread. I’ve compiled the changes to the document in response to the comments in Github:

Re: [TLS] Solving HRR woes in ECH

Hi Chris, HRR in ECH does seem challenging. This may be tangential to the PR you linked, but there may be a way to reduce the likelihood of HRR by moving even more of the handshake negotiation into DNS. The HTTPS RR is already used for some types of negotiation (ALPN and ECH key), so why can't it

Re: [TLS] comments on draft-subcerts

For some reason, I misinterpreted this request as putting a representation of the TLS extension into the document. An ASN.1 representation of the OID in the certificate is forthcoming. Nick On Thu, Aug 20, 2020 at 9:04 AM Salz, Rich wrote: > > >- There are many RFCs that use the PEM

Re: [TLS] comments on draft-subcerts

Thank you Russ and Rich for your comments, I've attempted to address the comments here: https://github.com/tlswg/tls-subcerts/pull/80, save for the one about the example extension. Russ, which format do you think would be most useful for the extension? I'm having a hard time finding another

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

Daniel, Thank you for your thorough review. We've attempted to address these comments in the latest version on Github and are preparing to submit a -10. Answers inline below for these comments. Hannes, thank you for your comment as well. The changes are tracked here:

Re: [TLS] comments on draft-subcerts

Thank you for the review, Sofía. I'm looking forward to the PR. Once that lands we'll submit a version of the doc with WGLC#2 comments incorporated. Nick On Thu, Aug 13, 2020 at 12:35 AM Sofía Celi wrote: > Dear, list, > > Sorry for sending this past the last call. > > Few comments on the

Re: [TLS] Possible blocking of Encrypted SNI extension in China

It's important to note that the Firefox Nightly client does not implement GREASE of any form, so only the connections to sites that are known to support the ESNI could be blocked by this method. These connections stick out like a sore thumb among connections from this browser since ESNI is

Re: [TLS] Closing WGLC (was Re: 3rd WGLC for draft-ietf-tls-exported-authenticators)

TLSWG and Chairs, I've submitted draft -13 with the appropriate changes. Best, Nick On Tue, Jun 16, 2020 at 10:23 AM Sean Turner wrote: > Hi! > > This message closes out the 3rd WGLC for > draft-ietf-tls-exported-authenticators. I have created GH issues for the > two issues raised during

[TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-09.txt

To: Richard Barnes , Subodh Iyengar , Eric Rescorla , Nick Sullivan A new version of I-D, draft-ietf-tls-subcerts-09.txt has been successfully submitted by Nick Sullivan and posted to the IETF repository. Name: draft-ietf-tls-subcerts Revision: 09 Title: Delegated Credentials

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

Thanks Russ, I filed an issue to address it. On Wed, Jun 3, 2020 at 1:27 PM Russ Housley wrote: > Nick: > > There is something wrong with the formatting of the numbered list in > Section 4.1.3. > > Russ > > On Jun 3, 2020, at 4:20 PM, Nick Sullivan < > nick=4

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

Hello TLSWG, We made a -08 version of this draft before the WGLC that incorporated some of the comments on-list for -07, but didn't notice until now that the submission didn't go through and therefore wasn't available for this RGLC. I apologize for this oversight. This submission just went

Re: [TLS] Encoding of delegated credential distribution

Hi Paul, Thank you for your comment. I would consider the distribution of key material out of scope for this protocol. Since this is can be an asynchronous distribution channel between mutually trusting parties, implementations may vary. As mentioned below, ACME may be suitable here, but I don't

Re: [TLS] Review of draft-ietf-tls-subcerts-07

Hi Jonathan, A (delayed) thank you for this helpful review. Your input will be incorporated into draft -08. Nick On Thu, Apr 2, 2020 at 6:31 PM Jonathan Hammell wrote: > The draft looks good. I have a few minor nits and suggestions. > > Section 3, Fourth bullet: s/TLS hadshake/TLS handshake

Re: [TLS] Dropping "do not stick out" from ECHO

Replies inline again. On Mon, Mar 23, 2020 at 8:40 AM Christopher Wood wrote: > Trying to reply succinctly inline below! > > On Mon, Mar 23, 2020, at 3:54 AM, Nick Sullivan wrote: > > I have reservations. > > > > On Sun, Mar 22, 2020 at 9:54 AM Christoph

Re: [TLS] Dropping "do not stick out" from ECHO

I have reservations. On Sun, Mar 22, 2020 at 9:54 AM Christopher Wood wrote: > One of the original motivating requirements for ECHO (then ENSI) was "do > not stick > out" [1]. This complicates the current ECHO design, as clients must > trial decrypt > the first encrypted handshake message to

Re: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack

Thank you again for the detailed explanation. > We agree with your preference for option 1. > Would it help if I contribute a draft of the new text for the security > considerations section? > > best wishes, > Nimrod > > > On Fri, 20 Mar 2020 at 18:57, Nick Sullivan wr

Re: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack

; Robert, Juraj and Nimrod > > ------ Forwarded message - > From: Nick Sullivan > Date: Fri, 20 Mar 2020 at 01:21 > Subject: Re: [TLS] Delegated Credentials: The impact of a hypothetical > Bleichenbacher attack > To: Nimrod Aviram > Cc: , Juraj Somorovsky <

Re: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack

Hello Nimrod, Robert and Juraj, Thank you for the report! The fact that a single signature oracle computation can be used to create a DC and therefore intercept multiple connections for up to 7 days is something we considered when writing this specification. The mitigation you proposed in option

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

Good catches on the section number and server/client questions. Confirming below. Here's a PR with the proposed change: https://github.com/tlswg/tls-subcerts/pull/54 On Sat, Feb 15, 2020 at 12:55 AM Ilari Liusvaara wrote: > On Fri, Feb 14, 2020 at 11:27:36AM -0800, Nick Sullivan wr

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

12:36 PM, internet-dra...@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > >Title : Delegated Cre

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

ies. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : Delegated Credentials for TLS > > Authors : Richard Barnes > > Subodh Iyengar > > Nick Su

Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

I'm in favor of adopting this work. Nick On Thu, Feb 13, 2020 at 9:13 AM Joseph Salowey wrote: > The authors of "Hybrid Key Exchange" have asked for adoption of their > draft as a WG item. Please state whether you support adoption of this > draft as a WG item by posting a message to the TLS

Re: [TLS] ESNI Android Implementation

Hi Justice, Thanks for reaching out and welcome. At this point, another implementation of draft-02 wouldn't hurt, but it also likely won't contribute much to the development process for this document. We've learned what we can from -02 and the upcoming draft version will likely be radically

Re: [TLS] More flexible signature_algorithm selection for Delegated Credentials

On Thu, Nov 21, 2019 at 1:43 PM Martin Thomson wrote: > On Thu, Nov 21, 2019, at 11:54, Nick Sullivan wrote: > > At IETF 106, we discussed adding the ability to advertise specific > > signature algorithms for use in DCs without requiring clients to have > > to support these

Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

On Thu, Nov 21, 2019 at 10:43 AM Salz, Rich wrote: > Likewise, I am okay with the "could be amended" text but in fact I > slightly prefer a new message type, for safety reasons. > How should we determine whether future extensions are permissible in the context of this new message? For example,

[TLS] More flexible signature_algorithm selection for Delegated Credentials

tlswg, At IETF 106, we discussed adding the ability to advertise specific signature algorithms for use in DCs without requiring clients to have to support these signature algorithms in leaf certificates. Here's a PR to address this issue: https://github.com/tlswg/tls-subcerts/pull/46 Comments

[TLS] Maximum lifetime for Delegated Credentials

tlswg, At IETF 106, Hannes Tschofenig suggested that there are use cases in which longer-lived delegated credentials are useful. The idea is to allows the 7-day default to be overridden in the presence of an application profile. This is similar to what is allowed in TLS for MTI cipher suites.

Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

On Tue, Nov 19, 2019 at 6:50 AM Benjamin Kaduk wrote: > On Sun, Nov 17, 2019 at 04:42:05PM +0800, Nick Sullivan wrote: > > Hi Yaron, > > > > Thanks for reminding me about the codepoint issue. It's a sticky one. > > > > As far as I see it, there are three option

Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

use it > can be client-generated in this context. I'd be ok with creating a > different extension for this, but it's rather elegant to re-use it in this > context. *I'd like to hear some opinions from the working group* on this > point > > > > BK: Or, since extension codepoints are ch

Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

Following up, Yaron, do the responses by myself and Benjamin along with the does the following PR sufficiently address your comments/concerns? https://github.com/tlswg/tls-exported-authenticator/pull/52 On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan wrote: > Hi Yaron, > > Thank you

Re: [TLS] Delegated Credentials Question about PSS

On Mon, Oct 21, 2019 at 3:34 PM Martin Thomson wrote: > On Thu, Oct 17, 2019, at 14:32, Watson Ladd wrote: > > In TLS 1.3 it seems to have been assumed this wouldn't happen and we > > could split signature algorithms from signature algorithms cert. > > > > If that's not actually the case it

Re: [TLS] Delegated Credentials Question about PSS

sively to RSAES-OAEP, then the id-RSAES-OAEP object > > identifier MUST be used in the algorithm field within the subject > > public key information ... > > > > I would like to continue with the approach. > > > > Russ > > > > > > > On Oct 15, 201

[TLS] Delegated Credentials Question about PSS

TLSWG, I'd like some feedback on a potential issue raised by Martin Thomson at the last IETF. The question is about the interaction between the SPKI and the signature scheme for RSA delegated credentials. The main concern is around the interaction between the rsaEncryption OID and the signature

Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09

protocol depends on these messages being reliably > delivered, it will want to provide some sort of loss recovery mechanism. > > On Thu, Oct 10, 2019, at 11:47, Nick Sullivan wrote: > > Thanks again for your review! The PR is on Github > > (https://github.com/tlswg/tls-exported

Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09

Thanks again for your review! The PR is on Github ( https://github.com/tlswg/tls-exported-authenticator/pull/50) and will be incorporated into a new version of the document that addresses both your comments and those by Yaron Sheffer. On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg <

Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09

Thanks Christer, Some answers to your questions inline. I'm not sure further changes along the lines suggested here are needed, but I'm open to arguments that point in that direction. On Thu, Sep 19, 2019 at 1:55 AM Christer Holmberg < christer.holmb...@ericsson.com> wrote: > Hi Nick, > >

Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

Hi Yaron, Thank you for your thorough review. My answers will be inline, and I'll incorporate some of Ben's replies if necessary. Here's a PR with proposed changes in response to your comments: https://github.com/tlswg/tls-exported-authenticator/pull/52 On Tue, Jul 16, 2019 at 12:59 PM Yaron

Re: [TLS] Adoption call for draft-nir-tls-tlsflags

I am in favor of adoption. On Wed, Jul 24, 2019 at 8:47 AM Christopher Wood wrote: > At TLS@IETF105, there was interest in the room to adopt > draft-nir-tls-tlsflags as a WG item. The draft can be found here: > >https://datatracker.ietf.org/doc/draft-nir-tls-tlsflags/ > > This email starts

Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

Yaron, Thank you for this review. I'm going to internalize it, come up with potential ways forward and get back to you soon. Best, Nick On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker < nore...@ietf.org> wrote: > Reviewer: Yaron Sheffer > Review result: Has Issues > > The

Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09

Christer, Thank you for the review. I'll attempt to address these in time for the submission window to open up again. Best, Nick On Sun, Jul 7, 2019 at 3:58 AM Christer Holmberg via Datatracker < nore...@ietf.org> wrote: > Reviewer: Christer Holmberg > Review result: Ready with Issues > > I am

[TLS] Delegated Credentials in Client certificates

Hello TLSWG, At previous meetings (and I think on the list?) there were requests to extend the Delegated Credentials in TLS ( https://tools.ietf.org/html/draft-ietf-tls-subcerts) draft to support client certificates. This turns out to be a pretty minor change to the document. I've put up a PR:

Re: [TLS] AD review of draft-ietf-tls-exported-authenticator-08

Ben, Thank you for the thorough review. I've added responses/comments inline and a PR to the spec https://github.com/tlswg/tls-exported-authenticator/pull/46. Feel free to respond in the PR for specific changes or on this thread for structural comments. On Tue, Apr 23, 2019 at 11:21 AM Benjamin

[TLS] Fwd: New Version Notification for draft-sullivan-tls-opaque-00.txt

-- Forwarded message - From: Date: Mon, Mar 11, 2019 at 3:58 PM Subject: New Version Notification for draft-sullivan-tls-opaque-00.txt To: Hugo Krawczyk , Richard Barnes , Owen Friel , Nick Sullivan A new version of I-D, draft-sullivan-tls-opaque-00.txt has been successfully submitted

Re: [TLS] Two Multi-CDN proposals

On Fri, Mar 1, 2019 at 6:27 PM Christopher Wood wrote: > On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop wrote: > > > > Stephen, there are a couple complicating factors here where I think we > all have varying knowledge gaps. > > > > There are two major ways of pointing to a CDN: Direct A/

[TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-03.txt

to discuss this draft in Prague. Nick -- Forwarded message - From: Date: Tue, Feb 19, 2019 at 3:33 PM Subject: New Version Notification for draft-ietf-tls-subcerts-03.txt To: Subodh Iyengar , Richard Barnes , Eric Rescorla , Nick Sullivan A new version of I-D, draft-ietf-tls

Re: [TLS] ticket lifetimes

Wouldn't this issue also be mitigated by requiring the server to re-authenticate during resumption with the certificate once in a while? Nick On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar wrote: > > If by "entire TLS session" you mean the resumed (and renewed) > sessions, then yep! > > Ya I

Re: [TLS] Call for Adoption: TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key

I support adoption. On Fri, Jan 25, 2019 at 3:53 PM Russ Housley wrote: > Of course, I support WG adoption. And, if the document is adopted, I am > willing to continue as author. > > Russ > > > > On Jan 25, 2019, at 1:11 PM, Christopher Wood < > christopherwoo...@gmail.com> wrote: > > > > At

Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

I'm also fine with removing the field and would welcome a PR to that effect. Putting in a version to protect a DC from future cross-protocol attacks that exploit TLS 1.3 smells a bit like over-engineering anyway. Nick On Tue, Jan 15, 2019 at 11:54 PM Subodh Iyengar wrote: > I don't feel too

Re: [TLS] Multi-CDN and ESNI

This line of commentary describes one instance of a more general situation that is unrelated to the multi-provider case: what happens when you connect to a server that doesn't know the ESNI key you're using? This can even happen on a single provider due to DNS caching issues, for example. The two

[TLS] Fwd: New Version Notification for draft-ietf-tls-exported-authenticator-08.txt

At this point, I'd like the chairs to consider starting a second last call for this document. Nick Sullivan -- Forwarded message - From: Date: Thu, Oct 18, 2018 at 2:46 PM Subject: New Version Notification for draft-ietf-tls-exported-authenticator-08.txt To: Nick Sullivan A new version

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-02.txt

nsport Layer Security WG of the IETF. > > Title : Delegated Credentials for TLS > Authors : Richard Barnes > Subodh Iyengar > Nick Sullivan > Eric Rescorla >

Re: [TLS] Proposals for draft-ietf-tls-subcerts-02

I support these changes. Nick On Thu, Jul 26, 2018 at 11:01 AM Patton,Christopher J wrote: > Thanks all for the feedback! In light of your observations, we've revised > the changes proposed for draft-02: > https://github.com/tlswg/tls-subcerts/pull/13. > > > The changes for draft-02 are as

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

he certification path. > > #26 switches to signature_algorithms_cert exclusively. That's an > error, I think. > > In #27, I think that dropping Certificate entirely isn't a good idea. > TLS 1.3 sends it, but leaves it empty. There are a few reasons I > mention in the PR comments. > On Thu, Ma

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

es/25 > > On Sat, May 12, 2018 at 9:59 AM Nick Sullivan > > wrote: > > > Thanks all for the comments on the draft. Let me try to summarize the > comments and propose next steps. > > > Tim Hollebeek had a comment about 0 as the separator. I generally don’t > t

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

://github.com/tlswg/tls-exported-authenticator/pull/24 Nick On Thu, May 3, 2018 at 1:16 PM Nick Sullivan <nicholas.sulli...@gmail.com> wrote: > Does anyone have any comments about the draft, criticisms, or votes of > support? > > Nick > > > On Thu, May 3, 2018 at 1:12 PM

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

Does anyone have any comments about the draft, criticisms, or votes of support? Nick On Thu, May 3, 2018 at 1:12 PM Sean Turner wrote: > > > > On Apr 21, 2018, at 10:25, Sean Turner wrote: > > > > > >> On Apr 19, 2018, at 16:32, Sean Turner

Re: [TLS] draft-ietf-tls-exported-authenticator

Ben, Putting the authenticator in an encrypted tunnel is not necessary for binding, but it is necessary for keeping the certificate itself confidential. I'll add text to that effect. Nick On Wed, Nov 15, 2017 at 7:13 PM Benjamin Kaduk wrote: > In the exported authenticators

Re: [TLS] Exported Authenticators proposed change to incorporate authenticator request

This is an uncontroversial change and nobody has responded from the list, so unless someone has any objections I'm going to incorporate this change (along with a change to address Benjamin Kaduk's comments) and publish a new draft next week. Nick On Thu, Nov 23, 2017 at 1:18 PM Nick Sullivan

[TLS] Exported Authenticators proposed change to incorporate authenticator request

Martin Thomson raised an issue Github (Issue #5 ) suggesting that we modify the exported authenticators draft to include the ability to incorporate a CertificateRequest into an authenticator. I have put together a set of changes to the

Re: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-04.txt

directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Exported Authenticators in TLS > Author : Nick Sullivan > Filename: draft-ietf-tls-exported-authenticator-04.txt > Pages

Re: [TLS] Draft RHRD

to inform a public debate. Nick On Wed, Nov 1, 2017 at 7:19 AM Salz, Rich <rs...@akamai.com> wrote: > In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html, Nick > Sullivan concluded: > > > > >- on the other hand using draft-rhrd is safer than allowing organiz

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

I didn't want to stick my foot in this, but here we are. The goal for an inspection service to be able to take a recording of the network and a key (or corpus of keys) and be able to decrypt any TLS connection to a server within that network. There are multiple ways of getting these keys. 1) use

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ralph and Russ, This draft addresses the two main concerns I had with draft-green: 1) Client opt-in 2) On-the wire visibility There are clearly some details missing from this draft (such as how Ke is used as a symmetric key), but generally I think this approach is more explicit and therefore

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Yoav, Let me make a correction to your scenario:. Instead of: "You’ll need it for Chrome to work with Google." it's: "You’ll need it for Chrome to work with Google, Facebook, and most of the 10% of Alexa top million sites that are using Cloudflare." TLS 1.3 (in on draft version or another) is

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

This situation is likely to arise every time a new signature algorithm is introduced. Suppose a TLS client library is updated to support Ed25519 certificates, but that the PKIX library only supports validating Ed25519 certificates signed by RSA or ECDSA, which signature schemes should the client

[TLS] TLS Hackathon in Singapore

and interoperability of adopted drafts Feel free to contribute ideas if you want to participate. Nick Sullivan ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

are still valid. > > > > Could you please comment on / add them to your pro-cons analysis? > > > > Cheers, thanks, > > t > > > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html > > > > On 18/07/2017, 12:06, "TLS on beh

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

It's a reality of the current CT system. If a crawler sees a short-lived certificate, it will submit it to a CT log and it will be accepted. On Tue, Jul 18, 2017 at 2:45 PM Salz, Rich wrote: > > Con short-lived certs: > > - Potentially problematic to the CT ecosystem (all

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

Sean, We've had some additional discussions in person here at IETF 99 with folks who were in the proxy certificates and short-lived certs camp, and we think there is now more agreement that the mechanism described in this draft is superior to the alternatives. I've included a summary of some of

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

I'd like to raise another point. Static Diffie-Hellman is a cryptographically problematic construction. Not only was it found to be fragile to implement in the prime field variant (LogJam), the Elliptic Curve variant has recently been identified as troublesome as well (see recent JWE

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Putting questions of whether or not this belongs as a working group document, I think there are some necessary requirements for intra-datacenter passive decryption schemes that are not met by this draft. Specifically, any passive decryption scheme should the following two properties: 1) Both

Re: [TLS] Exported Authenticators proposed updates

Thanks for the comments. I've updated the PRs appropriately. On Tue, Jun 13, 2017 at 12:56 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Tue, Jun 13, 2017 at 12:32:12AM +0000, Nick Sullivan wrote: > > All, > > > > I've collected a few changes that he

[TLS] Exported Authenticators proposed updates

All, I've collected a few changes that help clarify some ambiguities brought up on the list and during implementation of the draft. These changes are laid out as the following PRs in Github: Restrict the Certificate type to standard X.509 certificates.

Re: [TLS] Comments on draft-ietf-tls-exported-authenticator-00

at 1:12 PM Benjamin Kaduk <bka...@akamai.com> wrote: > On 05/23/2017 03:07 PM, Nick Sullivan wrote: > > 3) In TLS 1.3 post-handshake authentication, each successive certificate > added to the connection is incorporated into the handshake state. The last > certificate in a sequen

Re: [TLS] Comments on draft-ietf-tls-exported-authenticator-00

Hi Watson, Some points that should help clarify your questions: 1) The certificate used in the construction is no the plain certificate chain, it's the TLS 1.3 certificate message which could contain extensions. 2) The finished message is used to bind the certificate+certificateverify to the

Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator

Thanks for the review. I'm open to adding text indicating that the exported authenticator SHOULD be sent using an application protected by the TLS stream in question, but I don't want to remove the possibility of sending the data over a secure secondary channel, depending on the application. Nick

Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator

On Sat, Apr 15, 2017 at 6:42 AM Ilari Liusvaara wrote: > On Fri, Apr 14, 2017 at 02:44:25PM +0300, Ilari Liusvaara wrote: > > On Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph Salowey wrote: > > > Hey Folks, > > > > > > At the IETF 98 meeting in Chicago there was support

Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator

Thanks for the review. Comments/questions inline. I put together a pull request with your suggested changes here if you would like to review: https://github.com/grittygrease/tls-exported-authenticator/pull/11 On Fri, Apr 14, 2017 at 4:44 AM Ilari Liusvaara wrote: > On

Re: [TLS] Interest in draft-sullivan-tls-exported-authentication

cation status of the connection and the TLS layer does not. The application keeps track of the accounting, the TLS layer just mints and validates authenticators. This enables applications like HTTP/2 to use TLS certificates for features that would have previously used renegotiation. Nick > -Brian

Re: [TLS] Interest in draft-sullivan-tls-exported-authentication

All, I have updated the draft in preparation for the IETF 98: https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-01 The details of the protocol haven't changed, but I've included some security considerations after speaking with Karthikeyan Bhargavan and others about the

Re: [TLS] Confirming consensus: TLS1.3->TLS*

I took a very unofficial Twitter poll on this subject: https://twitter.com/grittygrease/status/80364408215424 Nick On Tue, Nov 29, 2016 at 5:47 AM Raja ashok wrote: > I feel we can go ahead with TLS 1.3. > > Or else TLS 3.4, because anyway we send 0x0304 on wire for

Re: [TLS] Confirming consensus: TLS1.3->TLS*

If we decide to move to some numeral higher than 3 to avoid confusion, I recommend *TLS 4*, but urge people to tell the story of the name in a way that retains some sense of continuity and logic. Here's a framing that makes sense: *TLS 4 is the fourth version of TLS* This framing will tell a

[TLS] draft-sullivan-tls-exported-authenticator-00

s.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01), and should generally be a useful tool for binding a certificate ownership proof to a TLS connection. Nick Sullivan ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

size. > > Ciao > Hannes > > > On 10/08/2016 03:03 AM, 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 attempt to make the story more expl

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

t handshake > message X which will be invented in 2018" (but of course we can register > an extension for > that then), but less useful to say "I don't like NST or KU" > > -Ekr > > > On Sat, Oct 8, 2016 at 9:32 AM, Nick Sullivan <nicholas.sulli...@gmail.com

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

AM Ilari Liusvaara <ilariliusva...@welho.com> > 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

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

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 attempt to make the story more explicit by adding a new post_handshake extension to TLS 1.3. Supporting all types of post-handshake messages can

  1   2   >