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

[Nick Sullivan]

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
> draft-ietf-tls-subcerts-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>
>
>
> --
> COMMENT:
> --
>
> ** Section 4
>  Endpoints will reject delegated
>   credentials that expire more than 7 days from the current time (as
>   described in Section 4.1) based on the default (see Section 3.
>
> For clarity, consider:
>
> NEW
> By default, unless set to an alternative value by an application profile
> (see
> Section 3), endpoints will reject delegated credentials that expire more
> than 7
> days from the current time (as described in Section 4.1.3).
>
> ** Section 7.1
>However, they cannot create new delegated credentials.  Thus,
>delegated credentials should not be used to send a delegation to an
>untrusted party, ...
>
> The second sentence doesn’t seem to follow from the first.
>
> ** Appendix B
>The following certificate has the Delegated Credentials OID.
>
> For clarity, consider:
>
> NEW
> The following is an example of a delegation certificate which satisfies the
> requirements described in Section 4.2 (i.e., uses the DelegationUsage
> extension
> and has the digitalSignature KeyUsage).
>
> ** Appendix B.  I will leave to the RFC Editor to decide if using the
> Watson
> Ladd’s personal home page (kc2kdm.com) in the certificate SAN is an
> acceptable
> example domain name.
>
> Editorial Nits
>
> ** Abstract.  Typo. s/to to/to/
>
> ** Section 4.2. Typo. s/documnt/document/
>
> ** Section 7.6.  In the spirit of inclusive language, consider if there is
> an
> alternative term to “man-in-the-middle certificate”
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 the following ballot position for
> draft-ietf-tls-subcerts-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the work on this document.
>
> Many thanks to Christian Amsüss for his ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/7lzdOaiccRnXFtSuX3aUyh9ffV8/.
> Authors, please take a look at Christian's comments (also reported below),
> especially the one about the "delegated_credential" usage in the
> Certificate
> message.
>
> Francesca
>
> --
>
> Reviewer: Christian Amsüss
> Review result: Ready with Nits
>
> Thanks for this well-written document
>
> ART topics:
>
> The document does not touch on any of the typical ART review issues; times
> are
> relative in well understood units, and versioning, formal language (ASN.1,
> which is outside of my experience to check) and encoding infrastructure
> (struct) follows TLS practices.
>
> General comments:
>
> * The introduction of this mechanism gives the impression of a band-aid
> applied
> to a PKI ecosystem that has accumulated many limitations as outlined in
> section
> 3.1. The present solution appears good, but if there is ongoing work on the
> underlying issues (even experimentally), I'd appreciate a careful
> reference to
> it.
>

Unfortunately, there are no good references for alternative approaches.

>
> * Section 7.6 hints at the front end querying the back-end for creation of
> new
> DCs -- other than that, DC distribution (neither push- nor pull-based) is
> discussed. If there are any mechanisms brewing, I'd appreciate a reference
> as
> well.
>

There are no formal mechanisms moving towards standardization at this time.

>
> Please check:
>
> * The IANA considerations list "delegated_credential" for CH, CR and CT
> messages. I did not find a reference in the text for Ct, only for CH and
> CR.
>

See section 4.1.2, where it states:
"The client MUST send the DC as an extension in the CertificateEntry of its
end-entity certificate" which is where CT extensions live.

>
> Editorial comments:
>
> * (p5) "result for the peer.." -- extraneous period.
> * (p9, p15, p16) The "7 days" are introduced as the default for a
> profilable
> prarameter, but later used without further comment.
>
> Addressed
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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
> draft-ietf-tls-subcerts-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>
>
>
> --
> COMMENT:
> --
>
> # GEN AD review of draft-ietf-tls-subcerts-14
>
> CC @larseggert
>
> Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
> (https://mailarchive.ietf.org/arch/msg/gen-art/QDnSqLec7uKP9GcyuL-8p8nS-2s
> ).
>
> ## Comments
>
> ### Section 6, paragraph 2
> ```
>  This document also defines an ASN.1 module for the DelegationUsage
>  certificate extension in Appendix A.  IANA has registered value 95
>  for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX
>  Module Identifier" (1.3.5.1.5.5.7.0) registry.  An OID for the
>  DelegationUsage certificate extension is not needed as it is already
>  assigned to the extension from Cloudflare's IANA Private Enterprise
>  Number (PEN) arc.
> ```
> See Martin Duke's comment on using the Cloudflare space; I have the same
> question.
>

This has been addressed by Sean Turner on the list.

>
> ### Inclusive language
>
> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and
> more
> guidance:
>
>  * Term `man`; alternatives might be `individual`, `people`, `person`
>  * Term `invalid`; alternatives might be `not valid`, `unenforceable`, `not
>binding`, `inoperative`, `illegitimate`, `incorrect`, `improper`,
>`unacceptable`, `inapplicable`, `revoked`, `rescinded`
>

Fixed in link below

>
> ### IP addresses
>
> Found IP blocks or addresses not inside RFC5737/RFC3849 example ranges:
> `1.3.5.1` and `5.5.7.0`.
>

> ## Nits
>
> All comments below are about very minor potential issues that you may
> choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
> there
> will likely be some false positives. There is no need to let me know what
> you
> did with these suggestions.
>
> ### Typos
>
>  Section 4.2, paragraph 1
> ```
> -This documnt defines a new X.509 extension, DelegationUsage, to be
> +This document defines a new X.509 extension, DelegationUsage, to be
> +  +
> ```
>
> ### Outdated references
>
> Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this
> may
> be on purpose).
>

Yes, it's referencing an attack

>
> ### Grammar/style
>
>  Paragraph 2
> ```
> his document describes a mechanism to to overcome some of these limitations
>^
> ```
> Possible typo: you repeated a word.
>
>  Section 5.1, paragraph 1
> ```
> tial's private key is thus important and access control mechanisms SHOULD
> be
> 
> ```
> Use a comma before "and" if it connects two independent clauses (unless
> they
> are closely connected and short).
>
>  Section 6, paragraph 1
> ```
> f early revocation. Since it is short lived, the expiry of the delegated
> cre
> ^^^
> ```
> This word is normally spelled with a hyphen.
>
>  Section 7, paragraph 1
> ```
> ime could be unique and thus privacy sensitive clients, such as browsers
> in i
>  ^
> ```
> This word is normally spelled with a hyphen.
>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> [IRT]: https://github.com/larseggert/ietf-reviewtool
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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
>
>
> > On 2022-4-9, at 3:18, Elwyn Davies via Datatracker 
> wrote:
> >
> > Reviewer: Elwyn Davies
> > Review result: Ready with Nits
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair.  Please treat these comments just
> > like any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > .
> >
> > Document: draft-ietf-tls-subcerts-??
> > Reviewer: Elwyn Davies
> > Review Date: 2022-04-08
> > IETF LC End Date: 2022-04-08
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> > Ready with nits.Just a few editrial level nits.
> >
> > Major issues:
> > None
> >
> > Minor issues:
> > None.
> >
> > Nits/editorial comments:
> > Abstract: The exact form of the abbreviation (D)TLS is not in the set of
> > well-known abbreviations.  I assume it is supposed to mean DTLS or TLS -
> This
> > ought to be expanded on first use.
> >
> > Abstract:  s/mechanism to to/mechanism to/
> >
> > s1, para 2: CA is used before its expansion in para 3.
> >
> > s1, next to last para: "this document proposes"  Hopefully when it
> becomes an
> > RFC it will do more than propose.  Suggest "this document introduces".
> >
> > s1, next to last para:  "to speak for names"  sounds a bit
> anthropomorphic to
> > me, but I can't think of a simple alternative word.
> >
> > s1, last para: s/We will refer/This document refers/  [Not an academic
> paper!]
> >
> > s3.1, 2nd bullet: s/provide are not necessary/provide is not necessary/
> >
> > s4, definition of expected_cert_verify_algorithm:  " Only signature
> algorithms
> > allowed for use in CertificateVerify message are allowed."  Does this
> need a
> > reference to the place where the list of such algorithms is recorded?
> >
> > s4.1.1 and s4.1.2:  In s4.1.1:  "the client SHOULD ignore delegated
> credentials
> > sent as extensions to any other certificate."  I would have though this
> ought
> > to be a MUST.  There is an equivalent in s4.1.2. I am not sure what the
> > client/server might do if it doesn't ignore the DC.
> >
> > s4.1.3, para 1: s/same way that is done/same way that it is done/
> >
> > s4.2, para 1: s/We define/This docuent defines/
> >
> > sS/s5.1: RFC conventions prefer not to have sections empty of text:  Add
> > something like: "The following operational consideration should be taken
> into
> > consideration when using Delegated Certificates:"
> >
> >
> >
> > --
> > last-call mailing list
> > last-c...@ietf.org
> > https://www.ietf.org/mailman/listinfo/last-call
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

Hi Éric,

Thank you for your review. Responses inline and edits in Github (
https://github.com/tlswg/tls-subcerts/pull/108/files).


> --
> COMMENT:
> --
>
> # Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of
> draft-ietf-tls-subcerts-14
>
> Thank you for the work put into this document. It solves a common and
> important
> issue while keeping backward compatibility.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
>
> Special thanks to Joe Salowey for the shepherd's write-up including the WG
> consensus and the intended status.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> ## COMMENTS
>
> ### Section 1
>
> ```
>Furthermore, this mechanism allows the server to use modern signature
>algorithms such as Ed25519 [RFC8032] even if their CA does not
>support them.
> ```
> Does it also mean that the signature algorithm could be weaker ?
>

In theory, TLS 1.3 (and by extension DCs) do not support weak signature
schemes.


> I found the use of `(D)TLS termination services`, `(D)TLS server`, `(D)TLS
> peer` a little confusing on whether they represent the same entity.
>

I added some text in the introduction to clarify.

>
> ### Section 3.2
>
> The small graphic in the text is really useful but:
>
> * should include a figure legend
> * the bottom part would be welcome in the introduction
>

Added

>
> ## Section 4.2
>
> Thanks to Sean Turner for providing the explanation about the use of
> Cloudflare
> OID into an IETF standard.
>
> ## Section 5.1
>
> Unsure whether having such a short subsection is useful (albeit being
> harmless)
> especially when there is only one subsection.
>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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://github.com/tlswg/tls-subcerts/compare/nick/wouters-review-may22?expand=1
>>
>> Comments inline.
>>
>
> Thanks for the changes and explanations.
>
> Looks good to me, so please continue with a draft update if you have to go
> ahead of your co-authors / WG.
>
> Paul
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 not further
> hold up this document. Ben's write up can be found at:
> https://mailarchive.ietf.org/arch/msg/tls/qa908s0dMNxbUOZhnUel0qEVBSg/
>
> Please treat the below as you would treat any other comments.
>
> Test vectors available but still not included - did these get verified ?
> Can these be included?
>
The current vectors are out of date. We're working on getting these updates
in the PR (https://github.com/tlswg/tls-subcerts/pull/77).

>
>  expected_cert_verify_algorithm - why is this not called
> dc_cert_verify_algorithm or dc_verify_algorithm ?
>   As in, why is there an "expected" prefix? We talk about
> signature_algorithms and not expected_signature_algorithms ?
>
I'm fine with dc_cert_verify_algorithm and have updated it.


>
>   algorithm:  The signature algorithm used to verify
>   DelegatedCredential.signature.
>
> This reads weird. If the signature algorithm is "used", it was to create
> the signature.
> The verification is in the future though. Perhaps say "The signature
> algorithm used to
> create the DelegatedCredential.signature"
>
Ok, changed.


>
>
>1.  A string that consists of octet 32 (0x20) repeated 64 times.
>
> - Why is there a 64 spaces prefix ?
> - Should it say a non-null terminated string? Or perhaps "octet stream"
> instead of "string" ?
>

It's a technique for domain separation that was taken from TLS 1.3 (4.4.3.
Certificate Verify) to prevent chosen-prefix attacks (
https://github.com/tlswg/tls13-spec/commit/c3902e65). The initial bytes
cover an entire hash block before the domain separator. This text was taken
directly from TLS 1.3, so the ambiguity remains there too, but I'm happy to
change this text to be more explicit.


>
>

>2.  The context string "TLS, server delegated credentials" for server
>authentication and "TLS, client delegated credentials" for client
>authentication.
>
> - Same here, non-null terminated string?
>
>3.  A single 0 byte, which serves as the separator.
>
> a few lines up it used hex notation for 0x20 and named it octet. Should
> this be called
> a single octet of value 0x00 ?
>

This text is taken directly from TLS 1.3 also, but it can be made less
ambiguous.

>
>A client which supports this specification SHALL send a
>"delegated_credential" extension in its ClientHello.
>
> This oddly means that a client that supports this cannot really choose to
> not use it. Normally, this is more written as
>"A client that is willing to use DC includes a "delegated_credential"
> extension in its ClientHello"
>

Agreed. Re-phrased.

>
>  If the client receives a delegated credential without having
>  indicated support in its ClientHello
>
> According to the above, this "SHALL" not happen because to recognise the
> extension it needs to support it and if it supports it, it SHALL send it :)
>

With the new phrasing above this now makes sense. The client can support
DCs but not be willing to use it in a given connection, and in this case if
the server sends it the connection should fail. However, this is the
default behavior in TLS when a client receives an unsolicited extension, so
it may still be a bit redundant.


>
>The server MUST ignore the extension unless
>(D)TLS 1.3 or a later version is negotiated.
>
> That is oddly phrased as a MUST with an exception (which is really a
> SHOULD)
> Perhaps: "When a (D)TLS version negotiated is less than 1.3, the server
> MUST ignore this extension"
>

Yes, this is better.

>
> The client MUST ignore the extension unless
>(D)TLS 1.3 or a later version is negotiated.
>

> Same here.
>
Done

>
> The server MUST send the delegated credential
>
> Should that be "delegated_credential", eg underscore instead of space? Or
> use DC ?
>
> We'll use DC.

>
>the server SHOULD
>ignore delegated credentials sent as extensions to any other
>certificate.
>
> Why is the case a "SHOULD ignore" where all the other cases of unexpected
> DC uses "MUST " ?
>

This draft doesn't speak to the use of DCs in the certificate chain or
modify the behavior of TLS with respect to certificate chain validation.
Adding a requirement to change behavior based on the certificate chain may
require implementers to modify PKIX libraries, which this draft currently
does not do.

>
>
> I'm a little confused by Section 7.4.  Interactions with Session
> Resumption.
> The session resumption uses a seperate continue mechanism that omits
> needing to re-authenticate the peer. It has its own
> session ticket lifetimes to keep its state. Why is that mechanism on its
> own not enough? If the server still has the session state
> why would a valid DC be a requirement to use an existing ticket? Or
> 

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

[Nick Sullivan]

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'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
> additional PR to go along with Benjamin's PR and submit a new draft version.
>
> Nick
>
>
> >>>>>
>
> Hi all,
>
> Generally I like the shape this is in, but there's enough potentially in
> flux after this review that I'd like to clean things up with a revised I-D
> before I kick off the IETF LC.  I think my comments on §4.2 are the ones
> that are most likely to result in any significant discussion.
>
> I made some (hopefully) editorial suggestions in a github PR, though
> a couple seemed borderline enough that I mention them here as well.
> (https://github.com/tlswg/tls-subcerts/pull/93)
>
> Abstract
>
> (editorial) There seems to be a large jump from the sentence that say
> the CA ultimately determines a lot about the certificate and the
> sentence describing the mechanism this document describes.  We might
> want to help the transition by also saying that the new mechanism
> partially overcomes/mitigates those limitations.
>
> [NS]
> Proposed changes
> Before:
>The organizational separation between the operator of a TLS endpoint
>and the certification authority can create limitations.  For example,
>the lifetime of certificates, how they may be used, and the
>algorithms they support are ultimately determined by the
>certification authority.  This document describes a mechanism by
>which operators may delegate their own credentials for use in TLS,
>without breaking compatibility with peers that do not support this
>specification.
>
> NEW:
>The organizational separation between the operator of a TLS endpoint
>and the certification authority can create limitations.  For example,
>the lifetime of certificates, how they may be used, and the
>algorithms they support are ultimately determined by the
>certification authority.  This document describes a mechanism to
>to overcome some of these limitations by enabling operators to
>delegate their own credentials for use in TLS without breaking
>compatibility with peers that do not support this specification.
> [/NS]
>
> Section 1
>
>   However, short-lived certificates need to be renewed more frequently
>   than long-lived certificates.  If an external CA is unable to issue a
>   certificate in time to replace a deployed certificate, the server
>   would no longer be able to present a valid certificate to clients.
>
> (editorial) Most of the document carefully phrases things so that it
> does not presume that the DC holder is the TLS server (e.g., in this
> section we mostly talk about "server operator"s).  This chunk does
> not, and arguably the following paragraph as well.  I didn't come up
> with a different phrasing I liked so as to offer it in my PR, though.
>
> [NS]
> In this section we are talking about traditional TLS deployments (without
> DCs or remote key operations) to motivate the document.  In
> these scenarios the certificate is typically deployed to server
> may introduce confusion to differentiate between server and certificate
> holder.  I don’t think there’s a useful change we can make that improves
> clarity.
> [/NS]
>
> Section 3
>
>   It was noted in [XPROT] that certificates in use by servers that
>   support outdated protocols such as SSLv2 can be used to forge
>   signatures for certificates that contain the keyEncipherment KeyUsage
>   ([RFC5280] section 4.2.1.3).  In order to prevent this type of cross-
>   protocol attack, we define a new DelegationUsage extension to X.509
>   that permits use of delegated credentials.  (See Section 4.2.)
>
> If I understand correctly, the extension serves to prevent *existing*
> misconfigured servers from being leveraged in a cross-protocol attack to
> "sign" DCs usable for TLS 1.3.  As we discuss in §7.6, however, it does
> not prevent the attack when such a misconfigured server is given a new
> certificate that contains the extension (as might happen if a cert is
> shared across the TLS 1.2 and TLS 1.3 backends for a single service and
> the TLS 1.2 implementation is unloved).  So maybe we should hedge our
> language a bit from "prevent this type of cross-protocol attack".
>
> [NS]
> Very good point.
>
> Proposed changes
>
> NEW:
>   It was 

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

[Nick Sullivan]

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
additional PR to go along with Benjamin's PR and submit a new draft version.

Nick


>

Hi all,

Generally I like the shape this is in, but there's enough potentially in
flux after this review that I'd like to clean things up with a revised I-D
before I kick off the IETF LC.  I think my comments on §4.2 are the ones
that are most likely to result in any significant discussion.

I made some (hopefully) editorial suggestions in a github PR, though
a couple seemed borderline enough that I mention them here as well.
(https://github.com/tlswg/tls-subcerts/pull/93)

Abstract

(editorial) There seems to be a large jump from the sentence that say
the CA ultimately determines a lot about the certificate and the
sentence describing the mechanism this document describes.  We might
want to help the transition by also saying that the new mechanism
partially overcomes/mitigates those limitations.

[NS]
Proposed changes
Before:
   The organizational separation between the operator of a TLS endpoint
   and the certification authority can create limitations.  For example,
   the lifetime of certificates, how they may be used, and the
   algorithms they support are ultimately determined by the
   certification authority.  This document describes a mechanism by
   which operators may delegate their own credentials for use in TLS,
   without breaking compatibility with peers that do not support this
   specification.

NEW:
   The organizational separation between the operator of a TLS endpoint
   and the certification authority can create limitations.  For example,
   the lifetime of certificates, how they may be used, and the
   algorithms they support are ultimately determined by the
   certification authority.  This document describes a mechanism to
   to overcome some of these limitations by enabling operators to
   delegate their own credentials for use in TLS without breaking
   compatibility with peers that do not support this specification.
[/NS]

Section 1

  However, short-lived certificates need to be renewed more frequently
  than long-lived certificates.  If an external CA is unable to issue a
  certificate in time to replace a deployed certificate, the server
  would no longer be able to present a valid certificate to clients.

(editorial) Most of the document carefully phrases things so that it
does not presume that the DC holder is the TLS server (e.g., in this
section we mostly talk about "server operator"s).  This chunk does
not, and arguably the following paragraph as well.  I didn't come up
with a different phrasing I liked so as to offer it in my PR, though.

[NS]
In this section we are talking about traditional TLS deployments (without
DCs or remote key operations) to motivate the document.  In
these scenarios the certificate is typically deployed to server
may introduce confusion to differentiate between server and certificate
holder.  I don’t think there’s a useful change we can make that improves
clarity.
[/NS]

Section 3

  It was noted in [XPROT] that certificates in use by servers that
  support outdated protocols such as SSLv2 can be used to forge
  signatures for certificates that contain the keyEncipherment KeyUsage
  ([RFC5280] section 4.2.1.3).  In order to prevent this type of cross-
  protocol attack, we define a new DelegationUsage extension to X.509
  that permits use of delegated credentials.  (See Section 4.2.)

If I understand correctly, the extension serves to prevent *existing*
misconfigured servers from being leveraged in a cross-protocol attack to
"sign" DCs usable for TLS 1.3.  As we discuss in §7.6, however, it does
not prevent the attack when such a misconfigured server is given a new
certificate that contains the extension (as might happen if a cert is
shared across the TLS 1.2 and TLS 1.3 backends for a single service and
the TLS 1.2 implementation is unloved).  So maybe we should hedge our
language a bit from "prevent this type of cross-protocol attack".

[NS]
Very good point.

Proposed changes

NEW:
  It was noted in [XPROT] that certificates in use by servers that
  support outdated protocols such as SSLv2 can be used to forge
  signatures for certificates that contain the keyEncipherment KeyUsage
  ([RFC5280] section 4.2.1.3).  In order to reduce the risk of cross-
  protocol attacks on certificates that are not intended to be used
  with DC-capable TLS stacks, we define a new DelegationUsage
  extension to X.509 that permits use of delegated credentials.  (See
Section 4.2.)
[/NS]

Section 3.1

  *  X.509 semantics are very rich.  This can cause unintended
 consequences if a service owner creates a proxy certificate where
 the properties differ from the leaf certificate.  

Re: [TLS] [Uta] OCSP in RFC7525bis

[Nick Sullivan]

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 SHOULD-level requirement (for TLS 1.3 implementations, possibly
> also TLS 1.2 implementations) to fail the handshake if the OCSP response is
> missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)
> > Remove the whole discussion of OCSP, saying that in its current form
> it’s not adding value.
> > Maintain the status quo, where many people implement OCSP on the server
> side, but clients rarely benefit.
> >
> I don't think that OCSP is not adding value in its current form. I
> have seen a lot of OCSP implementations with hard fail, especially on
> the server side for authenticating clients using private PKI
> certificates. Although OCSP does not add much value on the client side
> as it's a bit fragile for public PKI and client side checks because of
> the matrix of multiple OCSP status producers and consumers at scale.
>
> -Mohit
>
> ___
> Uta mailing list
> u...@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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
> https://github.com/tlswg/tls-exported-authenticator/pull/74#discussion_r734572153
> but either way this seems like a good plan.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

TLS WG,

We've published the -11 version of the Delegated Credentials draft. It
incorporates the feedback from the latest round of discussions.

Nick

On Thu, Sep 23, 2021 at 12:05 PM  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 Credentials for TLS
> Authors : Richard Barnes
>   Subodh Iyengar
>   Nick Sullivan
>   Eric Rescorla
> Filename: draft-ietf-tls-subcerts-11.txt
> Pages   : 20
> Date: 2021-09-23
>
> Abstract:
>The organizational separation between the operator of a TLS endpoint
>and the certification authority can create limitations.  For example,
>the lifetime of certificates, how they may be used, and the
>algorithms they support are ultimately determined by the
>certification authority.  This document describes a mechanism by
>which operators may delegate their own credentials for use in TLS,
>without breaking compatibility with peers that do not support this
>specification.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-11
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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:
https://github.com/tlswg/tls-exported-authenticator/pull/74

Responses welcome!

=

Open questions for debate

Should we define an optional API to generate the certificate_request_context?
[ns] Proposed solution: no, let the application decide

Should we remove the SHOULDs in Section 7, as they have little to do
with interoperability?
[ns] Proposed solution: leave the text as is.

Are there any security issues caused by the fact that the Exported
Authenticator is based on the Exporter Secret, which does not
incorporate the entire transcript:

  Using an exporter value as the handshake context means that any client
  authentication from the initial handshake is not cryptographically
  digested into the exporter value.  In light of what we ran into with
  EAP-TLS1.3, do we want to revisit whether we're still happy with that?
  We should in practice still benefit from the implicit confirmation that
  anything the server participates in after receiving the Client Finished
  means the server properly validated it and did not abort the handshake,
  but it's a bit awkward, especially since the RFC 8446 post-handshake
  authentication does digest the entire initial handshake transcript.
  Would we feel any safer if an exporter variant was available that
  digested the entire initial handshake transcript and we could use that?

[ns] This is a very good question. I didn’t follow the EAP-TLS1.3
issue closely, but this does seem to imply an imperfect match with
post-handshake authentication in the case of mutually authenticated
connections. I would like to suggest that Jonathan Hoyland (cc'd), who
did the formal analysis on the protocol, provide his input.

A comment from Yaron Scheffer/Benjamin Kaduk on the IANA considerations:

My understanding is that the intent of this document is to only allow
"server_name" to appear in the ClientCertificateRequest structure that
otherwise uses the "CR" notation in the TLS 1.3 column of the TLS
ExtensionType Values registry, but not to allow for "server_name" in
authenticator CertificateRequests or handshake CertificateRequests.
Assuming that's correct, the easiest way to indicate that would be if
there was a "Comment" column in the registry that could say "only used
in ClientCertificateRequest certificate requests and no other
certificate requests", but there is not such a column in the registry.
I think it could also work to be much more clear in the IANA
considerations of this document as to why the "CR" is being added and
what restrictions there are on its use, even if that's not quite as
clean of a solution.

[ns] Proposed solution:
Add text to section 8.1 to clarify why the CR is being added and what
restrictions there are to its use, as is done in
https://github.com/tlswg/tls-exported-authenticator/pull/74.
 Alternate solution:
Propose a new column, as done in
https://github.com/tlswg/tls-exported-authenticator/pull/75

=

Comments and responses

Proposals to address IESG comments below are here:
https://github.com/tlswg/tls-exported-authenticator/pull/74

Martin Duke (No Objection):

- I come away from this not being entirely sure if this document applies to
DTLS or not. There is the one reference in the intro to DTLS, but it's not in
the abstract, nor anywhere else. Assuming that the Sec. 1 reference is not some
sort of artifact, the document would benefit from a liberal sprinkling of
's/TLS/(D)TLS' (but this would not apply to every instance)

[ns] DTLS does not explicitly define a post-handshake authentication,
so not all references made sense to update, but I updated all the
relevant references.

- If (D)TLS 1.2 is REQUIRED to implement, then does this document not update
those RFCs?

[ns] It doesn’t change existing versions of (D)TLS and it is not
mandatory to include this functionality, so I don’t think that it
updates them. It’s a separate and optional feature built on top of
TLS. In any case, the text is changed to make it explicit that this is
a minimum requirement.

NITS:

- Sec 1. I think you mean Sec 4.2.6 of RFC 8446, not 4.6.3.
[ns] It’s actually neither, it’s 4.6.2. Sec. 4.2.6 defines the
extension that the client uses to advertise support for post-handshake
authentication.

- Sec 4 and 5. "use a secure with..." ?
[ns] Added “transport”

- Sec 4. s/messages structures/message structures
[ns] Fixed




Erik Kline's No Objection

--
COMMENT:
--

[ sections 4 & 5 ]

* "SHOULD use a secure with" ->
  "SHOULD use a secure communications channel with" or
  "SHOULD use a secure transport with" or something?
[ns] Fixed in previous change

* "as 

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

[Nick Sullivan]

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:

https://github.com/tlswg/tls-exported-authenticator/pull/74

Responses welcome!

Open questions for debate

Should we define an optional API to generate the
certificate_request_context?

*Proposed solution*: no, let the application decide

Should we remove the SHOULDs in Section 7, as they have little to do with
interoperability?

*Proposed solution*: leave the text as is.

Are there any security issues caused by the fact that the Exported
Authenticator is based on the Exporter Secret, which does not incorporate
the entire transcript

Using an exporter value as the handshake context means that any client

authentication from the initial handshake is not cryptographically

digested into the exporter value.  In light of what we ran into with

EAP-TLS1.3, do we want to revisit whether we're still happy with that?

We should in practice still benefit from the implicit confirmation that

anything the server participates in after receiving the Client Finished

means the server properly validated it and did not abort the handshake,

but it's a bit awkward, especially since the RFC 8446 post-handshake

authentication does digest the entire initial handshake transcript.

Would we feel any safer if an exporter variant was available that

digested the entire initial handshake transcript and we could use that?

This is a very good question. I didn’t follow the EAP-TLS1.3 issue closely,
but this does seem to imply an imperfect match with post-handshake
authentication in the case of mutually authenticated connections. I would
like to suggest that Jonathan Hoyland (cc'd), who did the formal analysis
on the protocol, provide his input.

A comment from Yaron Scheffer/Benjamin Kaduk on the IANA considerations

My understanding is that the intent of this document is to only allow
"server_name" to appear in the ClientCertificateRequest structure that
otherwise uses the "CR" notation in the TLS 1.3 column of the TLS
ExtensionType Values registry, but not to allow for "server_name" in
authenticator CertificateRequests or handshake CertificateRequests.
Assuming that's correct, the easiest way to indicate that would be if there
was a "Comment" column in the registry that could say "only used in
ClientCertificateRequest certificate requests and no other certificate
requests", but there is not such a column in the registry. I think it could
also work to be much more clear in the IANA considerations of this document
as to why the "CR" is being added and what restrictions there are on its
use, even if that's not quite as clean of a solution.

*Proposed solution*:

Add text to section 8.1 to clarify why the CR is being added and what
restrictions there are to its use, as is done in
https://github.com/tlswg/tls-exported-authenticator/pull/74.

*Alternate solution*:

Propose a new column, as done in
https://github.com/tlswg/tls-exported-authenticator/pull/75

=

Comments and responses


Proposals to address IESG comments below are here:
https://github.com/tlswg/tls-exported-authenticator/pull/74


Martin Duke (No Objection):

- I come away from this not being entirely sure if this document applies to

DTLS or not. There is the one reference in the intro to DTLS, but it's not
in

the abstract, nor anywhere else. Assuming that the Sec. 1 reference is not
some

sort of artifact, the document would benefit from a liberal sprinkling of

's/TLS/(D)TLS' (but this would not apply to every instance)

DTLS does not explicitly define a post-handshake authentication, so not all
references made sense to update, but I updated all the relevant references.

- If (D)TLS 1.2 is REQUIRED to implement, then does this document not update

those RFCs?

It doesn’t change existing versions of (D)TLS and it is not mandatory to
include this functionality, so I don’t think that it updates them. It’s a
separate and optional feature built on top of TLS. In any case, the text is
changed to make it explicit that this is a minimum requirement.

NITS:

- Sec 1. I think you mean Sec 4.2.6 of RFC 8446, not 4.6.3.

It’s actually neither, it’s 4.6.2. Sec. 4.2.6 defines the extension that
the client uses to advertise support for post-handshake authentication.

- Sec 4 and 5. "use a secure with..." ?

Added “transport”

- Sec 4. s/messages structures/message structures

Fixed




Erik Kline's No Objection

--

COMMENT:

--

[ sections 4 & 5 ]

* "SHOULD use a secure with" ->

  "SHOULD use a secure communications channel with" or

  "SHOULD use a secure transport with" or something?

Fixed in previous change

* "as its as its" -> "as its"

Fixed

[ section 

Re: [TLS] Solving HRR woes in ECH

[Nick Sullivan]

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 be
extended further to advertise to the client what the server is willing to
support for cryptographic negotiations?

For example, the HTTPS record could additionally contain the server's
supported supported_groups and cipher_suites. With this information, a
client could know which key_share extensions a server is likely to accept
and adjust its clienthello accordingly. A client who typically sends two
key_shares (P256 and x25519) for maximal compatibility could then reduce
the size of its client hello (no need to send redundant key_shares) or even
prevent an HRR flow altogether in the case that the default key_shares or
cipher_suites are not supported by the server.

This tweak wouldn't remove the need for HRR completely -- it could be
necessary when changing server configuration, for example -- but it could
remove the need for HRR in the common case.

Nick

On Thu, Mar 25, 2021 at 8:05 PM Christopher Patton  wrote:

> Hi all,
>
> One of the open issues for ECH is how it interacts with HelloRetryRequest
> (HRR). The central difficulty is that a client may advertise different
> preferences for HRR-sensitive parameters in the ClientHelloInner and
> ClientHelloOuter. And because the HRR path has no explicit signal of which
> ClientHello was used, the client may not be able to know how to respond.
> The following PR solves this problem by adding to HRR an explicit signal of
> which ClientHello was used:
> https://github.com/tlswg/draft-ietf-tls-esni/pull/407
>
> The design was originally proposed by David Benjamin in the issue
> referenced by the PR. Along the way, It also solves a handful of other HRR
> issues that have been identified.
>
> One consequence of this particular solution is that real ECH usage "sticks
> out" if the server responds with an HRR. In particular, signaling which
> ClientHello was used also signals whether ECH was accepted. However, the
> solution is designed to mitigate "don't stick out" attacks that attempt to
> trigger the HRR codepath by fiddling with bits on the wire. The
> distinguisher only arises when HRR happens organically.
>
> Feedback is appreciated!
>
> Best,
> Chris P.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] comments on draft-subcerts

[Nick Sullivan]

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 encoding to provide example
>certificates:
>
>  -BEGIN CERTIFICATE-
>
>  -END CERTIFICATE-
>
>
>
>- Others use the output of dumpasn1 from Peter Gutmann.
>
>
>
> If you ask I prefer PEM style, but can live with either.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] comments on draft-subcerts

[Nick Sullivan]

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 extension to model this after.

On Fri, Aug 14, 2020 at 10:00 AM Russ Housley  wrote:

> I have two comments:
>
> 1) The OID assignment for the ASN.1 module was assigned already by IANA.
> Please fill it in.
>
> 2) I think it would be very helpful to have an example of the extension in
> an Appendix.  There was discussion on the list about it, and an error was
> found in the proposed example, which proves the need for an example.
>
> Russ
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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:
https://github.com/tlswg/tls-subcerts/pull/80

On Mon, Jun 29, 2020 at 5:48 PM Daniel Migault  wrote:

> Hi,
>
> The draft has a number of nits and errors. Among others:
>
> The related work section mentions KEYLESS and subcert being complementary
> that is KEYLESS can perform the operations associated to the DC and/or
> those associated to the cert key. I do not think that is correct. KEYLESS
> does not support TLS 1.3 while DC only works with TLS 1.3. The LURK
> extension for TLS 1.3 [draft-mglt-lurk-tls13] should be mentioned instead..
> As LURK was mentioned during the adoption period and until version 05 that
> should not cause any issues.
>
> Technologies only available for TLS 1.2 may be mentioned in the related
> work section.  [draft-mglt-lurk-tls12] should be mentioned similarly to
> KEYLESS as it addresses the security concerns of KEYLESS.
>
> There are other places where the extensions is mentioned together with TLS
> 1.2 that needs to be updated.
>
> I also think that test vectors would be good as well as a link to a formal
> verification publication (if available).
>
> Please see all my comments inline, I hope they help.
>
> Yours,
> Daniel
>
> 
>
>  Delegated Credentials for TLS
>draft-ietf-tls-subcerts-09
>
> [...]
>
> 1.  Introduction
>
>Typically, a TLS server uses a certificate provided by some entity
>other than the operator of the server (a "Certification Authority" or
>CA) [RFC8446] [RFC5280].  This organizational separation makes the
>TLS server operator dependent on the CA for some aspects of its
>operations, for example:
>
>*  Whenever the server operator wants to deploy a new certificate, it
>   has to interact with the CA..
>
>*  The server operator can only use TLS signature schemes for which
>   the CA will issue credentials.
>
>These dependencies cause problems in practice.  Server operators
>often deploy TLS termination services in locations such as remote
>data centers or Content Delivery Networks (CDNs) where it may be
>difficult to detect key compromises..  Short-lived certificates may be
>used to limit the exposure of keys in these cases.
>
> 
> I believe it would be clearer to
> summarize the problem and link it to the
> use case. I would propose something
> around:
>
> These dependencies cause problems in
> practice, the management of key exposure
> necessarily requires an interaction with
> the CA.
>
> Typically server operators
> 
>

I tried to move the sentences around but wasn't able to get something more
satisfactory. It's currently structured as:

Reality of deployment
Problem: dependencies
Flaws in existing solutions
Proposed solution (this)


>
>However, short-lived certificates need to be renewed more frequently
>than long-lived certificates.  If an external CA is unable to issue a
>certificate in time to replace a deployed certificate, the server
>would no longer be able to present a valid certificate to clients.
>With short-lived certificates, there is a smaller window of time to
>renew a certificates and therefore a higher risk that an outage at a
>CA will negatively affect the uptime of the service.
>
>To reduce the dependency on external CAs, this document proposes a
>limited delegation mechanism that allows a TLS peer to issue its own
>credentials within the scope of a certificate issued by an external
>CA.  These credentials only enable the recipient of the delegation to
>speak for names that the CA has authorized.  For clarity, we will
>refer to the certificate issued by the CA as a "certificate", or
>"delegation certificate", and the one issued by the operator as a
>"delegated credential" or "DC".
>
> 
> From the text it is unclear why the
> signature scheme appears to be a
> constraint as well how it does not opens
> to some sort of downgrade attacks if
> left to the operator.
> 
>

The second bullet was left unaddressed, so I added some text here.
Downgrades are not a current concern in TLS 1.3 since weak signature
algorithms have been removed and clients advertise signature algorithm
support and can remove weak algorithms should they arise.

>
>
> 3.  Solution Overview
>
> [...]
>
> 3.1.  Rationale
>
>Delegated credentials present a better alternative than other
>delegation mechanisms like proxy certificates [RFC3820] for several
>reasons:
>
>*  There is no change needed to certificate validation at the PKI
>   layer.
>
>*  X.509 semantics are very rich.  This can cause unintended
>   consequences if a service owner creates a proxy certificate where
>   the properties differ from the 

Re: [TLS] comments on draft-subcerts

[Nick Sullivan]

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 draft, which are:
>
> - On Section 1:
>
> "For clarity, we will refer to the certificate issued by the CA as a
> "certificate", or "delegation certificate", and the one issued by the
> operator as a "delegated credential" or "DC"."
>
> I think this sentence can be their own paragraph, so it does not get
> lost with the rest of the text. It will be good to clarify as well the
> usage of 'credential', 'delegation', 'delegator' terms used through out
> the document. It will be really nice to clarify the term 'credential' as
> it sometimes seems to be used to refer to 'delegated credential', and
> sometimes to the 'Credential' struct.
>
> - On section 7.3
>
> "Delegated credentials do not provide any additional form of early
> revocation. Since it is short lived, the expiry of the delegated
> credential would revoke the credential. Revocation of the long term
> private key that signs the delegated credential also implicitly
> revokes the delegated credential."
>
> Not sure how the implicit revocation will work. It is my understanding
> that the sole way to check that a DC is revoked is by verifying its
> valid time, and this is the way that renders it 'invalid'.
> Maybe, the DC is valid until it expires regardless if the long-term
> private key is revoked, as I don't see a way to mark the DC invalid when
> the long-term private key revokes. But perhaps, I'm understanding this
> incorrectly.
>
> In that case, how the DC signed by a revoked key will be treated? Should
> it wait until they expire to render them completely explicitly invalid?
>
>
> I have other minor editorial changes that I'll send as a PR.
>
> Thanks!
>
>
>
>
>
> --
> Sofía Celi
> @claucece
> http://claucece.github.io/
> Cryptographic research and implementation at many places, but mainly at
> Cloudflare
> FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 supported by a minority of sites.

If ECH is deployed in a client with GREASE enabled, then every client hello
from the supporting client will contain the ECH extension whether the site
supports ECH or not. The traffic from the supporting user agent would stick
out, but simple filters that check for the presence of specific extensions,
would not be able to differentiate between connections to sites with ECH
enabled and to those without ECH.

On Thu, Jul 30, 2020 at 11:18 AM Christian Huitema 
wrote:

>
> On 7/30/2020 8:45 AM, onoketa wrote:
> > Hi,
> >
> > The Great Firewall of China may have identified and blocked
> > Cloudflare's ESNI implementation.
> >
> > I have found that when using a TLS client hello with ESNI extension to
> > connect to servers behind Cloudflare's CDN, the connection will be cut
> > off after the whole TLS handshake is done. And then that IP address
> > will be blocked at the TCP level for several minutes.
>
>
> Thanks for the report. I think this relates to our ambivalence about the
> requirement for ESNI to not "stick out". That requirement is hard to
> meet, and designs have drifted towards an acceptation that it is OK to
> stick out as long as a sufficiently large share of the traffic does it.
> If that share is large, goes the reasoning, it would be too costly for
> censors to just "drop everything that looks like ESNI". Well, given
> actors like the Great Firewall, one wonders.
>
> -- Christian Huitema
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 WGLC:
> https://github.com/tlswg/tls-exported-authenticator/issues/62
> https://github.com/tlswg/tls-exported-authenticator/issues/63
> Once addressed, and assuming the changes are not large, we will progress
> this draft towards our AD.
>
> I will put the draft in Waiting for WG Chair Go-Ahead / Revised I-D needed
> awaiting resolution of the two issues.
>
> spt (for the chairs)
>
> > On Jun 5, 2020, at 07:29, Watson Ladd  wrote:
> >
> > On Thu, Jun 4, 2020 at 9:48 PM Sean Turner  wrote:
> >>
> >> Another reminder ...
> >>
> >>> On May 22, 2020, at 09:23, Sean Turner  wrote:
> >>>
> >>> This is the 3rd WGLC for "Exported Authenticators in TLS" draft
> available at
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.
> The secdir review during IETF LC raised some issues and as a result there
> have been a couple of new versions. Please respond to the list with any
> comments by 2359 UTC on 8 June 2020.
> >
> > I've implemented earlier drafts. I do have a concern with the
> > validate API as presented in the draft: it treats empty authenticators
> > as valid, and then returns the identity as a certificate chain that
> > must be validated by the application. Similar APIs have lead to easily
> > foreseeable pwnage. Instead I would recommend the validate API carry
> > out X509 validation against a trust store or validation function and
> > treat the empty authenticator as invalid. That way someone has to
> > think before not checking the certificate returned.
> >
> > Sincerely,
> > Watson Ladd
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

TLSWG,

We have submitted draft-09 of the Delegated Credentials draft. This draft
incorporates the reviews of -07 from the WGLC process as well as changes
from draft-08 from the list that weren't covered during the WGLC.

Here's a quick summary of the changes:
   draft-09
   *  Fix section bullets in 4.1.3.
   *  Add operational considerations section for clock skew
   *  Add text around using an oracle to forge DCs in the future and
  past
   *  Add text about certificate extension vs EKU
   draft-08
   *  Include details about the impact of signature forgery attacks
   *  Copy edits for readability
   *  Fix section about DC reuse
   *  Incorporate feedback from Jonathan Hammell and Kevin Jacobs on the
  list

Best,
Nick

-- Forwarded message -
From: 
Date: Fri, Jun 26, 2020 at 4:47 PM
Subject: 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 for TLS
Document date:  2020-06-26
Group:  tls
Pages:  18
URL:
https://www.ietf.org/internet-drafts/draft-ietf-tls-subcerts-09.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
Htmlized:   https://tools.ietf.org/html/draft-ietf-tls-subcerts-09
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09

Abstract:
   The organizational separation between the operator of a TLS endpoint
   and the certification authority can create limitations.  For example,
   the lifetime of certificates, how they may be used, and the
   algorithms they support are ultimately determined by the
   certification authority.  This document describes a mechanism by
   which operators may delegate their own credentials for use in TLS,
   without breaking compatibility with peers that do not support this
   specification.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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=40cloudflare@dmarc.ietf.org> wrote:
>
> 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 through now and
> the changes from -07 can be seen here:
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-08.txt
>
> The authors plan on submitting a -09 soon that incorporates the comments
> from this WGLC. We'll post it here with a summary of changes.
>
> Nick
>
> On Mon, Jun 1, 2020 at 5:04 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
>> I reread this and support it.  We are looking at implementation. We’re
>> curious if anyone is working on a standard for server/origin
>> recertification, etc.
>>
>>
>>
>> *From: *Joseph Salowey 
>> *Date: *Monday, June 1, 2020 at 12:53 AM
>> *To: *"t...@ietf..org " 
>> *Subject: *Re: [TLS] Working group last call for
>> draft-ietf-tls-subcerts-07
>>
>>
>>
>> Reminder: the last call expires this week.
>>
>>
>>
>> On Mon, May 18, 2020 at 12:56 PM Joseph Salowey  wrote:
>>
>> This is the Working Group Last Call for "Delegated Credentials for TLS"
>> available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker..ietf.org_doc_draft-2Dietf-2Dtls-2Dsubcerts_=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=NyKKBPMwOfY63SCShlOoUHcCRvhIPlXkAWLXBtU3gxM=yYOYagwIW8vWSI8kkE982kz3_3rhLrquEtRXRiL9DtU=>.
>> Please review the document and respond to the list with any comments by
>> June 2, 2020.
>>
>> Cheers,
>>
>> Chris, Joe & Sean
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 through now and
the changes from -07 can be seen here:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-08.txt

The authors plan on submitting a -09 soon that incorporates the comments
from this WGLC. We'll post it here with a summary of changes.

Nick

On Mon, Jun 1, 2020 at 5:04 AM Salz, Rich 
wrote:

> I reread this and support it.  We are looking at implementation. We’re
> curious if anyone is working on a standard for server/origin
> recertification, etc.
>
>
>
> *From: *Joseph Salowey 
> *Date: *Monday, June 1, 2020 at 12:53 AM
> *To: *"tls@ietf.org" 
> *Subject: *Re: [TLS] Working group last call for
> draft-ietf-tls-subcerts-07
>
>
>
> Reminder: the last call expires this week.
>
>
>
> On Mon, May 18, 2020 at 12:56 PM Joseph Salowey  wrote:
>
> This is the Working Group Last Call for "Delegated Credentials for TLS"
> available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
> .
> Please review the document and respond to the list with any comments by
> June 2, 2020.
>
> Cheers,
>
> Chris, Joe & Sean
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encoding of delegated credential distribution

[Nick Sullivan]

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 think we should be prescriptive. I'll clarify this in the
next draft.

Nick

On Wed, Apr 1, 2020 at 11:13 PM Paul Yang  wrote:

> Hi all,
>
> When reading the latest draft of delegated credentials, I didn’t any
> description about how to distribute a credential from the backend to
> frontend. As described in the draft:
>
>Delegated credentials:
>
>ClientFront-End Back-End
>  ||<--DC distribution->|
>  |ClientHello--->|   |
>  |<---ServerHello| |
>  |<---Certificate||
>  |<---CertVerify-|   |
>  |... |   |
>
> Do we need to define some sorts of encoding schemes for the  distribution> part?
>
> Regards,
>
> Paul Yang
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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
>
> Section 3, Fourth bullet: To eliminate possible confusion, what is
> meant by "certificate’s working key" could be defined more precisely.
>
> Section 3.2, Last paragraph: s/Automated Certificate Managmeent
> Encvironment/Automated Certificate Management Environment
>
> Section 3.2, Last paragraph: "It is possible to address the
> short-lived certificate concerns above ..." seems to refer to text in
> the Introduction.  It is a bit far for use of "above" rather than
> indicating the particular section.  Even better would be to add some
> text regarding the concerns to Section 3 or 3.1.
>
> Section 4: The definition of "valid_time" could mention that the value
> must not exceed 7 days.
>
> Section 4: The phrase
> "Minimizing their semantics in this way is intended to mitigate the
> risk of cross protocol attacks involving delegated credentials."
> could be improved by adding at least one way that the minimized
> semantics mitigate such attacks.
>
> Section 6.1: The term "TLS private key" is used for the first time
> here. In the rest of the document we see the term "delegated private
> key"; are these the same?
>
> Section 6.1: The following phrase describes an important condition for
> using delegated credentials:
> "Thus, delegated credentials should not be used to send a delegation
> to an untrusted party, but is meant to be used between parties that
> have some trust relationship with each other."
> I think it is important enough to include a similar statement when
> describing the solution in Section 3.
>
> Section 6.4: s/cache the certificate chain an re-validate it/cache the
> certificate chain and re-validate it
>
>
> Best regards,
> Jonathan
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 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 determine whether a server
> used
> > >  the inner
> > >  or outer ClientHello for a given connection. It's also trivial to
> probe
> > >  for ECHO
> > >  support, e.g., by sending a bogus ECHO with the same key ID used in a
> > >  target client
> > >  connection and checking what comes back.
> >
> > Do you mean that it’s trivial for an attacker to probe a server for
> > ECHO support or whether it’s trivial to check if a given connection
> > used ECHO or not?
>
> In the current design: both.
>
> > In the current draft it seems trivial to identify servers that support
> > ECHO by:
> > - querying DNS and seeing whether the record exists
> > - connecting to the server with an ECHO extension that has a random key
> > ID and ECHO ciphertext and checking if the server returns “retry_keys”
> > (yes means ECHO support)
> >
> > Both of these can be done without observing a specific connection.
>
> Agreed. I think we should assume that attackers know which servers support
> ECHO and which do not.
>
> > If we’re talking about “don’t stand out,” would it be fair to consider
> > the attack you hinted at above as an active attack to identifies
> > whether a given connection used ECHO or not (3b in Ben’s email)? If so,
> > it points to a weakness in the current protocol description that could
> > be remedied.
>
> It's definitely an active attack. I don't disagree that it's possible to
> fix. What I am concerned with is the cost of fixing it.
>
> > Here are three scenarios:
> >
> > Client connects to confirmed ECHO-enabled server with valid key:
> > 1) client connects to server using an ECHO extension created with a
> > valid key ID and a valid ciphertext for that ID
> > 2) server responds with handshake encrypted using the inner CH
> >
> > Client connects to confirmed non-ECHO-enabled server with GREASE:
> > 1) client connects to server using an ECHO extension with a random
> > invalid key ID, and an invalid ciphertext
> > 2) server responds with handshake encrypted using the outer CH, no
> > retry_keys
> >
> > Client connects to ECHO-enabled server with GREASE (say DNS was
> > blocked):
> > 1) client connects to server using an ECHO extension with a random
> > invalid key ID, and an invalid ciphertext
> > 2) server responds with handshake encrypted using the inner CH, sends
> > default cert and retry_keys
> >
> >
> > For these scenarios, the attacker collects the handshakes and key IDs,
> > and wants to determine which is which. The attacker then probes the
> > servers with three connections:
> >
> > A. client connects to ECHO-enabled server using an ECHO extension with
> > a valid key ID (taken from a connection), and an invalid ciphertext
> >
> > The server will match the key ID and return “decryption_error” when the
> > ECHO ciphertext fails to decrypt.
> >
> > B. client connects to ECHO-enabled server using an ECHO extension with
> > an invalid key ID (taken from a GREASE connection), and an invalid
> > ciphertext
> >
> > The server will respond with handshake encrypted using the outer CH,
> > including retry_keys.
> >
> > C. client connects to non-ECHO-enabled server using an ECHO extension
> > with a the invalid key ID (taken from a GREASE connection), and an
> > invalid ciphertext
> >
> > The server will respond with handshake encrypted using the outer CH.
> >
> >
> > All three are distinguishable. This lets the attacker know whether a
> > given connection actually used ECHO (outer handshake) or GREASE for an
> > ECHO -enabled site. This shows that we don’t currently have property 3a
> > from Ben’s reply.
> >
> > A simple way to eliminate this oracle would be for the server to treat
> > ECHOs that have valid IDs but are corrupted or don’t match the outer CH
> > differently: treat them as GREASE handshakes and respond using the
> > outer CH and retry_keys. This would make the results from A and B
> > i

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

[Nick Sullivan]

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 determine whether a server used
> the inner
> or outer ClientHello for a given connection. It's also trivial to probe
> for ECHO
> support, e.g., by sending a bogus ECHO with the same key ID used in a
> target client
> connection and checking what comes back.


Do you mean that it’s trivial for an attacker to probe a server for ECHO
support or whether it’s trivial to check if a given connection used ECHO or
not?

In the current draft it seems trivial to identify servers that support ECHO
by:
- querying DNS and seeing whether the record exists
- connecting to the server with an ECHO extension that has a random key ID
and ECHO ciphertext and checking if the server returns “retry_keys” (yes
means ECHO support)

Both of these can be done without observing a specific connection.


If we’re talking about “don’t stand out,” would it be fair to consider the
attack you hinted at above as an active attack to identifies whether a
given connection used ECHO or not (3b in Ben’s email)? If so, it points to
a weakness in the current protocol description that could be remedied.


Here are three scenarios:

Client connects to confirmed ECHO-enabled server with valid key:
1) client connects to server using an ECHO extension created with a valid
key ID and a valid ciphertext for that ID
2) server responds with handshake encrypted using the inner CH

Client connects to confirmed non-ECHO-enabled server with GREASE:
1) client connects to server using an ECHO extension with a random invalid
key ID, and an invalid ciphertext
2) server responds with handshake encrypted using the outer CH, no
retry_keys

Client connects to ECHO-enabled server with GREASE (say DNS was blocked):
1) client connects to server using an ECHO extension with a random invalid
key ID, and an invalid ciphertext
2) server responds with handshake encrypted using the inner CH, sends
default cert and retry_keys


For these scenarios, the attacker collects the handshakes and key IDs, and
wants to determine which is which. The attacker then probes the servers
with three connections:

A. client connects to ECHO-enabled server using an ECHO extension with a
valid key ID (taken from a connection), and an invalid ciphertext

The server will match the key ID and return “decryption_error” when the
ECHO ciphertext fails to decrypt.

B. client connects to ECHO-enabled server using an ECHO extension with an
invalid key ID (taken from a GREASE connection), and an invalid ciphertext

The server will respond with handshake encrypted using the outer CH,
including retry_keys.

C. client connects to non-ECHO-enabled server using an ECHO extension with
a the invalid key ID (taken from a GREASE connection), and an invalid
ciphertext

The server will respond with handshake encrypted using the outer CH.


All three are distinguishable. This lets the attacker know whether a given
connection actually used ECHO (outer handshake) or GREASE for an ECHO
-enabled site. This shows that we don’t currently have property 3a from
Ben’s reply.

A simple way to eliminate this oracle would be for the server to treat
ECHOs that have valid IDs but are corrupted or don’t match the outer CH
differently: treat them as GREASE handshakes and respond using the outer CH
and retry_keys. This would make the results from A and B indistinguishable.

Given this modification, is there still an active attack to determine if a
specific connection used the outer or inner CH?

Does David Benjamin’s cut-and-paste attack still work if the cipher list in
the inner client hello is just a pointer to the cipher list in the outer
client hello?


>
> I propose we remove this requirement and add an explicit signal in SH
> that says
> whether or not ECHO was negotiated. (This will require us to revisit
> GREASE.)


A downside of this modification is that ECHO is no longer able to be used
by existing TLS 1.3 servers without modification.

One of the neat features of ECHO is that a a server-controlled proxy that
only has access to ESNI keys can determinate which client hello to use
(inner vs. outer). This allows a shim proxy to decrypt ECHO (or fail to)
and send a singular CH on to the real server running unmodified TLS 1.3
software. This modularity opens up a massive opportunity for the large TCP
load balancing providers out there with a lot of IP space to enable ECHO
for legacy applications without needing access to their private key. Having
a signaling extension in the handshake eliminates this deployment scenario
(one that CF is currently exploring).

Of course, without modifying the server, ECHO is less effective since it
won’t be possible to apply padding to the server’s portion of the
handshake. However, being able to deploy ECHO 

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

[Nick Sullivan]

Hi Nimrod,

This is a working group document, so it's open to comments and suggestions
from anyone in the IETF community. Feel free to send a PR
https://github.com/tlswg/tls-subcerts and we can discuss on-list.

Nick

On Fri, Mar 20, 2020 at 11:12 AM Nimrod Aviram 
wrote:

> Hi Nick,
>
> 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  wrote:
>
>>
>>
>> On Fri, Mar 20, 2020 at 9:23 AM Nimrod Aviram 
>> wrote:
>>
>>> Hi Nick,
>>>
>>> Thank you for the detailed response!
>>>
>>> In light of your explanation, we are curious why high-profile servers
>>> using Delegated Credentials need to support TLS-RSA? Most of the relevant
>>> clients (or all of them?) support ephemeral key exchange in TLS. So would
>>> it be possible to improve the state-of-the-art by forbidding TLS-RSA and
>>> demanding correct keyUsage, at least in such high-profile scenarios?
>>>
>>
>> This doesn't stop the attack, it just reduces the probability that a new
>> oracle will be exploitable in servers that implement DCs. If the oracle
>> exists in existing legacy servers where the cert is used, it doesn't matter
>> what DC-enabled servers do. Removing support for TLS-RSA in TLS 1.2 is a
>> valid TLS policy choice for today's age, but enforcing it in the protocol
>> document doesn't improve the security versus known attacks like DROWN.
>> Requiring EC keys for DC-enabled certificates is also an artificial
>> limitation that should be avoided -- not all CAs support EC certs and not
>> all software supports EC code.
>>
>> What you really want is to prevent keys from being used across different
>> contexts. I see two options for this:
>>
>> 1) Add strong wording in the security considerations section about how it
>> is dangerous to use the same key in different contexts. Advise implementers
>> to use DC-enabled certificates only for signing DCs, not for terminating
>> TLS or SSL -- if their software allows it.
>> 2) Enforce on the client-side that DC-enabled certificates can only be
>> used for DC handshakes. This option prevents DC certificates from being
>> used in an DC-capable server by DC-enabled clients, but it doesn't prevent
>> the certificate from being deployed on legacy services exposing an oracle.
>> The downside of this restriction is that it adds complexity for server
>> implementations (need the ability to load certificates dynamically based on
>> client hello), and operators (two certificates need to be managed per
>> service, not just one).
>>
>> My preference is for 1)
>>
>>
>>> Assuming this is not possible, we agree with your conclusion. It looks
>>> like the second alternative is more effective - to discourage the use
>>> of DC-enabled certificates in contexts where an oracle may be present.
>>> One possible defense-in-depth is to use DC only with EC certificates.
>>>
>>> best wishes,
>>> 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 <
>>> juraj.somorov...@upb.de>
>>>
>>>
>>> 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 1 (requiring the keyEncipherment KeyUsage to not
>>> be present on DC-capable certificates) is sound in theory, but unlikely to
>>> be effective in practice since many servers (including many of the ones
>>> identified in DROWN) ignore the requirement that keyEncipherment
>>> KeyUsage is present. Stating this requirement in the text of this document
>>> is unlikely to prevent existing oracles from being leveraged if the
>>> certificate is used in multiple contexts and is likely to introduce
>>> complexity on the CA side, so I'm inclined not to include this requirement.
>>> I'd be happy to hear an argument to the contrary, thou

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

[Nick Sullivan]

On Fri, Mar 20, 2020 at 9:23 AM Nimrod Aviram 
wrote:

> Hi Nick,
>
> Thank you for the detailed response!
>
> In light of your explanation, we are curious why high-profile servers
> using Delegated Credentials need to support TLS-RSA? Most of the relevant
> clients (or all of them?) support ephemeral key exchange in TLS. So would
> it be possible to improve the state-of-the-art by forbidding TLS-RSA and
> demanding correct keyUsage, at least in such high-profile scenarios?
>

This doesn't stop the attack, it just reduces the probability that a new
oracle will be exploitable in servers that implement DCs. If the oracle
exists in existing legacy servers where the cert is used, it doesn't matter
what DC-enabled servers do. Removing support for TLS-RSA in TLS 1.2 is a
valid TLS policy choice for today's age, but enforcing it in the protocol
document doesn't improve the security versus known attacks like DROWN.
Requiring EC keys for DC-enabled certificates is also an artificial
limitation that should be avoided -- not all CAs support EC certs and not
all software supports EC code.

What you really want is to prevent keys from being used across different
contexts. I see two options for this:

1) Add strong wording in the security considerations section about how it
is dangerous to use the same key in different contexts. Advise implementers
to use DC-enabled certificates only for signing DCs, not for terminating
TLS or SSL -- if their software allows it.
2) Enforce on the client-side that DC-enabled certificates can only be used
for DC handshakes. This option prevents DC certificates from being used in
an DC-capable server by DC-enabled clients, but it doesn't prevent the
certificate from being deployed on legacy services exposing an oracle. The
downside of this restriction is that it adds complexity for server
implementations (need the ability to load certificates dynamically based on
client hello), and operators (two certificates need to be managed per
service, not just one).

My preference is for 1)


> Assuming this is not possible, we agree with your conclusion. It looks
> like the second alternative is more effective - to discourage the use of
> DC-enabled certificates in contexts where an oracle may be present. One
> possible defense-in-depth is to use DC only with EC certificates.
>
> best wishes,
> 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 <
> juraj.somorov...@upb.de>
>
>
> 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 1 (requiring the keyEncipherment KeyUsage to not be
> present on DC-capable certificates) is sound in theory, but unlikely to be
> effective in practice since many servers (including many of the ones
> identified in DROWN) ignore the requirement that keyEncipherment KeyUsage
> is present. Stating this requirement in the text of this document is
> unlikely to prevent existing oracles from being leveraged if the
> certificate is used in multiple contexts and is likely to introduce
> complexity on the CA side, so I'm inclined not to include this requirement.
> I'd be happy to hear an argument to the contrary, though.
>
> I'm more inclined to incorporate some text into the security
> considerations to discourage the use of DC-enabled certificates in
> contexts where an oracle may be present. Servers may even go as far as to
> use a different certificate for DC-enabled handshakes vs regular handshakes
> --- although very few servers support this sort of dynamic certificate
> switching in practice so it would be difficult to make a hard requirement
> here.
>
> Nick
>
> On Thu, Mar 19, 2020 at 6:08 AM Nimrod Aviram 
> wrote:
>
>> Hi folks,
>>
>> We're writing to ask (and share some concerns) about the potential impact
>> of a Bleichenbacher attack when delegated credentials are in use.
>>
>> This issue is already discussed in the standard:
>> In Section 3:
>> ```   It was noted in [XPROT] that certificates in use by servers that
>>support outdated protocols such as SSLv2 can be used to forge
>>signatures for certificates that contain the keyEncipherment KeyUsage
>>([RFC5280] section 4.2.1.3).  In order to prevent this type of cross-
>>protocol attack, we define a new DelegationUsage extension to X.509
>>that permits use of deleg

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

[Nick Sullivan]

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 1 (requiring the keyEncipherment KeyUsage to not be
present on DC-capable certificates) is sound in theory, but unlikely to be
effective in practice since many servers (including many of the ones
identified in DROWN) ignore the requirement that keyEncipherment KeyUsage
is present. Stating this requirement in the text of this document is
unlikely to prevent existing oracles from being leveraged if the
certificate is used in multiple contexts and is likely to introduce
complexity on the CA side, so I'm inclined not to include this requirement.
I'd be happy to hear an argument to the contrary, though.

I'm more inclined to incorporate some text into the security considerations
to discourage the use of DC-enabled certificates in contexts where an
oracle may be present. Servers may even go as far as to use a different
certificate for DC-enabled handshakes vs regular handshakes --- although
very few servers support this sort of dynamic certificate switching in
practice so it would be difficult to make a hard requirement here.

Nick

On Thu, Mar 19, 2020 at 6:08 AM Nimrod Aviram 
wrote:

> Hi folks,
>
> We're writing to ask (and share some concerns) about the potential impact
> of a Bleichenbacher attack when delegated credentials are in use.
>
> This issue is already discussed in the standard:
> In Section 3:
> ```   It was noted in [XPROT] that certificates in use by servers that
>support outdated protocols such as SSLv2 can be used to forge
>signatures for certificates that contain the keyEncipherment KeyUsage
>([RFC5280] section 4.2.1.3).  In order to prevent this type of cross-
>protocol attack, we define a new DelegationUsage extension to X.509
>that permits use of delegated credentials.  (See Section 4.2.)
> ```
>
> And Section 4.2:
> ```   The client MUST NOT accept a delegated credential unless
>the server's end-entity certificate satisfies the following criteria:
>
>*  It has the DelegationUsage extension.
>
>*  It has the digitalSignature KeyUsage (see the KeyUsage extension
>   defined in [RFC5280]).
> ```
>
> Currently, it seems the standard does not discuss the common situation
> where the certificate has both the digitalSignature and keyEncipherment
> KeyUsages.
> If we understand correctly, for such certificates using Bleichenbacher's
> attack to forge a single signature once over a delegated credential,
> would grant an attacker the equivalent of a man-in-the-middle certificate.
> Section 3 mentions SSLv2, and this protocol indeed enabled a severe form
> of Bleichenbacher's attack, but these attacks are not limited to older
> protocol versions.
> There have been implementations of TLS 1.2 vulnerable to Bleichenbacher's
> attack, even by server operators as competent as Facebook, as discussed
> e..g. in the ROBOT paper.
>
> Also, coming back to SSLv2, one problem at the time was that the
> recommended way to disable SSLv2 in OpenSSL did not in fact disable
> SSLv2. Administrators who followed the guidelines falsely assumed they
> had disabled the protocol, but had no way to verify it was disabled. It
> would be prudent to assume this may happen again, e.g. administrators will
> be unaware that they have obsolete or vulnerable cryptography enabled.
>
> In light of the above, we would recommend one of two alternatives:
> 1. Change the text in Section 4.2 to say "[the certificate] has the
> digitalSignature KeyUsage, and does not have the keyEncipherment KeyUsage.
> Furthermore, the certificate does not share its public key with any
> certificate that has the keyEncipherment KeyUsage."
> - or -
> 2. Add text in the Security Considerations Section explaining that:
> 2.1. The recommended way for server operators to defend in depth against
> this type of attack is to use a certificate as in alternative 1 with
> delegated credentials.
> 2.2. Absent that, server operators should be aware of this risk.
>
> We would be happy to continue the discussion and help in any way.
>
> best wishes,
> Juraj, Robert and Nimrod
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 wrote:
> > Ilari,
> >
> > Thank you for identifying these errors in the document. There was no
> > intention to allow the client to constrict the server certificate's
> > algorithm with the delegated_credential extension, and no intention to
> > restrict the delegated credential's algorithm with the
> > signature_algorithms. Let me propose some minor text changes to address
> the
> > issues.
> >
> > As a reminder, the CertificateVerify.algorithm is constrained by the
> > signature_algorithms
> > extension, as stated in RFC 8446:
> >
> >If the CertificateVerify message is sent by a server, the signature
> >algorithm MUST be one offered in the client's "signature_algorithms"
> >extension unless no valid certificate chain can be produced without
> >unsupported algorithms (see Section 4.2.3
> > <https://tools.ietf.org/html/rfc8446#section-4.2.3>).
> >
> >
> >
> > Original text from 4.1.2.:
> >
> >The expected_cert_verify_algorithm fields MUST be of a
> >type advertised by the client in the SignatureSchemeList and are
> >considered invalid otherwise.  Clients that receive invalid delegated
> >credentials MUST terminate the connection with an "illegal_parameter"
> >alert.
> >
> >
> > proposed text:
> >
> >The expected_cert_verify_algorithm field MUST be of a
> >type advertised by the client in the SignatureSchemeList and is
> >considered invalid otherwise.  Clients that receive invalid delegated
> >credentials MUST terminate the connection with an "illegal_parameter"
> >alert.
>
> The section number looks incorrect (it is about client authentication)
> and the original looks to be copied from the new text. Did you mean
> section 4.1.1 (Server authentication) and:
>
> OLD:
>
>The algorithm and expected_cert_verify_algorithm fields MUST be of a
>type advertised by the client in the SignatureSchemeList and are
>considered invalid otherwise.  Clients that receive invalid delegated
>credentials MUST terminate the connection with an "illegal_parameter"
>alert.
>
> NEW:
>
>The expected_cert_verify_algorithm field MUST be of a
>type advertised by the client in the SignatureSchemeList and is
>considered invalid otherwise.  Clients that receive invalid delegated
>credentials MUST terminate the connection with an "illegal_parameter"
>alert.
>
> Yes, 4.1.1. I'll put this into a PR.

>
> > As for the second point, we did not add the capability for the server to
> > advertise a different set of signature_algorithms for client
> authentication
> > other than the one advertised via the "signature_algorithms" extension.
> > This was perhaps an oversight. I propose that we add that capability and
> > I'd be happy to propose a PR to that effect.
> >
> > The new text of 4.3.2. would look something like:
> >
> >A server which supports this specification SHALL send an
> >"delegated_credential" extension in the CertificateRequest message
> >when requesting client authentication.  The body of the
> >extension consists of a SignatureSchemeList.  If the server receives a
> >delegated credential without indicating support in its
> >CertificateRequest, then the server MUST abort with an
> >"unexpected_message" alert.
> >
> > ...
> >
> >The algorithm field MUST be of a
> >type advertised by the server in the "signature_algorithms" extension
> >of the CertificateRequest message and the
> expected_cert_verify_algorithm
> >field MUST be of a type advertised by the client in the
> SignatureSchemeList
> >and considered invalid otherwise.  Clients that receive invalid
> >delegated credentials MUST terminate the connection with an
> >"illegal_parameter" alert.
> >
>
> There seems to be no section 4.3.2 (or 4.3 for that matter). Did you mean
> section 4.1.2 (Client authentication)?


Yes, 4.1.2 is the right section.

>

The latter proposed paragraph
> seems like it says "client" in two places it should say  "server", did you
> mean:
>
>The algorithm field MUST be of a
>type advertised by the server in the "signature_algorithms" extension
>of the CertificateRequest message and the expected_cert_verify_algorithm
>field MUST be of a type advertised by the server in the
> SignatureSchemeList
>and considered invalid otherwise.  Servers that receive invalid
>delegated credentials MUST terminate the connection with an
>"illegal_parameter" alert.
>

Yes, that's correct.

>
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

Carrick,

Thank you for reading the document and identifying an embarrassingly
difficult to parse motivating paragraph (with an annoying unclosed
parenthesis to boot). You've correctly identified the meaning it was trying
to convey and we'll happily review this as a PR here:
https://github.com/tlswg/tls-subcerts/. I've noticed a few other
readability issues in the document, if you find anything else, we'll
happily look at those too.

Nick

On Thu, Feb 13, 2020 at 3:46 PM Carrick Bartle  wrote:

> TL;DR: I find it difficult to understand the second-to-last paragraph of
> the Introduction, so I took a stab at revising it. Let me know if I should
> put it in a pull request.
>
>
> This is the paragraph I'm referring to:
>
> "These dependencies cause problems in practice. Server operators often
> want to create short-lived certificates for servers in low- trust zones
> such as Content Delivery Network (CDNs) or remote data centers. This allows
> server operators to limit the exposure of keys in cases that they do not
> realize a compromise has occurred. The risk inherent in
> cross-organizational transactions makes it operationally infeasible to rely
> on an external CA for such short- lived credentials. In Online Certificate
> Status Protocol (OCSP) stapling (i.e., using the Certificate Status
> extension type ocsp [RFC8446], if an operator chooses to talk frequently to
> the CA to obtain stapled responses, then failure to fetch an OCSP stapled
> response results only in degraded performance. On the other hand, failure
> to fetch a potentially large number of short lived certificates would
> result in the service not being available, which creates greater
> operational risk."
>
> Here are my issues with it:
>
> - I think OCSP is being brought up here as an example of a way that
> dependence on a CA can go wrong, but that isn't really made explicit.
>
> - I'm not sure what "only" means in "only in degraded performance." Is it
> "the worst that can happen is just degraded performance" or "it can result
> only in degraded performance, as opposed to better performance"? At first I
> thought it was the latter, but after reading the subsequent sentence, I
> realized it was probably the former.
>
> - The use of "On the other hand" sounds like the rest of the sentence is
> going to describe a way that failure to receive something from a CA
> resulted in better performance, which obviously would be silly.
>
> Taking all these points together, here's my suggestion for a revision to
> make what I think the thrust of the paragraph is more clear:
>
> "These dependencies cause problems in practice. Server operators often
> want to create short-lived certificates for servers in low-trust zones such
> as Content Delivery Network (CDNs) or remote data centers. This allows
> server operators to limit the exposure of keys in cases where they do not
> realize a compromise has occurred. But the risk inherent in
> cross-organizational transactions makes it operationally infeasible to rely
> on an external CA for such short-lived credentials. For instance, in the
> case of Online Certificate Status Protocol (OCSP) stapling (i.e., using the
> Certificate Status extension type ocsp [RFC8446]), a CA may fail to deliver
> OCSP stapled response. While this will result in degraded performance, the
> ramifications of failing to deliver short-lived certificates is even worse:
> the service that depends on those certificates would go down entirely.
> Thus, ensuring independence from CAs for short-lived certificates is
> critical to the uptime of a service."
>
>
> Carrick
>
>
>
> > On Feb 5, 2020, at 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 Credentials for TLS
> >Authors : Richard Barnes
> >  Subodh Iyengar
> >  Nick Sullivan
> >  Eric Rescorla
> >   Filename: draft-ietf-tls-subcerts-06.txt
> >   Pages   : 15
> >   Date: 2020-02-05
> >
> > Abstract:
> >   The organizational separation between the operator of a TLS endpoint
> >   and the certification authority can create limitations.  For example,
> >   the lifetime of certificates, how they may be used, and the
> >   algorithms they support are ultimately determined by the
> >   certification authority.  This document describes a mechanism by
> >   which operators may deleg

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

[Nick Sullivan]

Ilari,

Thank you for identifying these errors in the document. There was no
intention to allow the client to constrict the server certificate's
algorithm with the delegated_credential extension, and no intention to
restrict the delegated credential's algorithm with the
signature_algorithms. Let me propose some minor text changes to address the
issues.

As a reminder, the CertificateVerify.algorithm is constrained by the
signature_algorithms
extension, as stated in RFC 8446:

   If the CertificateVerify message is sent by a server, the signature
   algorithm MUST be one offered in the client's "signature_algorithms"
   extension unless no valid certificate chain can be produced without
   unsupported algorithms (see Section 4.2.3
<https://tools.ietf.org/html/rfc8446#section-4.2.3>).



Original text from 4.1.2.:

   The expected_cert_verify_algorithm fields MUST be of a
   type advertised by the client in the SignatureSchemeList and are
   considered invalid otherwise.  Clients that receive invalid delegated
   credentials MUST terminate the connection with an "illegal_parameter"
   alert.


proposed text:

   The expected_cert_verify_algorithm field MUST be of a

   type advertised by the client in the SignatureSchemeList and is

   considered invalid otherwise.  Clients that receive invalid delegated

   credentials MUST terminate the connection with an "illegal_parameter"

   alert.


As for the second point, we did not add the capability for the server to
advertise a different set of signature_algorithms for client authentication
other than the one advertised via the "signature_algorithms" extension.
This was perhaps an oversight. I propose that we add that capability and
I'd be happy to propose a PR to that effect.

The new text of 4.3.2. would look something like:

   A server which supports this specification SHALL send an
   "delegated_credential" extension in the CertificateRequest message
   when requesting client authentication.  The body of the

   extension consists of a SignatureSchemeList.  If the server receives a
   delegated credential without indicating support in its
   CertificateRequest, then the server MUST abort with an
   "unexpected_message" alert.



   The algorithm field MUST be of a
   type advertised by the server in the "signature_algorithms" extension

   of the CertificateRequest message and the expected_cert_verify_algorithm

   field MUST be of a type advertised by the client in the SignatureSchemeList

   and considered invalid otherwise.  Clients that receive invalid
   delegated credentials MUST terminate the connection with an
   "illegal_parameter" alert.





Nick



On Mon, Feb 10, 2020 at 7:59 AM Ilari Liusvaara 
wrote:

> On Wed, Feb 05, 2020 at 12:36:52PM -0800, 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 Credentials for TLS
> >     Authors : Richard Barnes
> >   Subodh Iyengar
> >   Nick Sullivan
> >   Eric Rescorla
> >   Filename: draft-ietf-tls-subcerts-06.txt
> >   Pages   : 15
> >   Date: 2020-02-05
>
> I noticed the following:
>
> > The algorithm and expected_cert_verify_algorithm fields MUST be of a
> > type advertised by the client in the SignatureSchemeList and are
> > considered invalid otherwise.  Clients that receive invalid delegated
> > credentials MUST terminate the connection with an "illegal_parameter"
> > alert.
>
> This can be interpretted that the delegated_credentials extension
> constrains the end-entity certificate algorithm if DC is sent. This has
> seemingly undesirable consequences if the list diverges from what the
> signature_algorithms contains:
>
> 1) If delegated_credentials contains algorithm that signature_algorithms
> does not, the server may use that as DC signing algorithm, which will
> cause PKIX code to blow up.
>
> 2) If delgated_credentials is missing some algorithm that
> signature_algorithms contains, the client needs to constrain the PKIX
> validation further.
>
> These issues are made worse by the fact that delegated credential
> validation code is seemingly intended to be separate from PKIX validation
> code, meaning the two can diverge from one another (which is a reason
> for having separate lists).
>
> Looking at the steps to validate the delegated credential, there is
> no explicit step to validate signing algorithm, which would imply that
> the signing algorithm is constrained by the PKIX code, which would

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

[Nick Sullivan]

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 list by 2359 UTC 28
> February 2020.  Please include any additional information that is helpful
> in understanding your position.
>
> NOTE:
> If the draft is adopted, the working group has change control over the
> draft and the timing of its progression.  This means the document does not
> have to be perfect as the working group can and will make changes.
> Adopting the draft means the working group thinks the topic is a good idea
> and the draft is a good place to start the work.
>
> Thanks,
> Chris, Joe, and Sean
>
> [0] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ESNI Android Implementation

[Nick Sullivan]

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 different from the
existing published version, so you likely won't be able to re-use much
code. If it's possible for your schedule I recommend waiting or exploring
questions like how applications with different TLS stacks can get access to
ESNI records if they're fetched system-wide.

Nick

On Tue, Jan 21, 2020 at 12:30 AM Justice Parham 
wrote:

> Hello tlsWG,
>
> First I would like to introduce myself to you. My name is Justice Parham
> (github mrsylerpowers) a current Senior Undergraduate Student at North
> Carolina A State University. As my senior project I decided to create a
> android system wide implementation of the ESNI Draft. I am planning on
> implementing draft-ietf-tls-esni-02 because this is the version that
> cloudflare currently has published on their servers. I am planning on
> upgrading to newer versions of ESNI as more implementations come out on the
> server side
>
> My question to everyone is if creating this implementation will hurt or
> help this document? I would really like for this to be a standard that is
> used everywhere in every browser and in every computer. But I understand 
> draft-ietf-tls-sni-encryption
> 3.4
> 's
> importance about not sticking out. Is there a time where vendors all plan
> to implement or do you think this is a perfect time to create this?
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 signature algorithms in leaf certificates.
>
> Is the intent with supporting an empty extension to support backward
> compatibility?  I think that deployed implementations can probably just
> change to use the list so that we don't have to include this additional
> flexibility.  I'd prefer to always have a list.
>

Even simpler. Once we have a pre-allocated codepoint, the can be released
without conflict with deployed code.

>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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, draft-sullivan-tls-opaque-00
 defines a new
extension that is valid in CH and ClientCertificateRequest, but is not
valid in CR. Does it make sense to require future extensions that can be
used in ClientCertificateRequest to include a new tag, "CCR", in the IANA
TLS ExtensionType Value table

?

In any case, we can address that when/if we get to it. Here's the new
proposed text:
https://github.com/tlswg/tls-exported-authenticator/pull/55/files
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] More flexible signature_algorithm selection for Delegated Credentials

[Nick Sullivan]

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 welcome!
Nick
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Maximum lifetime for Delegated Credentials

[Nick Sullivan]

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.

Here's the PR:
https://github.com/tlswg/tls-subcerts/pull/45

Comments welcome,
Nick
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 options:
> >
> > a) Change the document to UPDATE RFC 8446
> > This feels like a heavyweight option and may complicate things since it
> > will mean that SNI is allowed but undefined for CertificateVerify in the
> > TLS handshake.
> >
> > b) Ask for a new extension point for SNI sent in a client-generated
> > authenticator request.
> > This has the downside of not scaling to future client hello extensions
> that
> > could be useful in exported authenticator requests -- it forces the
> > definition of a new code point for each new extension.
> >
> > c) Explicitly state that the CertificateRequest-like construction in
> > client-generated exported authenticator requests is a new type of message
> > (analogous to a ClientHello) and clarify the rules about which extensions
> > can be used when it is client-generated (specifically, say that any
> > extension supported in CH is allowed)
> > This is my preferred solution.
>
> Just to check: this would be adding a new possible value for the "TLS 1.3"
> column at
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1
> ?
>
Not necessarily. The text could be amended to say something like:
  "the allowed extensions for client-generated authenticator requests need
to have CH listed, and for server-generated authenticator requests need to
have CR listed"

The only current extension that supports CR, but not CH is oid_filters,
which is not relevant to client-initiated authenticator requests.


> Thanks,
>
> Ben
>
> > I'm interested to hear what the working group thinks, and I'll happily
> > present the options at IETF 106 if there's time.
> >
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

Hi Yaron,

Thanks for reminding me about the codepoint issue. It's a sticky one.

As far as I see it, there are three options:

a) Change the document to UPDATE RFC 8446
This feels like a heavyweight option and may complicate things since it
will mean that SNI is allowed but undefined for CertificateVerify in the
TLS handshake.

b) Ask for a new extension point for SNI sent in a client-generated
authenticator request.
This has the downside of not scaling to future client hello extensions that
could be useful in exported authenticator requests -- it forces the
definition of a new code point for each new extension.

c) Explicitly state that the CertificateRequest-like construction in
client-generated exported authenticator requests is a new type of message
(analogous to a ClientHello) and clarify the rules about which extensions
can be used when it is client-generated (specifically, say that any
extension supported in CH is allowed)
This is my preferred solution.

I'm interested to hear what the working group thinks, and I'll happily
present the options at IETF 106 if there's time.

Best,
Nick

On Mon, Nov 4, 2019 at 6:20 PM Yaron Sheffer  wrote:

> Hi Nick,
>
>
>
> Apologies for not responding on time.
>
>
>
> I may be missing some follow-on discussions, but:
>
>
>
>- Ben suggested that we mention that QUIC is also an option, even if
>informatively, in addition to the “SHOULD use TLS” statement.
>- I think we left my question re: back-fitting this protocol into the
>IANA TLS registry open. Quoting:
>
>
>
> YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert
> Request! I think it's a really bad idea. Better to hack special support to
> existing libraries, allowing this specific extension for this special case,
> than to change the base protocol. Otherwise, this document should UPDATE
> 8446.
>
>
>
> NS: This is a good point and one that we struggled a bit with during
> design. We needed to allow SNI in the CertificateRequest message because 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 cheap, just use a new codepoint.
>
>
>
> Thanks,
>
> Yaron
>
>
>
> *From: *Nick Sullivan 
> *Date: *Monday, November 4, 2019 at 04:49
> *To: *Yaron Sheffer 
> *Cc: *, <
> draft-ietf-tls-exported-authenticator@ietf.org>, , "<
> tls@ietf.org>" 
> *Subject: *Re: 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 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 Sheffer via Datatracker <
> nore...@ietf.org> wrote:
>
> Reviewer: Yaron Sheffer
> Review result: Has Issues
>
> The document is generally clear in both its motivation and the proposed
> solution.
>
> I think it's playing a bit too liberal with TLS 1.3, in sort-of but not
> quite
> deprecating renegotiation, and in changing the IANA registry in a way that
> actually changes the protocol. Details below.
>
> Other comments:
>
> * Abstract: please reword to make it clear that it's the proof (not the
> cert)
> that is portable.
>
>
>
> Proposed text here:
>
> This document describes a mechanism in Transport Layer Security (TLS) for
> peers to
> provide a proof of ownership of a certificate.  This proof can be exported
> by one peer, transmitted out-of-band to the other peer, and verified by
> the receiving peer.
>
>
>
> * Introduction: TLS 1.3 post-handshake auth "has the
> disadvantage of requiring additional state to be stored as part of the TLS
> state machine." Why is that an issue is practice, assuming this feature is
> already supported by TLS libraries? Also, are we in effect deprecating
> this TLS
> 1.3 feature because of the security issue of the mismatched record
> boundaries?
>
>
>
> My understanding is that post-handshake authentication as defined in the
> TLS 1.3 RFC is not implemented in m

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

[Nick Sullivan]

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 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 Sheffer via Datatracker <
> nore...@ietf.org> wrote:
>
>> Reviewer: Yaron Sheffer
>> Review result: Has Issues
>>
>> The document is generally clear in both its motivation and the proposed
>> solution.
>>
>> I think it's playing a bit too liberal with TLS 1.3, in sort-of but not
>> quite
>> deprecating renegotiation, and in changing the IANA registry in a way that
>> actually changes the protocol. Details below.
>>
>> Other comments:
>>
>> * Abstract: please reword to make it clear that it's the proof (not the
>> cert)
>> that is portable.
>
>
> Proposed text here:
> This document describes a mechanism in Transport Layer Security (TLS) for
> peers to
> provide a proof of ownership of a certificate.  This proof can be exported
> by one peer, transmitted out-of-band to the other peer, and verified by
> the receiving peer.
>
> * Introduction: TLS 1.3 post-handshake auth "has the
>> disadvantage of requiring additional state to be stored as part of the TLS
>> state machine." Why is that an issue is practice, assuming this feature is
>> already supported by TLS libraries? Also, are we in effect deprecating
>> this TLS
>> 1.3 feature because of the security issue of the mismatched record
>> boundaries?
>>
>
> My understanding is that post-handshake authentication as defined in the
> TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some
> implementors would prefer to use exported authenticators.
>
> * "For simplicity, the mechanisms... require", maybe a normative REQUIRE?
>
> I'm fine with this.
>
>
>> * Authenticator Request: please clarify that we use the TLS 1.3 format
>> even when
>> running on TLS 1.2.
>
>  Updated, though it might be a bit unnecessary.
>
> * Also, I suggest to change "is not encrypted with a
>> handshake key" which is too specific to "is sent unencrypted within the
>> normal
>> TLS-protected data".
>
> This specific text is meant to differentiate the wire format of this
> message from that of the CertificateRequest message, which is encrypted
> with the handshake key. The specificity is warranted.
>
> * Before diving into the detailed messages in Sec. 3, it
>> would be nice to include a quick overview of the message sequence.
>
> There are two message types and three potential sequences. I've added a
> short overview.
>
>
>> * Sec. 3:
>> "SHOULD use TLS", change to MUST. There's no way it can work otherwise
>> anyway.
>>
> As Ben noted, this could be any secure channel with equivalent security to
> TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms.
>
>
>> * "This message reuses the structure to the CertificateRequest message" -
>> repeats the preceding paragraph.
>
> Fixed
>
>
>> * Sec. 4: again, SHOULD use TLS -> MUST.
>
> Again, I don't see the need for a MUST here.
>
>
>> * Is
>> there a requirement for all protocol messages to be sent over a single TLS
>> connection? If so, please mention it. Certainly this is true for the
>> Authenticator message that must be sent over a single connection and
>> cannot be
>> multiplexed by the high-level protocol. I think this protocol actually
>> assumes
>> "nice" transport properties (no message reorder, reliability) that also
>> require
>> a single, clean TLS connection.
>
> There is no such requirement. Message ordering is managed by the
> application layer protocol that utilizes exported authenticators.
>
>
>> * Why no authenticator request for servers?
>> Don't we care about replay? OTOH if the client wants to detect replays, it
>> would need to keep state on received authenticators, which would be very
>> messy.
>>
> I'm not sure I understand. It's possible to use authenticator requests for
> servers.
>
> * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3].
>
> Added  "Sec. 7.5"
>
> * The
>> discussion of E

Re: [TLS] Delegated Credentials Question about PSS

[Nick Sullivan]

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 affects more than just DCs. DCs are
> > a good way to restore extensibility if there is a problem here,
> > provided we can come up with a solution.
>
> Yeah, I think that this is the clincher.
>
> FWIW, in Firefox we have a separation between TLS and the certificate
> validation logic.  The latter cares about the SPKI of all certificates in
> the certification path because it applies policy related to choice of
> keys.  As a result, that code cares about DC also.  So we don't really get
> to advertise an algorithm until it is supported in both places.  For that
> reason signature_algorithms_cert, as much as it is intended to address this
> sort of split, doesn't really help us.
>
> Logically, there is a split between the certification path construction
> and the policy pieces, and the structure of the code recognizes this, but
> in practice they are somewhat coupled.
>

This makes sense. In the current text, signature_algorithms_cert only
applies to the cert chain, which is fine. It's slightly annoying that
supporting new SPKIs in DCs makes implementations have to support the new
SPKI in certificates, but it doesn't seem like too big of a deal.

I'd be interested in hearing from other client implementations on this
issue (cc: David Benjamin).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Delegated Credentials Question about PSS

[Nick Sullivan]

One may note that no matter what the choice is with respect to RSA, this
particular wrinkle also applies more broadly. For example, if a client
advertises support for ed25519 in "signature_algorithms" in order to
support ed25519 delegated credentials, it should also be prepared to
receive an ed25519 certificate.

Nick

On Tue, Oct 15, 2019 at 5:00 PM Martin Thomson  wrote:

> I think that what Nick proposes is consistent with this, and it also
> matches my preference.  Requiring a PSS OID is nice in that it creates a
> strong constraint.
>
> However, there is a wrinkle.  The way you signal support for the signature
> scheme is through the signature_algorithms extension.  If you advertise
> rsa_pss_pss_*, then that means that you are also indicating support for an
> end entity certificate with a PSS SPKI.  Some certificate validation
> software hasn't been updated to support that and might choke if they got a
> PSS SPKI in a certificate.
>
> I don't know if we could support RSA without double checking our code.
> Adding support shouldn't be too hard, and we don't current advertise PSS
> support, so it's not a complete deal breaker for us, but it's worth
> highlighting.
>
> On Tue, Oct 15, 2019, at 15:58, Russ Housley wrote:
> > When we were working on RFC 4055, we thought it would be important to
> > allow a certified RSA public key to be bound to a specific algorithm
> > (e.g., RSA-PSS or RSA-OAEP). However, in transition, we thought it
> > would be important for the certified RSA public key to be used with any
> > of the algorithms (constrained by key usage extension).
> >
> > Section 1.2 says:
> >
> >  The rsaEncryption object identifier continues to identify the subject
> >  public key when the RSA private key owner does not wish to limit the
> >  use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP.
> >
> >  ...
> >
> >  When the RSA private key owner wishes to limit the use of the public
> >  key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object
> >  identifier MUST be used in the algorithm field within the subject
> >  public key information ...
> >
> >  When the RSA private key owner wishes to limit the use of the public
> >  key exclusively 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, 2019, at 6:34 PM, Nick Sullivan  40cloudflare@dmarc.ietf.org> wrote:
> > >
> > > 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
> scheme, specifically PKCS#1v1.5, which we disallow in TLS 1.3 but not
> explicitly in DCs (yet). This issue is tracked on Github as issues/28 <
> https://github.com/tlswg/tls-subcerts/issues/28>.
> > >
> > > Given the feedback on Github, I see two main choices to resolve this
> issue:
> > >
> > > 1) Allow RSA Credentials with the rsaEncryption OID in the SPKI to be
> used with the rsa_pss_rsae_* signature schemes, but disallow rsa_pkcs1_*
> signature schemes.
> > > 2) Forbid RSA Credentials with the rsaEncryption OID (and associated
> signature schemes) and require an RSA PSS OIDs for rsa_pss_pss_* signature
> schemes.
> > >
> > > Does anyone have a strong preference for one of these options?
> > >
> > > My take:
> > > The rsa_pss_rsae_* suites are a hack created to allow TLS 1.3 to be
> backward-compatible with existing rsaEncryption OID certs while enabling
> RSA-PSS. We don't have this legacy in delegated credentials, so I'm
> inclined to prefer 2).
> > >
> > > The only reason I see to go for 1) is the risk of implementation
> difficulties. The RSA PSS OIDs are hard to get right in code. However,
> considering that RSA DCs are unlikely to be widely used in favor of
> elliptic-curve DCs, the implementation risk seems low and restricted to
> implementations who choose to support RSA DCs as an optional feature.
> > >
> > > Nick
> > >
> > >  ___
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Delegated Credentials Question about PSS

[Nick Sullivan]

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 scheme,
specifically PKCS#1v1.5, which we disallow in TLS 1.3 but not explicitly in
DCs (yet). This issue is tracked on Github as issues/28
.

Given the feedback on Github, I see two main choices to resolve this issue:

1) Allow RSA Credentials with the rsaEncryption OID in the SPKI to be used
with the rsa_pss_rsae_* signature schemes, but disallow rsa_pkcs1_*
signature schemes.
2) Forbid RSA Credentials with the rsaEncryption OID (and associated
signature schemes) and require an RSA PSS OIDs for rsa_pss_pss_* signature
schemes.

Does anyone have a strong preference for one of these options?

My take:
The rsa_pss_rsae_* suites are a hack created to allow TLS 1.3 to be
backward-compatible with existing rsaEncryption OID certs while enabling
RSA-PSS. We don't have this legacy in delegated credentials, so I'm
inclined to prefer 2).

The only reason I see to go for 1) is the risk of implementation
difficulties. The RSA PSS OIDs are hard to get right in code. However,
considering that RSA DCs are unlikely to be widely used in favor of
elliptic-curve DCs, the implementation risk seems low and restricted to
implementations who choose to support RSA DCs as an optional feature.

Nick
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

The main concern I had about including DTLS explicitly in this document was
because exporters are not officially defined for DTLS. However, some other
documents assume they are portable so maybe this is an overly conservative
choice.

On Wed, Oct 9, 2019 at 6:26 PM Martin Thomson  wrote:

> I think that the DTLS thing doesn't require as much rewriting as
> observed.  Just say that when you say "TLS" you mean "TLS or DTLS"
> somewhere up front.
>
> As to what a transport needs to provide, I think that there is no real
> text to add regarding DTLS.  You *could* say that as the application
> protocol is responsible for carrying the messages, might find that using a
> DTLS connection introduces new problems.  Specially, these are big messages
> and they are likely to require fragmentation and reassembly if DTLS is
> used.  Also, if the 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-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
> >  wrote:
> > > Hi,
> > >
> > >  >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.
> > >
> > >  I am mostly fine with your answers. Just a couple of comments inline
> still.
> > >
> > >  ---
> > >
> > >  MIN_2:
> > >
> > >  >>>> Can the mechanism be used also for DTLS?
> > >  >>>
> > >  >>> I think the answer is yes. I don't see any reason to disallow the
> use of Exported Authenticators in DTLS.
> > >  >>
> > >  >> Would it be useful to clarify that?
> > >  >
> > >  > Going through what the modified text would look like, it seems like
> a substantial amount of re-writing (even the title!) for what amounts to an
> unclear use case.
> > >  > Keeping in mind that DTLS 1.3 hasn't been finalized and doesn't
> directly define exporters, I'm disinclined to define how EAs would work
> with DTLS. If someone
> > >  > has a strong use case for EA in DTLS, it may be worth considering
> it.
> > >
> > >  Would it then be useful with a statement saying that it might be
> possible to use exporters also with DTLS, but that such usage is outside
> the scope of the document and needs to be specified in a separate document?
> >
> > I added a line to this effect.
> > >
> > >  ---
> > >
> > >  MIN_3:
> > >
> > >  >>>> The documents talk about additional certificates. If I only have
> one additional
> > >  >>>> certificate, can I use that for multiple authenticators
> throughout the TLS
> > >  >>>> session?
> > >  >>>
> > >  >>> Yes, there is nothing disallowing the creation of multiple
> exported authenticators with the same certificate.
> > >  >>
> > >  >> Would it be useful to clarify that?
> > >  >
> > >  > I'm not convinced this is a realistic use case. Since exported
> authenticators are based on the exporter, there is no inherent ordering.
> > >  > If you re-authenticate with the same certificate, there's nothing
> asserting freshness of the second certificate. Is there something in
> > >  > the text that suggests that using a certificate multiple times is
> disallowed? If there's no suggestion that this is not possible that
> > >  > needs to be corrected, I don't see the benefit of calling out this
> specific use case.
> > >
> > >  I don't think there is any text suggesting that it is disallowed.
> But, if you don't think it is a realistic use case I'll take your word for
> it :)
> > >
> > >  ---
> > >
> > >  ED_2:
> > >
> > >  >>>> Section 3 says: "The authenticator request is a structured
> message that can be
> > >  >>>> created..." Section 4 says: "The authenticator is a structured
> message that can
> > >  >>>> be exported..."
> > >  >>>>
> > >  >>>> In the 2nd paragraph of Section 4 it is stated that
> "authenticator" is sent
>

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

[Nick Sullivan]

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 <
christer.holmb...@ericsson.com> wrote:

> Hi,
>
> >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.
>
> I am mostly fine with your answers. Just a couple of comments inline still.
>
> ---
>
> MIN_2:
>
>  Can the mechanism be used also for DTLS?
> >>>
> >>> I think the answer is yes. I don't see any reason to disallow the use
> of Exported Authenticators in DTLS.
> >>
> >> Would it be useful to clarify that?
> >
> > Going through what the modified text would look like, it seems like a
> substantial amount of re-writing (even the title!) for what amounts to an
> unclear use case.
> > Keeping in mind that DTLS 1.3 hasn't been finalized and doesn't directly
> define exporters, I'm disinclined to define how EAs would work with DTLS.
> If someone
> > has a strong use case for EA in DTLS, it may be worth considering it.
>
> Would it then be useful with a statement saying that it might be possible
> to use exporters also with DTLS, but that such usage is outside the scope
> of the document and needs to be specified in a separate document?
>

I added a line to this effect.

>
> ---
>
> MIN_3:
>
>  The documents talk about additional certificates. If I only have one
> additional
>  certificate, can I use that for multiple authenticators throughout
> the TLS
>  session?
> >>>
> >>> Yes, there is nothing disallowing the creation of multiple exported
> authenticators with the same certificate.
> >>
> >> Would it be useful to clarify that?
> >
> > I'm not convinced this is a realistic use case. Since exported
> authenticators are based on the exporter, there is no inherent ordering.
> > If you re-authenticate with the same certificate, there's nothing
> asserting freshness of the second certificate. Is there something in
> > the text that suggests that using a certificate multiple times is
> disallowed? If there's no suggestion that this is not possible that
> > needs to be corrected, I don't see the benefit of calling out this
> specific use case.
>
> I don't think there is any text suggesting that it is disallowed. But, if
> you don't think it is a realistic use case I'll take your word for it :)
>
> ---
>
> ED_2:
>
>  Section 3 says: "The authenticator request is a structured message
> that can be
>  created..." Section 4 says: "The authenticator is a structured
> message that can
>  be exported..."
> 
>  In the 2nd paragraph of Section 4 it is stated that "authenticator"
> is sent
>  based on an "authenticator request". I wonder if that could be stated
> already
>  in the beginning of Section 4, to further clarify the difference
> between them.
>  E.g.,
> 
>  "The authenticator is a structured message, triggered by an
> authenticator
>  request, that can be exported from either party of a TLS connection."
> >>>
> >>> The issue is that servers can generate spontaneous exported
> authenticators without
> >>> an authenticator request.
> >>
> >> Where is this written? Did I miss it?
> >
> > Section 4:
> >   An authenticator message can be constructed by either the client or
> >   the server given an established TLS connection, a certificate, and a
> >   corresponding private key.  Clients MUST NOT send an authenticator
> >   without a preceding authenticator request; for servers an
> >   authenticator request is optional.  For authenticators that do not
> >   correspond to authenticator requests, the certificate_request_context
> >   is chosen by the server.
>
> Ok. Looks good.
>
> Regards,
>
> Christer
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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,
>
> Thanks for your reply! Please see inline.
>
> >>MIN_1:
> >>The last sentence of Section 1 says that the mechanism requires TLS
> version 1.2
> >>or later. Would it be useful to state that in a dedicated Applicability
> section?
> >
> > I'm disinclined to include an applicability section considering how
> short it would be.
> > I'm open to being convinced otherwise with examples.
>
> If others think it's clear enough (or, that it doesn't need to be that
> clear, because earlier versions will anyway disappear), I am fine to keep
> in in Section 1.
>
> ---
>
> >> MIN_2:
> >> Can the mechanism be used also for DTLS?
> >
> > I think the answer is yes. I don't see any reason to disallow the use of
> Exported Authenticators in DTLS.
>
> Would it be useful to clarify that?
>

Going through what the modified text would look like, it seems like a
substantial amount of re-writing (even the title!) for what amounts to an
unclear use case. Keeping in mind that DTLS 1.3 hasn't been finalized and
doesn't directly define exporters, I'm disinclined to define how EAs would
work with DTLS. If someone has a strong use case for EA in DTLS, it may be
worth considering it.


>
> ---
>
> >> MIN_3:
> >> The documents talk about additional certificates. If I only have one
> additional
> >> certificate, can I use that for multiple authenticators throughout the
> TLS
> >> session?
> >
> > Yes, there is nothing disallowing the creation of multiple exported
> authenticators with the same certificate.
>
> Would it be useful to clarify that?
>

I'm not convinced this is a realistic use case. Since exported
authenticators are based on the exporter, there is no inherent ordering. If
you re-authenticate with the same certificate, there's nothing asserting
freshness of the second certificate. Is there something in the text that
suggests that using a certificate multiple times is disallowed? If there's
no suggestion that this is not possible that needs to be corrected, I don't
see the benefit of calling out this specific use case.

>
> ---
>
> >> MIN_4:
> >> Section 3 and 4 say that the authenticator request and authenticator
> SHOULD be
> >> sent using TLS, and Section 1 says that the proof of authentication can
> be sent
> >>out-of-band. I think it would be useful to clarify whether both the
> >>authenticator request and authenticator can be sent out-of-band ( i.e.,
> not
> >>using the TLS connection that the additional authentication is associated
> >>with), and also to state whether it IS allowed to send the authenticator
> >>request and authenticator on the TLS connection they are associated with.
> >
> > Good point. I can clarify this a bit. Both the authenticator and
> authenticator request can be sent
> > through either the TLS connection they were derived from or another TLS
> connection altogether.
> > The important part is that they are sent over an encrypted and
> authenticated connection.
>
> Thanks!
>
> ---
>
> >> MIN_5:
> >> Section 5 talks about an endpoint sending an empty authenticator. But,
> what if
> >> the sender of the authenticator request does not receive anything?
> Does it
> >> simply move on? Does it terminate the TLS session? Is the action based
> on local
> >> policy?
> >
> > The TLS layer is stateless. The decision to time out or fail the
> connection if an authenticator request
> > is not responded to is left to higher-level protocols that leverage EAs.
> >
> >> MIN_6:
> >> Related to MIN_5, I can't find text about how endpoints inform each
> other about
> >> the support of the mechanism, so maybe a few words about that would be
> useful.
> >> And some words about backward compatibility with endpoints that don't
> support
> >> the mechanism.
> >
> > Adding an extension to signal support for exported authenticators was
> discussed at some point,
> > but it was decided that the higher-layer application should handle the
> signaling.
> >
> >> MIN_7:
> >> What happens if the validation of an authenticator fails? Does the
> requester
> >> simply move on? Does it terminate the TLS session? Is the action based
> on local
> >> policy?
> >
> > This is also up to the application-layer protocol. I'll add text
> covering MIN_5, MIN_6 and MIN_7.
>
> Thanks!
>
> ---
>
> >> ED_1:
> >> The document uses "session", "TLS connection" and "TLS communication"
> >> terminology. Is that intentional, or wouuld it be possible to use
> consistent
> >> terminology?
> > Good note. I'll standardize on "connection".
>
> Thanks!
>
> ---
>
> >> ED_2:
> >> Section 3 says: "The authenticator request is a structured message that
> can be
> >> created..." Section 4 says: "The authenticator is a structured message
> that can
> >> be exported..."
> >>
> >> In 

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

[Nick Sullivan]

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 Sheffer via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Yaron Sheffer
> Review result: Has Issues
>
> The document is generally clear in both its motivation and the proposed
> solution.
>
> I think it's playing a bit too liberal with TLS 1.3, in sort-of but not
> quite
> deprecating renegotiation, and in changing the IANA registry in a way that
> actually changes the protocol. Details below.
>
> Other comments:
>
> * Abstract: please reword to make it clear that it's the proof (not the
> cert)
> that is portable.


Proposed text here:
This document describes a mechanism in Transport Layer Security (TLS) for
peers to
provide a proof of ownership of a certificate.  This proof can be exported
by one peer, transmitted out-of-band to the other peer, and verified by the
receiving peer.

* Introduction: TLS 1.3 post-handshake auth "has the
> disadvantage of requiring additional state to be stored as part of the TLS
> state machine." Why is that an issue is practice, assuming this feature is
> already supported by TLS libraries? Also, are we in effect deprecating
> this TLS
> 1.3 feature because of the security issue of the mismatched record
> boundaries?
>

My understanding is that post-handshake authentication as defined in the
TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some
implementors would prefer to use exported authenticators.

* "For simplicity, the mechanisms... require", maybe a normative REQUIRE?

I'm fine with this.


> * Authenticator Request: please clarify that we use the TLS 1.3 format
> even when
> running on TLS 1.2.

 Updated, though it might be a bit unnecessary.

* Also, I suggest to change "is not encrypted with a
> handshake key" which is too specific to "is sent unencrypted within the
> normal
> TLS-protected data".

This specific text is meant to differentiate the wire format of this
message from that of the CertificateRequest message, which is encrypted
with the handshake key. The specificity is warranted.

* Before diving into the detailed messages in Sec. 3, it
> would be nice to include a quick overview of the message sequence.

There are two message types and three potential sequences. I've added a
short overview.


> * Sec. 3:
> "SHOULD use TLS", change to MUST. There's no way it can work otherwise
> anyway.
>
As Ben noted, this could be any secure channel with equivalent security to
TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms.


> * "This message reuses the structure to the CertificateRequest message" -
> repeats the preceding paragraph.

Fixed


> * Sec. 4: again, SHOULD use TLS -> MUST.

Again, I don't see the need for a MUST here.


> * Is
> there a requirement for all protocol messages to be sent over a single TLS
> connection? If so, please mention it. Certainly this is true for the
> Authenticator message that must be sent over a single connection and
> cannot be
> multiplexed by the high-level protocol. I think this protocol actually
> assumes
> "nice" transport properties (no message reorder, reliability) that also
> require
> a single, clean TLS connection.

There is no such requirement. Message ordering is managed by the
application layer protocol that utilizes exported authenticators.


> * Why no authenticator request for servers?
> Don't we care about replay? OTOH if the client wants to detect replays, it
> would need to keep state on received authenticators, which would be very
> messy.
>
I'm not sure I understand. It's possible to use authenticator requests for
servers.

* 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3].

Added  "Sec. 7.5"

* The
> discussion of Extended Master Secret only applies to TLS 1.2 - please
> clarify
> that, plus I suggest to reword this paragraph which I find hard to parse.

re-worded

*
> 4.2: "the extensions are chosen from the TLS handshake." - What does it
> mean
> exactly, and how does an application even know which extensions were used
> at
> the TLS layer? Reading further, we mention "ClientHello extensions." Maybe
> the
> authenticator should also include a ClientHello message to indicate
> supported
> extensions. Assuming we can peek into ClientHello contradicts the hopeful
> "even
> if it is possible to implement it at the application layer" in Sec. 6.


This could be clearer. Effectively, the Certificate message in the
Authenticator needs
to be constructed in a similar manner to how a Certificate message would be
created
in a TLS handshake. Namely, it can only contain extensions that were
present in either
the client hello or a preceding CertificateRequest.

You're right that this makes an assumption that the party creating the
Authenticator
has access to 

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

[Nick Sullivan]

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 the call for adoption. It will run until August 7, 2019.
> Please indicate whether or not you would like to see this draft adopted.
>
> Best,
> Chris, on behalf of the chairs
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 document is generally clear in both its motivation and the proposed
> solution.
>
> I think it's playing a bit too liberal with TLS 1.3, in sort-of but not
> quite
> deprecating renegotiation, and in changing the IANA registry in a way that
> actually changes the protocol. Details below.
>
> Other comments:
>
> * Abstract: please reword to make it clear that it's the proof (not the
> cert)
> that is portable. * Introduction: TLS 1.3 post-handshake auth "has the
> disadvantage of requiring additional state to be stored as part of the TLS
> state machine." Why is that an issue is practice, assuming this feature is
> already supported by TLS libraries? Also, are we in effect deprecating
> this TLS
> 1.3 feature because of the security issue of the mismatched record
> boundaries?
> * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? *
> Authenticator Request: please clarify that we use the TLS 1.3 format even
> when
> running on TLS 1.2. * Also, I suggest to change "is not encrypted with a
> handshake key" which is too specific to "is sent unencrypted within the
> normal
> TLS-protected data". * Before diving into the detailed messages in Sec. 3,
> it
> would be nice to include a quick overview of the message sequence. * Sec.
> 3:
> "SHOULD use TLS", change to MUST. There's no way it can work otherwise
> anyway.
> * "This message reuses the structure to the CertificateRequest message" -
> repeats the preceding paragraph. * Sec. 4: again, SHOULD use TLS -> MUST.
> * Is
> there a requirement for all protocol messages to be sent over a single TLS
> connection? If so, please mention it. Certainly this is true for the
> Authenticator message that must be sent over a single connection and
> cannot be
> multiplexed by the high-level protocol. I think this protocol actually
> assumes
> "nice" transport properties (no message reorder, reliability) that also
> require
> a single, clean TLS connection. * Why no authenticator request for servers?
> Don't we care about replay? OTOH if the client wants to detect replays, it
> would need to keep state on received authenticators, which would be very
> messy.
> * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. *
> The
> discussion of Extended Master Secret only applies to TLS 1.2 - please
> clarify
> that, plus I suggest to reword this paragraph which I find hard to parse. *
> 4.2: "the extensions are chosen from the TLS handshake." - What does it
> mean
> exactly, and how does an application even know which extensions were used
> at
> the TLS layer? Reading further, we mention "ClientHello extensions." Maybe
> the
> authenticator should also include a ClientHello message to indicate
> supported
> extensions. Assuming we can peek into ClientHello contradicts the hopeful
> "even
> if it is possible to implement it at the application layer" in Sec. 6. *
> 4.2.1:
> the first sentence of the section is incomplete. * Can I use TLS
> 1.3-specific
> extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there a
> situation where a certificate is acceptable for TLS 1.3 connections but
> not for
> TLS 1.2 connections? * "using a value derived from the connection secrets"
> - I
> think we should recommend a specific construction here to ensure people do
> it
> securely. * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))?
> If
> so, please say so. * 4.2.4: "a constant-time comparison" - why is it
> actually
> required, what is the threat? An attacker can do very little because each
> authenticator being sent is different. * 5: please say explicitly which
> messages are used in this case to construct the authenticator. * 6.1: the
> "MUST" is strange in a section that's only supposed to be informative.
> Also,
> the library may provide this extension (and possibly others) without
> requiring
> it as input. * 6.4: "The API MUST return a failure if the
> certificate_request_context of the authenticator was used in a previously
> validated authenticator." Are we requiring the library to keep previous
> contexts for replay protection? If so, please make it explicit. *  7.1:
> this is
> changing TLS 1.3 by allowing this extension in Cert Request! I think it's a
> really bad idea. Better to hack special support to existing libraries,
> allowing
> this specific extension for this special case, than to change the base
> protocol. Otherwise, this document should UPDATE 8446. * 8: I think the
> Security Considerations is the right place to talk about interaction
> between
> this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply
> RECOMMEND
> not to do it. Or else explain the use cases where renegotiation is still
> useful
> if 

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

[Nick Sullivan]

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 the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-tls-exported-authenticator-09
> Reviewer: Christer Holmberg
> Review Date: 2019-07-07
> IETF LC End Date: 2019-07-16
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The document is well written. However, I have found some issues
> that
> the author may want to consider clarifying in the document.
>
> Major issues: N/A
>
> Minor issues:
>
> MIN_1:
> The last sentence of Section 1 says that the mechanism requires TLS
> version 1.2
> or later. Would it be useful to state that in a dedicated Applicability
> section?
>
> MIN_2:
> Can the mechanism be used also for DTLS?
>
> MIN_3:
> The documents talk about additional certificates. If I only have one
> additional
> certificate, can I use that for multiple authenticators throughout the TLS
> session?
>
> MIN_4:
> Section 3 and 4 say that the authenticator request and authenticator
> SHOULD be
> sent using TLS, and Section 1 says that the proof of authentication can be
> sent
> out-of-band. I think it would be useful to clarify whether both the
> authenticator request and authenticator can be sent out-of-band ( i.e., not
> using the TLS connection that the additional authentication is associated
> with), and also to state whether it IS allowed to send the authenticator
> request and authenticator on the TLS connection they are associated with.
>
> MIN_5:
> Section 5 talks about an endpoint sending an empty authenticator. But,
> what if
> the sender of the authenticator request does not receive anything?  Does it
> simply move on? Does it terminate the TLS session? Is the action based on
> local
> policy?
>
> MIN_6:
> Related to MIN_5, I can't find text about how endpoints inform each other
> about
> the support of the mechanism, so maybe a few words about that would be
> useful.
> And some words about backward compatibility with endpoints that don't
> support
> the mechanism.
>
> MIN_7:
> What happens if the validation of an authenticator fails? Does the
> requester
> simply move on? Does it terminate the TLS session? Is the action based on
> local
> policy?
>
> Nits/editorial comments:
>
> ED_1:
> The document uses "session", "TLS connection" and "TLS communication"
> terminology. Is that intentional, or wouuld it be possible to use
> consistent
> terminology?
>
> ED_2:
> Section 3 says: "The authenticator request is a structured message that
> can be
> created..." Section 4 says: "The authenticator is a structured message
> that can
> be exported..."
>
> In the 2nd paragraph of Section 4 it is stated that "authenticator" is sent
> based on an "authenticator request". I wonder if that could be stated
> already
> in the beginning of Section 4, to further clarify the difference between
> them.
> E.g.,
>
> "The authenticator is a structured message, triggered by an authenticator
> request, that can be exported from either party of a TLS connection."
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Delegated Credentials in Client certificates

[Nick Sullivan]

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:

https://github.com/tlswg/tls-subcerts/pull/26/files/a502f3055c3eefe59a4b36642cd062267ac0fff7

Let me know if there is opposition to this change. I'm planning on
submitting -04 later today.

Nick
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 Kaduk  wrote:
>
> Hi all,
>
> I don't think there's anything earth-shattering in here; mostly just
places
> where we can tighten things up before it gets to a broader set of
> reviewers.
>
> Thanks!
>
> -Ben
>
> Abstract, Introduction
>
> Maybe s/other party/peer/?

How about:

This document provides a way to authenticate one party of a Transport
Layer Security (TLS) communication to its peer using a certificate

> Section 1
>
>This document provides a way to authenticate one party of a Transport
>Layer Security (TLS) communication to another using a certificate
>after the session has been established.  This allows both the client
>and server to prove ownership of additional identities at any time
>after the handshake has completed.  This proof of authentication can
>be exported and transmitted out of band from one party to be
>validated by the other party.
>
> We need to be careful about what exactly is being proved when, and how it
> synchronizes (or doesn't) with other events/data.
> This will be a general theme throughout...
>
>multiple identities -  Endpoints that are authoritative for multiple
>   identities - but do not have a single certificate that includes
>   all of the identities - can authenticate with those identities
>   over a single connection.
>
> (The RFC Editor will do two-hyphen em dashes.)
> I didn't go back and reread the formal analysis that Jonathan sent out,
> but my recollection was that the semantics around being "jointly
> authoritative" over multiple identities are quite subtle, and that the
> wording here may be doing the reader a disservice.


Here's a suggested edit:
can authenticate with those identities over a single connection ->
can authenticate additional identities over a single connection

Jonathan's analysis showed that the protocol provides "joint
authentication" between the certificate used in the handshake and one added
as an EA. It does not provide "joint authentication" between two EAs.
That's a subtle point, but I think it maps cleanly to this text.


>
>
>
>This document intends to replace much of the functionality of
>renegotiation in previous versions of TLS.  It has the advantages
>over renegotiation of not requiring additional on-the-wire changes
>during a connection.  For simplicity, only TLS 1.2 and later are
>supported.
>
> Well, renegotiation does many things.  We need to say why we claim that
> renegotiation was widely used and for what purpose(s), and only then say
> that we provide an alternative.
> Also, the wording about "previous versions of TLS" is pretty vague -- is
> it intended to be "prior to TLS 1.3"?


Very good point.

How about:
  Versions of TLS prior to TLS 1.3 used renegotiation as a way to enable
  post-handshake client authentication given an existing TLS connection.
  The mechanism described in this document may be used to replace the
  post-handshake authentication functionality provided by renegotiation.
  Unlike renegotiation, exported Authenticator-based post-handshake
  authentication does not require any on-the-wire changes.  For simplicity,
  only TLS 1.2 and later are supported.

>
>
>
>Post-handshake authentication is defined in TLS 1.3, but it has the
>disadvantage of requiring additional state to be stored in the TLS
>state machine and it composes poorly with multiplexed connection
>protocols like HTTP/2 [RFC7540].  It is also only available for
>
> We should probably be more explicit about "composes poorly" being due to
> the authentication not being tied to a specific event at the higher
> layer (among other things).


How about:
   Post-handshake authentication is defined in TLS 1.3, but it has the
   disadvantage of requiring additional state to be stored in the TLS
   state machine.  Furthermore, the authentication boundaries of TLS
   1.3 post-handshake authentication align with TLS record boundaries,
   which are often not aligned with the authentication boundaries of the
   higher-layer protocol. For example, multiplexed connection protocols
   like HTTP/2 [RFC7540] do not have a notion of which TLS record
   a given message is a part of.

>
>
> Section 3
>
>
>The authenticator request is a structured message that can be
>exported from either party of a TLS connection.  It can be
>transmitted to the other party of the TLS connection at the
>application layer.  The application layer protocol used to send the
>authenticator SHOULD use TLS as its underlying transport to keep the
>request confidential.
>
> Also to indicate which TLS connection to pull key material from?

How about:
   The authenticator request is a 

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

[Nick Sullivan]

All,

We have submitted a draft that describes several ways that OPAQUE (
https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-01) can be
implemented in TLS 1.3, both as an in-handshake authentication method and
as a post-handshake authentication method via Exported Authenticators.

Nick

-- 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 by Nick Sullivan and posted to the
IETF repository.

Name:   draft-sullivan-tls-opaque
Revision:   00
Title:  Usage of OPAQUE with TLS 1.3
Document date:  2019-03-11
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-sullivan-tls-opaque-00.txt
Status: https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque/
Htmlized:   https://tools.ietf.org/html/draft-sullivan-tls-opaque-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-sullivan-tls-opaque


Abstract:
   This document describes two mechanisms for enabling the use of the
   OPAQUE password-authenticated key exchange in TLS 1.3.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Two Multi-CDN proposals

[Nick Sullivan]

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/ records
> and CNAMEs.  The easiest way to handle key update complexities on the part
> of the CDN(s) is simply to CNAME the ESNI query for your domain to their
> ESNI record, but you can certainly directly host your CDN’s keys in your
> domain if you prefer.  Nothing should preclude that.
> > The issue we’re trying to address is when the ESNI record and the A/
> record follow different CNAME chains and you get the records from different
> hosts.  Of course, if we move to an ESNI RRType with the same hostname (see
> #105), there’s hopefully a single CNAME chain that gets cached at the
> resolver and used when looking up both queries.  If they remain separate
> hostnames, it seems like it gets much easier for them to diverge.
> > It’s my understanding that DNSsec doesn’t play well with returning a
> subset of all extant RRs for a given name+type.  However, some CDNs return
> DNS results tailored to the user’s location; the load-balancing servers
> will (in some cases) return CNAMEs to different targets based on the
> desired traffic share.  That’s not a behavior that maps well to DNSsec as I
> understand it.  You mention DNSsec signing your domain as part of why you
> have issues with the proposal, but I think this is an open issue beyond
> ESNI or these PRs.
> >
> > Maybe someone better-steeped in DNS/DNSsec can help us figure out how
> all that should work, and I agree with you that there are definitely bumps
> here we need to iron out – maybe those are just questions to answer, or
> maybe changes to the structure of the record are warranted.
> >
> > However, these PRs are primarily about what information should be in
> these records and how clients make use of it.  I disagree with you that we
> have to resolve both questions at the same time.  Let’s agree on content
> first, and spent some time separately with DNS folks to see whether the
> content can be more pleasantly arranged.
>
> Thanks all for the discussion so far! Focusing strictly on the content
> of the records and not the formatting, as Mike suggests, we
> essentially have the following:
>
> - #137 gives clients a way to detect A/+ESNI mismatch and recover,
> at the cost of another sequential DNS query for ESNI. In this change,
> A/ records still control where traffic goes.
> - #136 never requires clients to send a second DNS query for ESNI
> since clients ignore the A/ results. In this change, ESNI records
> dictate routing.
>
> With #137, clients willing to send a second DNS query will get ESNI
> for all supporting providers. Clients unwilling to send a second DNS
> query will only get ESNI for those providers which ensure that their
> A/ and ESNI records very rarely mismatch. With #136, clients only
> get ESNI for those providers capable of building ESNI records with
> correct addresses. In theory, these providers should be the same ones
> that could ensure A/ and ESNI record matching.
>
> Given this, the discussion seems to hinge on the following question:
> Are operators comfortable with the risks of letting ESNI records
> control routing. If so, #136 is probably a better design for said
> operators. If not, then #137 is probably required.


Thanks for the summary, Chris.

Speaking for Cloudflare, we prefer the method described in #136 and would
be willing to implement ESNI records this way.

I have sympathy for organizations with a preference for #137 for
debuggability reasons, but I would rather avoid situations in which the
client needs to do an additional DNS query if avoidable.

I would support the option to include either extension based on operator
preference.


> Note that this does not mean we must choose between #136 and #137
> right now. We can do both (after possibly simplifying #137!), use
> them, and see what works best in practice.
>
> Anyway, I hope this summary accurately captures the differences and
> possible tradeoffs.
>
> Best,
> Chris
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

TLSWG,

We've posted draft -03 of the Delegated Credentials draft. It includes some
editorial improvements (thanks Christopher Patton) and two changes
discussed on the list:
1) fixing the text around covering the credential in the signature
2) removing the TLS version from the structure

We hope 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-subcerts-03.txt
has been successfully submitted by Nick Sullivan and posted to the
IETF repository.

Name:   draft-ietf-tls-subcerts
Revision:   03
Title:  Delegated Credentials for TLS
Document date:  2019-02-19
Group:  tls
Pages:  12
URL:
https://www.ietf.org/internet-drafts/draft-ietf-tls-subcerts-03.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
Htmlized:   https://tools.ietf.org/html/draft-ietf-tls-subcerts-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-03

Abstract:
   The organizational separation between the operator of a TLS server
   and the certification authority can create limitations.  For example,
   the lifetime of certificates, how they may be used, and the
   algorithms they support are ultimately determined by the
   certification authority.  This document describes a mechanism by
   which operators may delegate their own credentials for use in TLS,
   without breaking compatibility with clients that do not support this
   specification.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ticket lifetimes

[Nick Sullivan]

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 think that'd need a new draft either way. Can definitely write that up
> if people don't think it's the worst idea in the world.
>
> Subodh
> --
> *From:* Christopher Wood 
> *Sent:* Monday, January 28, 2019 10:13:36 PM
> *To:* Subodh Iyengar
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] ticket lifetimes
>
> On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar  wrote:
> >
> > > Since clients already store tickets, could they not also store the
> > time of original ticket issuance and cap the resumption window to N
> > (7) days from that point? That is, it seems clients could implement
> > this behavior without any protocol support.
> >
> > Correct, however the server currently provides a value for this, and
> clients do not enforce a lower bound on this. 7 days is an upper bound.
> > Servers would provide a much lower value than 7 days practically.
> >
> > If I'm understanding your suggestion correctly, you're suggesting that
> clients change the meaning of ticket_lifetime_hint?
> > That is not just limit it to the scope of the ticket but the entire TLS
> session? That would be fine to by me, however might break some folks.
>
> If by "entire TLS session" you mean the resumed (and renewed)
> sessions, then yep!
>
> Best,
> Chris
>
> >
> > Subodh
> > 
> > From: Christopher Wood 
> > Sent: Monday, January 28, 2019 9:57 PM
> > To: Subodh Iyengar
> > Cc: tls@ietf.org
> > Subject: Re: [TLS] ticket lifetimes
> >
> > On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar  wrote:
> > >
> > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days.
> This had several original motivations including reducing the time that a
> ticket is reused (for privacy or PFS). Another major motivation for this
> was to limit the exposure of servers that use keyless ssl like mechanisms,
> i.e. if they kept a STEK locally, but the keyless SSL server remotely, then
> the theft of a STEK would presumably limit the MITM capabilities to the
> ticket lifetime.
> > >
> > > However thinking about it some more because of the renewal capability
> of tickets in TLS 1.3, an entity owning the STEK could just re-issue new
> tickets forever on a resumed connection. This would look to the client as a
> new ticket and it would refresh its lifetime on the ticket. Thereby a MITM
> could intercept connections to users that have been to the server with the
> STEK. I'm wondering whether it might be useful to define a mechanism to
> limit the lifetime of all ticket resumption across all resumptions from the
> original connection instead of just the limited per ticket lifetime.
> >
> > Since clients already store tickets, could they not also store the
> > time of original ticket issuance and cap the resumption window to N
> > (7) days from that point? That is, it seems clients could implement
> > this behavior without any protocol support.
> >
> > Best,
> > Chris
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 the TLS@IETF103 session, there was interest in adopting
> > draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG
> > item, provided that it's limited to external PSKs with certificates
> > for the initial handshake. This email is to determine whether there is
> > WG consensus to adopt this draft (as is) as a WG item.
> >
> > If you would like for this draft to become a WG document and you are
> > willing to review it as it moves through the process, then please let
> > the list know by 2359UTC 20180208. If you are opposed to this being a
> > WG document, please say so (and say why).
> >
> > Thanks,
> > Chris, Joe and Sean
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 strongly about the tls version binding and I'd be fine
> with removing it to favor operational simplification.
>
>
> Subodh
> --
> *From:* TLS  on behalf of Martin Thomson <
> m...@lowentropy.net>
> *Sent:* Tuesday, January 15, 2019 7:39:44 PM
> *To:* tls@ietf.org
> *Subject:* Re: [TLS] Version pinning and indicating the signing algorithm
> in draft-ietf-tls-subcerts-02
>
> On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote:
> > Usually the negotiation happens during the processing of the client
> hello.
>
> I don't think that the problem here is a code problem.  It's an
> operational one.
>
> In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be
> made in isolation.  You decide to flip the switch and flip it.  But if you
> are doing delegated credentials, deploying a new version depends on having
> a fallback in place for that version, or getting the vendor of delegated
> credentials to start supplying new credentials.  And that assumes that all
> the necessary stores are keyed correctly (though this highlights the case
> where that might not happen), and the code has been written.  It's not that
> it's impossible, but more that it complicates what was previously
> uncomplicated.
>
> As you say, the decision to use a delegated credential is fairly simple.
>
> ___
> TLS mailing list
> TLS@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=DwICAg=5VD0RTtNlTh3ycd41b3MUw=h3Ju9EBS7mHtwg-wAyN7fQ=qOxPqAH-53XWS1ivRMVW5YPWzTYrcOjqXPcoImyDlnM=LwnVFi-5giNs_anA6DyKhcbiJ5NCSU5T1oZyDjx33Nw=
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Multi-CDN and ESNI

[Nick Sullivan]

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 cases are related and there are two features missing from the
current ESNI draft that might be useful to mitigate these scenarios:
1) Allow multiple simultaneous ESNI keys. The DNS provider could present
ESNI keys from multiple HTTPS providers (perhaps as different DNS records)
and the client could choose to send multiple entries in its ESNI extension,
each encrypted to a different key. This would likely solve the multi-CDN
scenario at the cost of some clienthello bloat.
2) Allow in-band distribution of ESNI keys if the server does not know the
ESNI key sent by the client. The server could prove ownership over a
specific long-term "fallback key" advertised in the ESNI record (or maybe a
fallback domain) when sent a TLS connection for which no ESNI extensions
can be decrypted, then in-band send back a new ESNI public key that the
client could use to send the SNI in a follow-up message. It's also possible
that handshake encryption alone is enough. This might require some TLS
message gymnastics, but doesn't seem impossible. I've heard more well-baked
versions of this idea batted around by others. (note that this incurs at
least one additional round-trip, but considering that a server not having
the active ESNI key should be rare, it is likely ok)

To comment specifically on your proposals, Patrick, I don't see #3 as a
workable solution since many authoritative DNS providers hide the fact that
a CNAME is used when returning A/ records. This obfuscates the
indirection that would be necessary to do what you propose, and it does it
for a good reason (saving round trips on DNS resolution). Furthermore,
intermediate values of CNAME chains seems like a brittle mechanism to rely
on for policy enforcement.

Nick

On Tue, Oct 23, 2018 at 2:28 PM Patrick McManus 
wrote:

> Definitely agree this is something that needs to be addressed..
>
> As Mike notes, the fundamental issue is that there are 2 pieces of
> information that are statefully related (the key and address) but obtained
> statelessly from each other and can therefore come from un-coordinated
> sources. 2 CDNs are commonly un-coordinated sources.. but I've seen this
> with other kinds of cloud providers too. All of which should be target
> audiences of ESNI (because they terminate a variety of hostnames on a
> smaller number of addresses).
>
> fwiw there is a muddled github issue open on this in the old
> individual-draft repo:
> https://github.com/ekr/draft-rescorla-tls-esni/issues/35 .. which I'll
> re-open when the tls-wg repo starts being used for this draft.
>
> I see three solution spaces.
>
> 1] As Rich suggests, you can coordinate the uncoordinated sources to have
> one keying record to rule them all. I suspect that's actually not good for
> anonymity unless it somehow had a normalized global set .. and given the
> one way nature of a CNAME pointer, I feel like this would be really fragile.
>
> 2] you could scope the keys to only be valid for certain addresses by
> putting the valid addresses in the key record. This wouldn't help you do
> ESNI when they didn't match, but at least you could avoid hard failure. (or
> you could ignore the addressing record but that might be a bridge too far?)
>
> 3] My preferred approach, you could scope the keys to the same
> intermediate name. So if www.example.com -> cname www.cdn-a.com -> ESNI
> record www.cdn-a.com we could make a rule that the ESNI record would only
> apply to address records with a final intermediate of www.cdn-a.com. (I'm
> presuming we'll shift from TXT to ESNI RRTYPE without a prefix, but I don't
> think it matters for this..).. when there is a mismatch you could use the
> addressing intermediate as a place to try a new ESNI query from.. That's a
> perf penalty, but its only paid in the hopefully rare case where these
> things are unsyncd.
>
> #3 is admittedly a bit non traditional, but I spent a bit of time looking
> at the features of DNS APIs that already have the necessary surface to make
> a query for a new RRTYPE... and the cname intermediates are indeed
> generally available.. its true of getdns, res_query, the IOS and MacOS
> interfaces, DnsQuery* on windows, and of course the custom dns stacks in
> cronet/android and firefox/doh could do it.
>
> I hope to work this into a PR.. my first attempt wasn't very readable, but
> I'll try again tomorrow.
>
> -P
>
>
>
>
>
>
> On Tue, Oct 23, 2018 at 1:59 PM Salz, Rich  wrote:
>
>> I think perhaps we need to take a step back and explain something that
>> might not be well-known outside the community of CDN’s and their
>> customers.  It is not uncommon for (admittedly larger) origins to use
>> multiple CDN’s, and to switch among them. This can be 

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

[Nick Sullivan]

I've posted draft 08 of Exported Authenticators. It contains a few minor
changes:
- an updated reference to RFC 8443
- an updated IANA considerations section
- a text change to require CRCs to be unique within a connection (requested
at IETF 102 by Jonathan Hoyland)
- minor text fixes

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 of I-D, draft-ietf-tls-exported-authenticator-08.txt
has been successfully submitted by Nick Sullivan and posted to the
IETF repository.

Name:   draft-ietf-tls-exported-authenticator
Revision:   08
Title:  Exported Authenticators in TLS
Document date:  2018-10-18
Group:  tls
Pages:  12
URL:
https://www.ietf.org/internet-drafts/draft-ietf-tls-exported-authenticator-08.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/
Htmlized:
https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-08
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-08

Abstract:
   This document describes a mechanism in Transport Layer Security (TLS)
   to provide an exportable proof of ownership of a certificate that can
   be transmitted out of band and verified by the other party.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

tlswg,

After incorporating feedback from the working group, we have published
draft 02 of Delegated Credentials. It contains the following changes from
draft -01:

 (*) indicates changes to the wire protocol.
- Change public key type. (*)
- Change DelegationUsage extension to be NULL and define its object
identifier.
- Drop support for TLS 1.2.
- Add the protocol version and credential signature algorithm to the
Credential structure. (*)
- Specify undefined behavior in a few cases: when the client receives a DC
without indicated support; when the client indicates the extension in an
invalid protocol version; and when DCs are sent as extensions to
certificates other than the end-entity certificate.

Nick

On Fri, Aug 17, 2018 at 11:19 AM  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 Credentials for TLS
> Authors : Richard Barnes
>   Subodh Iyengar
>   Nick Sullivan
>   Eric Rescorla
> Filename: draft-ietf-tls-subcerts-02.txt
> Pages   : 12
> Date: 2018-08-17
>
> Abstract:
>The organizational separation between the operator of a TLS server
>and the certification authority can create limitations.  For example,
>the lifetime of certificates, how they may be used, and the
>algorithms they support are ultimately determined by the
>certification authority.  This document describes a mechanism by
>which operators may delegate their own credentials for use in TLS,
>without breaking compatibility with clients that do not support this
>specification.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-subcerts-02
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 follows:
>
>
>
>
>- Drop support for TLS 1.2.
>- Add the protocol version and credential signature algorithm to the
>Credential structure.
>
>
>- Specify undefined behavior in a few cases: when the client receives
>a DC without indicated support; when the client indicates the extension in
>an invalid protocol version; and when DCs are sent as extensions to
>certificates other than the end-entity certificate.
>
>
> Any additional feedback is welcome.
>
>
> Thanks,
>
> Christopher Patton
>
>
> --
> *From:* Blumenthal, Uri - 0553 - MITLL 
> *Sent:* Tuesday, July 24, 2018 4:40 PM
> *To:* Ilari Liusvaara; Patton,Christopher J
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] Proposals for draft-ietf-tls-subcerts-02
>
> I object to re-interpreting/overloading the Critical flag. It has one and
> only one meaning: "If the parser does not understand the given attribute,
> it must abort parsing if this attribute is marked as Critical (or ignore
> this attribute and continue parsing if the Critical flag is not set)".
>
>
> On 7/24/18, 16:25, "TLS on behalf of Ilari Liusvaara" <
> tls-boun...@ietf.org on behalf of ilariliusva...@welho.com> wrote:
>
> On Tue, Jul 24, 2018 at 07:24:09PM +, Patton,Christopher J wrote:
> > Hi all,
> >
> >
> > I've taken the liberty of addressing the changes to the delegated
> credentials extension that were requested at IETF:
> >
> > https://github.com/tlswg/tls-subcerts/pull/13
>
> >
> >
> > The changes that would be adopted in draft-02 are as follows:
> >
> >   *   Drop support for TLS 1.2.
> >   *   Allow the critical bit of the X.509 extension to be set.
> >   *   Add the protocol version and credential signature algorithm
> >   to the Credential structure.
> >   *   Make the KeyUsage of the delegation certificate stricter.
> >   *   Specify undefined behavior in a few cases.
> >
> > It was suggested that we add optional "must-use-DC" semantics to the
> > certificate. The solution we came up with was to add a "strict" flag
> > to the extension that is set if (and only if) the extension is marked
> > critical. The idea is that if the "strict" flag is set and the server
> > doesn't offer a DC, then client must abort the handshake, In my
> opinion,
> > the complexity this adds to the protocol outweighs the potential
> benefits.
> >
> > Comments on the PR are welcome.
>
> This has the signifcant critical flag issue. It should at minimum be
> explicitly called out, as I do not know any precendent for this kind of
> behavior (check that some extension is critical yes, but not changing
> meaning of extension depending on critical flag).
>
>
> I watched the presentation and the resulting Q again. Short summary
> of
> relevant stuff:
>
> - The motivation in the slides is to reduce exposure of private keys to
>   memory disclosure vulernabilities, without reducing performance.
> - The orignal proposal was to add a TLS Feature extension value. No
>   discussion.
> - The drawback of "strict mode" would be causing issues with servers
>   that can not effectively switch between certificates.
> - There is question about fallback. Paraphrased answer: LURK.
>
>
> TLS Feature extensions have some really unwnated properties here. They
> are never critical on client side, and they have OR-inheritance. You
> definitely do not want OR-inheritance here.
>
> Well, after this, the best usecase I can come up with strict flag is
> still dealing with LURK endpoints that can not do proof-of-possession
> or format checking[1].
>
>
> [1] TLS 1.2 and 1.3 servers should only ask for signatures and only
> over the following kinds of data:
>
> - <64 bytes> 03 00 17 41 04 <64 bytes>
> - <64 bytes> 03 00 18 61 04 <96 bytes>
> - <64 bytes> 03 00 19 85 04 <132 bytes> (rare, P-521)
> - <64 bytes> 03 00 1A 41 04 <64 bytes> (rare, brainpool)
> - <64 bytes> 03 00 1B 61 04 <96 bytes> (rare, brainpool)
> - <64 bytes> 03 00 1C 81 04 <128 bytes> (rare, brainpool)
> - <64 bytes> 03 00 1D 20 <32 bytes>
> - <64 bytes> 03 00 1E 38 <56 bytes> (rare, X448)
> - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <32 bytes>
> - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <48 bytes>
>
> None of these covers delegated credential signatures, which would
> cause any attempt to ask for DC signature to fail if the format is
> checked..
>
>
>
> -Ilari
>
>
> ___
> TLS mailing list
> TLS@ietf.org
>  

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

[Nick Sullivan]

Martin,

Thanks for the corrections, and thank you others who have reviewed the
patches. I've updated the PRs appropriately.

Nick

On Wed, May 30, 2018 at 6:48 PM Martin Thomson 
wrote:

> I've reviewed changes.  Thanks for writing them up Nick.
>
> Two concerns:
>
> On #26, I think that there is a misunderstanding of how
> signature_algorithms and signature_algorithms_cert work.  My
> understanding is that the former applies to the entire chain, unless
> the latter is present, in which case the latter applies to all
> signatures produced by certificates in the chain other than the end
> entity certificate.  Thus, signature_algorithms entirely governs the
> choice of signature algorithm that is used in TLS itself, whereas
> signature_algorithms_cert (if present) governs the use of signatures
> that are used in building the 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, May 31, 2018 at 11:23 AM Nick Sullivan
>  wrote:
> >
> > I've put together some PRs to address the comments from last call.
> Comments welcome.
> >
> > Failing CertificateVerify due to MITM text:
> > https://github.com/tlswg/tls-exported-authenticator/pull/28
> >
> > Comments from Ben Kaduk:
> > https://github.com/tlswg/tls-exported-authenticator/pull/26
> >
> > Authenticated Denial:
> > https://github.com/tlswg/tls-exported-authenticator/pull/27
> >
> >
> > Nick
> >
> > On Thu, May 24, 2018 at 5:54 PM Martin Thomson 
> wrote:
> >>
> >> Mike just inadvertently (?) discovered a problem with exported
> >> authenticators.
> >>
> >> TLS post handshake authentication provides an authenticated refusal
> when a
> >> certificate can't be found.  It turns out that the current design of the
> >> HTTP/2 CERTIFICATE frame might need to rely on the same capability here.
> >>
> >> The current draft doesn't really say anything about what happens.
> >>
> >> https://github.com/tlswg/tls-exported-authenticator/issues/25
> >>
> >> On Sat, May 12, 2018 at 9:59 AM Nick Sullivan <
> nicholas.sulli...@gmail.com>
> >> 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
> >> think this is a big issue, and prefer 0 because it is a natural way to
> >> terminate a string. If anyone strongly disagrees, please reply to the
> list.
> >>
> >> > Roelof duToit raised a question about middlebox interoperability,
> >> specifically that the exporters will not match if the TLS connection is
> not
> >> end-to-end. There was a subsequent discussion about where to signal this
> >> property. Martin Thomson suggested a signaling mechanism at the
> application
> >> layer (https://github.com/httpwg/http-extensions/issues/617) and Eric
> >> Rescorla suggested that the fact that this could cause CertificateVerify
> >> failures should be called out in the document. I'll put a PR together to
> >> add some helpful text around debugging CertificateVerify failures to
> >> address Eric's suggestion.
> >>
> >> > Ben Kaduk had three points:
> >> > - The certificate_request_context is prone to collisions with
> >> post-handshake authentication and there are different spaces for the
> server
> >> and client context values. He suggested some text in Section 3 and maybe
> >> more explanation in Section 5.2 as well. I’ll put together a PR for
> this.
> >> > - Section 4.1 talks of the length of the exporter value in terms of
> the
> >> length of the
> >> > TLS PRF hash, adding that cipher suites not using TLS PRF have to
> define
> >> a hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I’ll
> put
> >> together a PR to clarify the text around this clarifying that for TLS
> 1.3
> >> cipher suites, the HDKF hash is what is meant.
> >> > - The “signature_algorithms_cert” extension was not incorporated into
> the
> >> draft. I’ll put together a PR for 4.2.1., 4.2.2. and 5.1. to incorporate
> >> this extension.
> >>
> >> > I'll have the proposed changes for the above comments ready next week.
> >>
> >> > There w

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

[Nick Sullivan]

I've put together some PRs to address the comments from last call. Comments
welcome.

Failing CertificateVerify due to MITM text:
https://github.com/tlswg/tls-exported-authenticator/pull/28

Comments from Ben Kaduk:
https://github.com/tlswg/tls-exported-authenticator/pull/26

Authenticated Denial:
https://github.com/tlswg/tls-exported-authenticator/pull/27


Nick

On Thu, May 24, 2018 at 5:54 PM Martin Thomson 
wrote:

> Mike just inadvertently (?) discovered a problem with exported
> authenticators.
>
> TLS post handshake authentication provides an authenticated refusal when a
> certificate can't be found.  It turns out that the current design of the
> HTTP/2 CERTIFICATE frame might need to rely on the same capability here.
>
> The current draft doesn't really say anything about what happens.
>
> https://github.com/tlswg/tls-exported-authenticator/issues/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
> think this is a big issue, and prefer 0 because it is a natural way to
> terminate a string. If anyone strongly disagrees, please reply to the list.
>
> > Roelof duToit raised a question about middlebox interoperability,
> specifically that the exporters will not match if the TLS connection is not
> end-to-end. There was a subsequent discussion about where to signal this
> property. Martin Thomson suggested a signaling mechanism at the application
> layer (https://github.com/httpwg/http-extensions/issues/617) and Eric
> Rescorla suggested that the fact that this could cause CertificateVerify
> failures should be called out in the document. I'll put a PR together to
> add some helpful text around debugging CertificateVerify failures to
> address Eric's suggestion.
>
> > Ben Kaduk had three points:
> > - The certificate_request_context is prone to collisions with
> post-handshake authentication and there are different spaces for the server
> and client context values. He suggested some text in Section 3 and maybe
> more explanation in Section 5.2 as well. I’ll put together a PR for this.
> > - Section 4.1 talks of the length of the exporter value in terms of the
> length of the
> > TLS PRF hash, adding that cipher suites not using TLS PRF have to define
> a hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I’ll put
> together a PR to clarify the text around this clarifying that for TLS 1.3
> cipher suites, the HDKF hash is what is meant.
> > - The “signature_algorithms_cert” extension was not incorporated into the
> draft. I’ll put together a PR for 4.2.1., 4.2.2. and 5.1. to incorporate
> this extension.
>
> > I'll have the proposed changes for the above comments ready next week.
>
> > There were also some uncontroversial suggestions that I propose merging:
> > https://github.com/tlswg/tls-exported-authenticator/pull/21
> > https://github.com/tlswg/tls-exported-authenticator/pull/22
> > https://github.com/tlswg/tls-exported-authenticator/pull/23
> > https://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 Sean Turner  wrote:
>
>
>
> >>> > On Apr 21, 2018, at 10:25, Sean Turner  wrote:
> >>> >
> >>> >
> >>> >> On Apr 19, 2018, at 16:32, Sean Turner  wrote:
> >>> >>
> >>> >> All,
> >>> >>
> >>> >> This is the working group last call for the "Exported Authenticators
> in TLS" draft available at
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.
> Please review the document and send your comments to the list by 2359 UTC
> on 4 April 2018.
> >>> >
> >>> > … 4 May 2018 ...
>
> >>> Just a reminder the WGLC ends tomorrow.
>
> >>> spt
> >>> ___
> >>> TLS mailing list
> >>> TLS@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tls
>
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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
think this is a big issue, and prefer 0 because it is a natural way to
terminate a string. If anyone strongly disagrees, please reply to the list.

Roelof duToit raised a question about middlebox interoperability,
specifically that the exporters will not match if the TLS connection is not
end-to-end. There was a subsequent discussion about where to signal this
property. Martin Thomson suggested a signaling mechanism at the application
layer (https://github.com/httpwg/http-extensions/issues/617) and Eric
Rescorla suggested that the fact that this could cause CertificateVerify
failures should be called out in the document. I'll put a PR together to
add some helpful text around debugging CertificateVerify failures to
address Eric's suggestion.

Ben Kaduk had three points:
- The certificate_request_context is prone to collisions with
post-handshake authentication and there are different spaces for the server
and client context values. He suggested some text in Section 3 and maybe
more explanation in Section 5.2 as well. I’ll put together a PR for this.
- Section 4.1 talks of the length of the exporter value in terms of the
length of the
TLS PRF hash, adding that cipher suites not using TLS PRF have to define a
hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I’ll put
together a PR to clarify the text around this clarifying that for TLS 1.3
cipher suites, the HDKF hash is what is meant.
- The “signature_algorithms_cert” extension was not incorporated into the
draft. I’ll put together a PR for 4.2.1., 4.2.2. and 5.1. to incorporate
this extension.

I'll have the proposed changes for the above comments ready next week.

There were also some uncontroversial suggestions that I propose merging:
https://github.com/tlswg/tls-exported-authenticator/pull/21
https://github.com/tlswg/tls-exported-authenticator/pull/22
https://github.com/tlswg/tls-exported-authenticator/pull/23
https://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 Sean Turner <s...@sn3rd.com> wrote:
>
>>
>>
>> > On Apr 21, 2018, at 10:25, Sean Turner <s...@sn3rd.com> wrote:
>> >
>> >
>> >> On Apr 19, 2018, at 16:32, Sean Turner <s...@sn3rd.com> wrote:
>> >>
>> >> All,
>> >>
>> >> This is the working group last call for the "Exported Authenticators
>> in TLS" draft available at
>> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.
>> Please review the document and send your comments to the list by 2359 UTC
>> on 4 April 2018.
>> >
>> > … 4 May 2018 ...
>>
>> Just a reminder the WGLC ends tomorrow.
>>
>> spt
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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  wrote:
> >>
> >> All,
> >>
> >> This is the working group last call for the "Exported Authenticators in
> TLS" draft available at
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.
> Please review the document and send your comments to the list by 2359 UTC
> on 4 April 2018.
> >
> > … 4 May 2018 ...
>
> Just a reminder the WGLC ends tomorrow.
>
> spt
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 draft we claim that "The
> application layer protocol used to send the authenticator SHOULD
> use TLS as its underlying transport."  This is of course natural --
> why would you be using TLS authenticators if you were not using TLS
> -- but it seems that we would also benefit from saying what
> properties are actually *required* of the channel used to transport
> the authenticator.  (Confidentiality?  Binding to the key material
> of the TLS connection?)
>
> -Ben
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 <nicholas.sulli...@gmail.com>
wrote:

> Martin Thomson raised an issue Github (Issue #5
> <https://github.com/tlswg/tls-exported-authenticator/issues/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 draft to incorporate this suggestion:
> https://github.com/tlswg/tls-exported-authenticator/pull/9
>
> The advantage of this change is that it provides a more explicit binding
> between a request for an authenticator (which includes TLS extensions) and
> the authenticator itself. This change also significantly simplifies the HTTP/2
> Additional Certificates draft
> <https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-04>
> that depends on exported authenticators. I presented this change at IETF
> 100 and there were no objections.
>
> Comments welcome,
> Nick
>
>
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Exported Authenticators proposed change to incorporate authenticator request

[Nick Sullivan]

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 draft to incorporate this suggestion:
https://github.com/tlswg/tls-exported-authenticator/pull/9

The advantage of this change is that it provides a more explicit binding
between a request for an authenticator (which includes TLS extensions) and
the authenticator itself. This change also significantly simplifies the HTTP/2
Additional Certificates draft

that depends on exported authenticators. I presented this change at IETF
100 and there were no objections.

Comments welcome,
Nick
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

After some discussion on Github leading up to IETF 100, we discovered a few
drawbacks of the current draft that can be addressed by the following
change:
https://github.com/tlswg/tls-exported-authenticator/pull/9

The change introduces the concept of an *authenticator request,* which is
based on the CertificateRequest message in TLS. This change is motivated by
the following goals:
- Provide a way to bind authenticators to requests
- Move the certificate and extension selection logic from the application
into the TLS library, where code and logic can be reused

A consequence of this change is that it no longer allows "spontaneous"
client authentication, which did not have a compelling use case to begin
with.

Nick

On Tue, Oct 31, 2017 at 5:46 AM <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   : Exported Authenticators in TLS
>     Author  : Nick Sullivan
> Filename: draft-ietf-tls-exported-authenticator-04.txt
> Pages   : 7
> Date: 2017-10-30
>
> Abstract:
>This document describes a mechanism in Transport Layer Security (TLS)
>to provide an exportable proof of ownership of a certificate that can
>be transmitted out of band and verified by the other party.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-04
>
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Draft RHRD

[Nick Sullivan]

Rich,

I think you're mixing things up a bit. There is no false comparison. I am
not comparing draft-rhrd to the Wireshark option, they are fundamentally
different. I'm comparing draft-rhrd to draft-green. The wireshark option
requires storage of n keys to inspect n connections, both draft-rhrd and
draft-green only require a single master key to inspect n connections.

The Wireshark option is always possible with TLS, it just has scaling
issues. You export the session keys on a connection-by-connection basis
from one of the endpoints and can then use them to decrypt the transcript
after the fact. This is possible with TLS 1.2, TLS 1.3 and every version of
TLS that uses symmetric keys for encryption. This keeps TLS a two-party
protocol, and is my preferred solution to datacenter visibility, and I
assume Stephen's as well. There have been arguments here that this is not a
tenable solution in some environments, but I haven't found them convincing
for the datacenter visibility case.

The other two options, the master key options draft-rhrd and draft-green,
turn TLS into a quasi three-party protocol. Server operators can just
implement draft-green (or a variant thereof that doesn't repeat DH keys,
but instead generates them deterministically) no matter what the IETF says.
It's not prohibited by TLS 1.3 either structurally or by policy. If
datacenter operators want a master key option and there is no standard to
use, they can just implement draft-green and the client will have no idea
this is happening.

Your rejection of the cleartext signal expresses implies a preference for
draft-green over draft-rhrd, not a preference for the wireshark option
over draft-rhrd. Without draft-rhrd, it's likely that draft-green gets
implemented whether it's standardized or not and no client will be able to
opt out or even know that it's happening.

In the situation where draft-green become the de facto standard for key
escrow in TLS, the public debates around national firewalls trying to force
clients to opt into wiretapping will become moot, firewalls won't have to
block users who have the cleartext signal, they'll just force servers to
implement draft-green unbeknownst to users. Users won't have any option, or
any knowledge that servers are using a master key to protect the
confidentiality of their connection and that their security may be lessened
because of it (compared to a Wireshark-type system which is more difficult
to implement at nation-scale due to how many keys you need to manage).
Furthermore, researchers won't be able to measure the prevalence of this
type of technology. With draft-green, civil society goes dark, with
draft-rhrd, there will be public data 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 organizations
> to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with
> non-forward-secret cipher suites
>
>
>
> I think this sets up a false comparison.  Existing TLS 1.3 debugging
> systems – Wireshark – can debug individual TLS sessions with the session
> key information being made available.  This is what the RHRD draft would
> require an organization to do, but it adds the additional signaling that
> the client is willing to allow it. The Wireshark example shows that the
> signaling is not needed.  Servers can unilaterally do it now.
>
>
>
> I maintain that the cleartext signal servers no useful purpose, except to
> provide a mechanism for entities to segregate traffic.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 TLS 1.2 with RSA -> one single key
2) use TLS 1.3 with DH key derived from seed -> one single key (similar to
draft-green)
3) use any version of TLS and export the session keys -> corpus of keys
equal to number of connections

The fundamental assumption of this draft is that that 3) is not feasible
for all enterprises because rearchitecting their systems for a multi-key
escrow is either too costly or that the requirement for TLS 1.3 will come
too soon. Ted Lemon had some convincing arguments earlier about why
enterprises should see this coming and invest in migrating to a model
closer to 3), which will always be possible in a system that uses symmetric
cryptography for encryption. Newer companies like the one mentioned by Tony
Arcieri have managed to architect their systems this way, so it’s not
impossible. Still, it’s usually cheaper to adapt an existing system rather
than re-architect your network (and buy more gear). As long as 2) is
possible, the moving to a model based on 3) is going to be a hard sell.

Given that enterprises would rather be standards-compliant, this draft is a
way to prevent enterprises from just going ahead and implementing 2), and
instead implement something that has similar benefits (a single master key
that can decrypt multiple connections), but with additional safeguards for
the user:
-the ability to opt out
-visibility into the fact that their connection is part of a pool of
connections protected by a single key

You can do neither with 2). This is a win. To Rich’s argument that network
domains will force browsers to implement this by blocking connections that
don’t advertise this support, I disagree. There are no passive firewalls
that I know of that drop TLS connections that don’t support escrow (in the
sense that non PFS-RSA and session ticket keys in TLS 1.2 are escrow).
Shouldn’t these be blocked by the GFW if someone is forcing RSA escrow?

On that note, so what if some browsers opt in? Servers need to also opt-in
to setting visibility keys. These will be visible by the browser, and
visible by network watchdogs. Visibility is good in the situation where
both parties want to be honest, and a dishonest escrow mechanism is
possible. Furthermore, large services that are internet-facing that see
this extension existence can simply disconnect when it's presented,
applying back-pressure in the event of this "escaping" the datacenter.

Until TLS is redesigned so that a single key escrow is not possible,
datacenter operators will choose to do 2). For the next version of TLS, we
should strive to eliminate a the ability for a server to escrow a single
key. I posit that this should be a fundamental design principle for TLS
going forward: *cross-connection secrecy*. Forward secrecy with respect to
the long term certificate key is something that has been addressed in TLS
1.3. Forward secrecy with respect to other keys, like the session ticket
key or other keys that can be generated centrally, are things that need to
be looked at more closely for TLS 1.4 (or whatever’s next).

This draft is an optional extension that allows a client and server to
agree that a single key held by the server should be able to decrypt the
data of multiple connections. I don’t think it’s something that belongs on
the Internet as a whole, but understood it as a lesser of two evils with
respect to the options people have.

To summarize:
- TLS 1.3 allows single-key escrow with no client opt-in by design (because
of ephemeral DH)
- This is something that requires fundamental changes to TLS to fix, but
should be looked into
- Enterprises should look into moving to a model where session keys are
exported to prepare for this eventuality
- draft-rhrd allows clients to opt-in to an extension-based escrow system
that doesn’t abuse the core protocol and it enables network watchdogs to
observe
- having such a system on the internet is a bad idea because it reduces the
security of multiple connections down to a single piece of data
- on the other hand using draft-rhrd is safer than allowing organizations
to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with
non-forward-secret cipher suites

Nick

On Thu, Oct 19, 2017 at 7:26 AM Salz, Rich  wrote:

>
> > I didn’t say easy, I said ‘easier’
> >
> Can you explain how it is easier?
>
> There’s no way to limit it to the use-case it was putatively intended
> for.  We now have a signaling mechanism that says “allow interception.”
> Firewalls can drop connections where the client doesn’t send that
> extension. Therefore they can force only tappable TLS traffic. This makes
> the job easier.
>
> I take it you want to see this draft adopted?

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

[Nick Sullivan]

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 less likely to unintentionally impact the broader
internet if used in the datacenter setting.

Nick

On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms  wrote:

> We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS
> extension defined in this I-D takes into account what we heard from the
> discussion regarding TLS visibility and
> draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides
> an opt-in capability for both the TLS client and server and makes it clear
> on the wire that visibility will be enabled for the session.  The new
> mechanism does not depend on static handshake or session keys.
>
> - Ralph and Russ
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Update on TLS 1.3 Middlebox Issues

[Nick Sullivan]

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 very widely deployed on the
server side. Enabling it by default in a major browser would break enough
of the Internet that both middlebox vendors and enterprises/ISP who use
them will take notice.

The browser vendors will have to do their own calculus around whether or
not the ecosystem benefits of accelerating the deployment of TLS 1.3
compatibility by deploying no-downgrade TLS 1.3 defaults outweigh the
business costs associated with the potential harm to their relationships
with enterprises.

For example, Chrome has a history of making large bets that break a portion
of the internet in order to force ecosystem changes (see SHA-1, SSLv3).
However, these have been projects with gradual changes and long lead times.
Also, the failure rates introduced by such changes were well below 2% of
all connections. Furthermore, these changes typically revolved around
server changes (updating certs, changing configurations) not
software/firmware updates to devices.

I don't want to speak for browser vendors, but history suggests that Option
3) may not be a viable one for browsers with a significant market share.

Nick

On Sat, Oct 7, 2017 at 1:33 PM Yoav Nir  wrote:

> On 7 Oct 2017, at 4:01, Salz, Rich  wrote:
>
> Thanks very much for the update.
>
> There is a third option, name the devices which are known to cause
> problems, and move forward with the draft as-is.
>
>
> +1.  I like this third option.
>
> 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh,
> it's your customers who don't update? Seems you don't have any
> reasonable update system. Call your customers,
>
>
> Vendor: Hello customer. We have an update for you that will make TLS 1.3
> work.
>
> Customer: No way. We’re in the middle of the year-end processing. We’re
> not making any configuration changes until the second week of January.
>
> Vendor: But it’s a simple fix. It will make things work better. You’ll
> need it for Chrome to work with Google.
>
> Customer: What part of “not making any configuration changes” was not
> clear to you!?
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 present? This is similar to the 2014 issue with ECDSA and Chrome on
XP (https://bugs.chromium.org/p/chromium/issues/detail?id=409901), in which
the PKIX library didn't support ECDSA, but the TLS stack did. As long as
TLS and PKIX libraries are decoupled, the dual meaning of the signature
scheme makes the addition of a new algorithm to one or the other a bit
messy.

For example: In the current situation, it is mandatory to support
rsa_pss_sha256, but how many of these clients support certificates signed
with PSS? Not many -- including OpenSSL (
https://github.com/openssl/openssl/issues/2878#issuecomment-328576616).
Without PSS certificate support, if we chose EKR's option 1, these clients
would not be able to support TLS 1.3 according to the spec. This seems like
an unnecessary dependency.

An easy fix would be to use a different extension for PSS certificates, but
this makes the naming and code point definitions more troublesome. Will all
new signature schemes get two codepoints, one for the handshake and one for
the certificate? The other option, EKR's option 2, seems more promising.

This option could be implemented as follows:
- keep the old hash and signature algorithm extension from TLS 1.2 to
indicate certificate signature support
- add a new extension for handshake signature scheme support

This would have the additional advantage of allowing us to clean up some of
the issues that have been raised before on this list around the numbering
of new TLS 1.3 signatureSchemes, specifically the fact that the byte order
is backwards for RSA-PSS relative to existing TLS 1.2 values.

Nick

On Mon, Sep 11, 2017 at 11:43 AM Eric Rescorla  wrote:

> Ugh.
>
> Generally, the idea with signature schemes is that they are supposed to
> reflect both the capabilities of your TLS stack and the capabilities of
> your PKI verifier [0]. So, yes, if you advertise this it is supposed to
> work. So, ideally we would just say that it's as Ilari says in his followup.
>
> It seems like there are really two choices:
>
> 1. Only advertise algorithm X if you support algorithm X in both places
> 2. Invent a new extension whose semantics are "if present, this tells you
> what the PKI validator accepts, otherwise look at signature schemes"
>
> I hate to be suggesting #2 at this stage in the process, but maybe it's
> right anyway...
>
> -Ekr
>
> [0] I recognize that there are people who think that TLS shouldn't say
> anything about the PKI verifier,
> but I don't think that this is viable, for exactly the reason shown here:
> it's possibly to have an algorithm which is widely supported in TLS stacks
> but not in PKI verifiers.
>
>
>
> On Fri, Sep 8, 2017 at 3:59 PM, Peter Wu  wrote:
>
>> Hi!
>>
>> While working on adding RSASSA-PSS support to Go's crypto/tls library
>> (TLS 1.2), I have noticed something that may cause interop problems
>> later.
>>
>>
>> The current draft says the following about Server Certificate Selection
>> (https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.2.2):
>>
>>-  The certificate MUST allow the key to be used for signing (i.e.,
>>   the digitalSignature bit MUST be set if the Key Usage extension is
>>   present) with a signature scheme indicated in the client's
>>   "signature_algorithms" extension.
>>
>> In TLS 1.2, the cipher suite was responsible for selecting the hash
>> function and signature algorithm (e.g. for ServerKeyExchange) while
>> "signature_algorithms" directed what certificate signatures are
>> accepted.  But in TLS 1.3, this also influences what algorithms can be
>> used for signing handshake messages (CertificateVerify).
>>
>> This results in possible interop problem: while implementations
>> advertise RSASSA-PSS support in "supported_algorithms" because they can
>> indeed sign/verify handshake messages with said algorithm, they might
>> not be able to accept certificates with a RSASSA-PSS signature (because
>> the PKI library does not implement it for example). And because PSS
>> certificates are non-existent now, it will only be discovered later.
>>
>> Some implementations I have checked wrt RSASSA-PSS support:
>>  - Go crypto/tls (TLS 1.2) - no RSASSA-PSS yet.
>>  - tls-tris (TLS 1.3) - accepts PSS for CV, but not certificates.
>>  - BoringSSL - failed, "bssl server" rejects cert.
>>  - OpenSSL - failed, s_server rejects cert. Related:
>>https://github.com/openssl/openssl/issues/2878
>>  - NSS - not checked, but I think it has the same problem as tls-tris.
>>Related: https://bugzilla.mozilla.org/show_bug.cgi?id=158750
>>
>> These implementations will require fixing, but at the moment it is just
>> broken. Is this the 

[TLS] TLS Hackathon in Singapore

[Nick Sullivan]

I just added a TLS section to the hackathon wiki for IETF 100 (
https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100hackathon).
There are currently three main goals:

   - TLS 1.3 draft 21 testing and interop
   - Implementation in applications (wget)
   - Implementation 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

[Nick Sullivan]

Thomas,

Thanks for your comments. Let me see if I can summarize them:

- A disadvantage of delegated credentials vs short-lived certs is that it
requires client opt-in. This is also a disadvantage of proxy certificates.
If client support is below 100%, a LURK-type system may be required to keep
long-term private keys off TLS termination endpoints.
- A disadvantage of delegated credentials is that it requires software
updates on both client and server. This is also a disadvantage of proxy
certificates. I think this is covered by my point below: "Short lived certs
work with existing libraries, no new code changes."
- An advantage of short-lived certificates is that there is an audit log by
a third party (either the CA's internal logs and optionally Certificate
Transparency logs).

I should state that short-lived certificates are possible right now and
it's supported by some CAs, though not necessarily at the scale needed to
provide, say, a unique 7-day certificate for each server of a large
Internet company. This draft's advantages apply most strongly to
organizations who don't want to tie their ability to have functional TLS on
the ability for CAs to maintain high-availability issuance services.  How
much Delegated Credentials can be rotated and diversified inside an
organization is only limited by the operational ability of the organization
that has control of the EE private key.

Nick

On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) <
thomas.foss...@nokia.com> wrote:

> Hi Nick,
>
>
>
> I am not against delegated credentials, in fact I think it’s a good thing
> per se.
>
>
>
> I had expressed a couple of concerns at the time the call for adoption was
> first issued [1], which I think 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 behalf of Nick Sullivan" <
> tls-boun...@ietf.org on behalf of nicholas.sulli...@gmail.com> wrote:
>
>
>
> 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 the pros
> and cons of the approaches:
>
> *Proxy certificates vs. Delegated Credentials*
>
> *Pro proxy certificates*:
>
> - Already deployed in some industries, though not on the Web.
>
> - Fits the conceptual model that public key == certificate.
>
> *Con proxy certificates*:
>
> - Proxy certificates adds additional complexity to the delegation other
> than limiting the time period (full X.509, additional constraints  such as
> hostname).
>
> - Encourages implementers to reuse PKIX libraries rather than build code
> as part of TLS:
> -- There have been problems and inconsistencies around pathlen and
> constraints enforcement in existing PKIX libraries.
> -- Modifying these libraries is more complex and risk prone than delegated
> creds (which can easily be implemented in TLS as demonstrated by the 3
> interoperable implementations at the IETF 98 hackathon).
>
> - In proxy certificates, pathing is SKI dependent, not directly tied to EE
> cert. This is a binding weaker than delegated credentials which includes a
> signature over the EE certificate.
>
>
>
> *Short-lived certs vs. Delegated Credentials*
>
> *Pro short-lived certs*:
>
> - Short lived certs work with existing libraries, no new code changes.
>
> *Con short-lived certs*:
>
> - Not widely available from CAs, especially for EV.
>
> - Potentially problematic to the CT ecosystem (all certificates must be
> logged in CT, which may bloat them).
>
> - Introduces a high-risk operational dependency on external party:
> -- Requires frequent exchanges with an external Certificate Authority
> (must provide proof of domain possession to CA vs. internally managed
> credential minter for delegated credentials).
>
> -- There is no fallback if the CA has outage. With delegated credentials
> you can fall back to a LURK-style protocol with the long-lived certificate
> key.
>
>
>
> Given these comparisons, we think the proposed draft is the superior
> option and would like to continue the discussion about adopting it.
>
>
>
> Nick
>
>
>
> On Fri, May 19, 2017 at 12:58 AM Sean Turner <s...@sn3rd.com> wrote:
>
> All,
>
> During the WG call for adoption, a couple of questions were raised about
> comparison/analysis of sub-certs versus proxy and/or short-lived

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

[Nick Sullivan]

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 certificates must be
> logged in CT, which may bloat them).
>
> That's a browser policy, not an IETF requirement, right?
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 the pros
and cons of the approaches:


*Proxy certificates vs. Delegated Credentials*
*Pro proxy certificates*:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
*Con proxy certificates*:
- Proxy certificates adds additional complexity to the delegation other
than limiting the time period (full X.509, additional constraints  such as
hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as
part of TLS:
-- There have been problems and inconsistencies around pathlen and
constraints enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated
creds (which can easily be implemented in TLS as demonstrated by the 3
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE
cert. This is a binding weaker than delegated credentials which includes a
signature over the EE certificate.

*Short-lived certs vs. Delegated Credentials*
*Pro short-lived certs*:
- Short lived certs work with existing libraries, no new code changes.
*Con short-lived certs*:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be
logged in CT, which may bloat them).
- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must
provide proof of domain possession to CA vs. internally managed credential
minter for delegated credentials).
-- There is no fallback if the CA has outage. With delegated credentials
you can fall back to a LURK-style protocol with the long-lived certificate
key.

Given these comparisons, we think the proposed draft is the superior option
and would like to continue the discussion about adopting it.

Nick

On Fri, May 19, 2017 at 12:58 AM Sean Turner  wrote:

> All,
>
> During the WG call for adoption, a couple of questions were raised about
> comparison/analysis of sub-certs versus proxy and/or short-lived
> certificates.  There is some discussion currently in the draft, but the
> chairs feel that these issues need further discussion (and elaboration in
> the draft) prior to WG adoption.  So let’s keep the conversation going.
>
> J
>
> > On Apr 12, 2017, at 15:31, Sean Turner  wrote:
> >
> > All,
> >
> > At our IETF 98 session, there was support in the room to adopt
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on the
> list so please let the list know whether you support adoption of the draft
> and are willing to review/comment on the draft before 20170429.  If you
> object to its adoption, please let us know why.
> >
> > Clearly, the WG is going to need to work through the trade-offs between
> short-lived certificates and sub-certs because both seem, to some, to be
> addressing the same problem.
> >
> > Cheers,
> >
> > J
> >
> > [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 vulnerability
https://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html
and CVE-2017-8932). Furthermore, many post-quantum key exchange mechanisms
cannot be secured with repeated key shares (SIDH is one example).

Encouraging (or worse, standardizing) the repeated use of a key share seems
risky and shortsighted.

For this reason, and the fact that there are alternative techniques to
achieve the same goals (put the symmetric key material in a serverhello
extension encrypted with an exfiltration key, for example), I don't think
this proposal should be considered. If alternative proposals come are
presented that don't require key shares to be reused, I am not against
discussing them.

Nick

On Sat, Jul 15, 2017 at 10:16 AM Dobbins, Roland  wrote:

>
>
> > On Jul 15, 2017, at 16:05, Dobbins, Roland  wrote:
> >
> > There is plenty of information on these topics available on the Internet
> today.
>
> At the risk of self-replying, it should also be noted that highly
> informative discussions of these challenges, & detailed presentations
> thereof, have taken place in WG meetings at previous IETF meetings.
>
> There has also been ample time since those discussions & presentations to
> gain additional understanding & insight.
>
> ---
> Roland Dobbins 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 server and client must explicitly opt-in
2) A third party should be able to tell whether or not this feature is
enabled by observing the stream

These two requirements protect services on the wider Internet from being
accidentally (or surreptitiously forced to be) subject to unauthorized
decryption. The static DH proposal satisfies neither of the above
requirements.

What you likely want is something similar to TLS 1.2 session tickets with
centrally managed session ticket keys. The client would advertise support
for "passive session decryption" in an extension and the server would
return an unencrypted extension containing the session keys encrypted by a
server "passive decryption key". The passive decryption key would be
managed in the same way as the static DH key in this draft: rotated
frequently and synchronized centrally.

A TLS 1.2 session ticket-like scheme provides the same semantics as this
static DH but provides more safeguards against accidental use outside the
datacenter. Both client and server need to opt in, it's visible from the
network, and limits the data visible to the inspection service to the
session (rather than exposing the master secret which can be used to
compute exporters and other things outside of the scope of session
inspection). Furthermore, in the session ticket-like scheme, a *public
key *could
be used to encrypt the session keys, removing the need for a secure
distribution scheme for the endpoints. The passive decryption private key
could me managed in a secure location and only the public key distributed
to the endpoints.

Session ticket-like scheme advantages vs this static DH proposal:
1) Mandatory client opt-in
2) Passive indication that scheme is being used
3) Decryption service only gets session keys, not master secret
4) No need for private distribution system for static keys to endpoints

In summary, even if this was to be considered as a working group document,
I think this is the wrong solution to problem.

Nick

On Fri, Jul 7, 2017 at 8:03 AM Matthew Green 
wrote:

> The need for enterprise datacenters to access TLS 1.3 plaintext for
> security and operational requirements has been under discussion since
> shortly before the Seoul IETF meeting. This draft provides current thinking
> about the way to facilitate plain text access based on the use of static
> (EC)DH keys on the servers. These keys have a lifetime; they get replaced
> on a regular schedule. A key manager in the datacenter generates and
> distributes these keys.  The Asymmetric Key Package [RFC5958] format is
> used to transfer and load the keys wherever they are authorized for use.
>
> We have asked for a few minutes to talk about this draft in the TLS WG
> session at the upcoming Prague IETF. Please take a look so we can have a
> productive discussion.  Of course, we're eager to start that discussion on
> the mail list in advance of the meeting.
>
> The draft can be found here:
>
> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01
>
> Thanks for your attention,
> Matt, Ralph, Paul, Steve, and Russ
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Exported Authenticators proposed updates

[Nick Sullivan]

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 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.
> > https://github.com/grittygrease/tls-exported-authenticator/pull/20
>
> Supporting certificates that are not X.509 actually brings major
> complications in protocol like this. The TLS library must
> recognize those types in order to properly extract the key
> needed to verify the CertificateVerify. The type extension can't
> just be skipped.
>
>
> Also, for related reasons, when implementing client certificates
> in TLS library I am working on, I only implemented X.509, despite the
> library supporting authentication based on keys, and RPK being
> supported for server authentication. The reason for this was the
> pretty nasty interaction of certificate types with client
> certificates.
>

> > Relax requirement for the certificate_request_context to be unique,
> clarify
> > the benefits of doing so.
> > https://github.com/grittygrease/tls-exported-authenticator/pull/18
>
> Might also note unpredictability. And then note what happens if
> uniqueness (replays of the same certificate) or unpredictability
> (pregenerating responses) fails. Neither seems catastrophic (unlike,
> say repeating a nonce in AEAD).
>
> After all, the certificate contexts in TLS 1.3 discuss
> unpredictability.
>

Good comment. I added some text to reflect this.

>
> > Be more explicit about how signature schemes are chosen and supported.
> > https://github.com/grittygrease/tls-exported-authenticator/pull/18
>
> This seems to be only place where non-standard APIs are required from
> the TLS library itself (I don't think most TLS APIs that do have
> exporters and EMS indication have facility to obtain the list of
> algorithms supported).
>

For this API, the server needs to know which signature algorithms the
client supports and use that to make the correct choice of certificate. The
signature schemes will have to be available already for servers to do
dynamic certificate selection, so I don't see this as a big ask.


>
> And the client side is supposed to have a call for obtaining the
> supported algorithms anyway.
>
> Why not always operate on TLS 1.3 semantics, regardless of transport
> version? Main implications would be always using PSS with RSA and
> not mixing ECDSA curves and hashes.
>

This would simplify the logic substantially. I don't see any problems with
eliminating PKCS#1 1.5 altogether. I have updated the PR.


>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Exported Authenticators proposed updates

[Nick Sullivan]

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.
https://github.com/grittygrease/tls-exported-authenticator/pull/20

Relax requirement for the certificate_request_context to be unique, clarify
the benefits of doing so.
https://github.com/grittygrease/tls-exported-authenticator/pull/18

Be more explicit about how signature schemes are chosen and supported.
https://github.com/grittygrease/tls-exported-authenticator/pull/18

Modify handshake context to be asymmetrical with respect to client and
server.
https://github.com/grittygrease/tls-exported-authenticator/pull/15


Let me know if there are any objections. If there are no comments I'll
merge the changes and publish a new draft.

Nick
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

Ben,

Thanks for pointing that out, you are right. A client is jointly
authoritative if there was in-handshake client auth followed by a
post-handshake client auth. Subsequent client authentications can be
computed in any order and are disambiguated by the context id.

Nick

On Tue, May 23, 2017 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 sequence of authentications would result in a connection
> in which the party could say they were jointly authoritative a over
> multiple identities. In exported authenticators, the only state that is
> signed comes from the original handshake, so there's no way to order them.
> Each exported authenticator is tied to the connection, but not tied
> directly to another authenticator, and therefore there is no proof that the
> party is "jointly authoritative". I welcome text changes to make this more
> clear.
>
>
> I thought at least for "normal" post-handshake auth, the handshake hash
> used was always just the initial handshake, and did not include
> intermediate certificates that had been transmitted.
>
> -Ben
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 connection state. It mirrors TLS 1.3 post-handshake authentication.
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 sequence of authentications would result in a connection
in which the party could say they were jointly authoritative a over
multiple identities. In exported authenticators, the only state that is
signed comes from the original handshake, so there's no way to order them.
Each exported authenticator is tied to the connection, but not tied
directly to another authenticator, and therefore there is no proof that the
party is "jointly authoritative". I welcome text changes to make this more
clear.
4) We can add the prefix in the next draft, thanks for the note.

On Tue, May 23, 2017 at 12:40 PM Watson Ladd  wrote:

> Dear all,
>
> I don't think this design needs to be as complex as it is. Why isn't
> signing a party-dependent (server or client) exporter with the key of the
> certificate, and then appending the certificate chain, enough? I am fairly
> certain this gets the properties we need.  Further, the language around
> jointly authoritative remains very opaque to me.
>
> My other (much more minor) comment is that exporters labels should start
> with "EXPORTER" in RFC 5705, and I don't see why this draft shouldn't do
> it.
>
> Sincerely,
> Watson Ladd
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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

On Tue, Apr 18, 2017 at 8:29 AM Victor Vasiliev  wrote:

> I've read the draft, and I support its adoption.  I believe that the
> mechanism
> is sound for its stated use.
>
> I have some minor concerns about the wording in the draft, though.  First,
> the
> draft describes the authenticators as sent "out-of-band", while my
> understanding is that they are always intended to be sent in-band as
> application data.  If they were truly sent out-of-band, there would be some
> questions about the security analysis, because that would imply those
> could be
> sent unprotected.  Hence, I suggest the draft to adapt the premise that
> exported authenticators MUST be sent as application data within the same
> connection.  This might simplify your security proofs too.
>
> The second issue I have is with the question of when does authentication
> succeed.  In TLS, by the time any party can send application data, normally
> (with exception of server-to-client data in client auth case) both parties
> know
> that the other side has authenticated them.  Here, a new identity is
> introduced
> while application data can be already in flight, and it's not clear to me
> when
> the sender of the exported authenticator can act assuming the peer has
> accepted
> its new identity.  My current understanding is that this issue is deferred
> to
> the application layer, but it would be nice to discuss those considerations
> explicitly.
>
> The last question I have is how does this interact with the state of TLS
> connection.  Does accepting a new identity mean that the entire connection
> now
> has that identity too?  Does this mean that the session tickets issued
> after
> the library receives the authenticator are valid for the new identity?
> Does it
> make the tickets sent previously on that connection valid for the new
> identity?
>
> Also, what is the distinction between "jointly authoritative for A and B"
> and
> "individually authoritative for A and individually authoritative for B"?
>
>   -- Victor.
> On Fri, Apr 14, 2017 at 12:29 AM, Joseph Salowey  wrote:
>
>> Hey Folks,
>>
>> At the IETF 98 meeting in Chicago there was support in the room to adopt
>> draft-sullivan-tls-exported-authenticator [0]. We are looking for
>> feedback on adopting this draft form the list. Please respond if you
>> support the draft and are willing to review it. If you object to its
>> adoption, please let us know why. Please respond to the list by 20170501
>>
>> Cheers,
>>
>> J
>>
>> [0]
>> https://datatracker.ietf.org/doc/html/draft-sullivan-tls-exported-authenticator
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 in the room to
> adopt
> > > draft-sullivan-tls-exported-authenticator [0]. We are looking for
> feedback
> > > on adopting this draft form the list. Please respond if you support the
> > > draft and are willing to review it. If you object to its adoption,
> please
> > > let us know why. Please respond to the list by 20170501
> > >
> >
> > Looking at the draft and reviewing it:
>
> Another edge-case I figured:
>
> How do certificate type extensions (#9, #19 and #20) work with exported
> authenticators?
>
> Where other extensions are either meaningless or are edditional info,
> certificate types actually change the format of the first certificate,
> which the library needs to understand in order to extract the SPKI for
> validating the following CertificateVerify.
>

I think it would be fair to only support server-generated exported
authenticators with the certificate_type negotiated by the TLS handshake.
If the client sent a list of server_certificate_types in its client hello,
then only authenticators of that type can be used (with the chosen type
included an extension to the certificate message). Similarly, if the
server's EE message contains a single client_certificate_type, that would
be the only type supported by client-generated exported authenticators. I
can add text to this effect (
https://github.com/grittygrease/tls-exported-authenticator/issues/12).


>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph Salowey wrote:
> > Hey Folks,
> >
> > At the IETF 98 meeting in Chicago there was support in the room to adopt
> > draft-sullivan-tls-exported-authenticator [0]. We are looking for
> feedback
> > on adopting this draft form the list. Please respond if you support the
> > draft and are willing to review it. If you object to its adoption, please
> > let us know why. Please respond to the list by 20170501
> >
>
> Looking at the draft and reviewing it:
>
> - Section 1:
>
> The section should also say a bit why not to use post-handshake
> authentication. Which is not available at all for server, won't
> work properly with multiplexed connections, etc...
>
Can do.

>
> - Section 2:
>
> Probable typo: "encryped" (in last line of first paragraph on page 3).
>
Fixed.

>
> - Section 2:
>
> I think there should be "(for TLS 1.3)" after reference to the TLS 1.3
> draft in definition of handshake context. Otherwise it will read oddly
> after draft reference gets replaced by reference to the RFC.
>
Good catch.

>
> - Section 2:
>
> I think the finished MAC key length should always follow the PRF hash.
> TLS 1.2 with EMS requires well-defined PRF hash anyway, and some cipher-
> suites have SHA-1 as HMAC hash.
>
This was noted before. It's tracked as issue #7 (
https://github.com/grittygrease/tls-exported-authenticator/issues/7)


>
> - Section 2
>
> I think giving random number as example of request context is bad,
> and one should instead give some sequence number (with possible gaps)
> as example.
>
> These things do not have to be random, and generating sequence
> numbers in connection context is much easier than random numbers.
>
Ok.


>
> - Section 2:
>
> The spec should be clear if message headers are included or not (the
> hashes seem injective either way).
>
> If message headers are included, perhaps wrap the context into
> synthethic hash message like with first CH when retrying handshake in
> TLS 1.3. One could even reuse the message type (#254).
>
The text uses a plain Hash, not a Transcript-Hash, so there should be no
confusion about including message headers. What is the motivation for
incorporating message headers?


>
> - Section 4:
>
> Nitpick: The framework is usually called SIGMA, not SIGMAC (reference).
>

The reference here is to the 2016 paper which describes the SIGMA Compiler,
which I've seen referenced as SIGMAC, vs. the original SIGMA paper.

>
> - Section 4:
>
> The last two security considerations look pretty hard to understand,
> and overly long.
>
> As I understand it, those paragraphs mean something like:
>
> --
> Authenticators are independent and unidirectional, and as consequence:
>
>  * It is difficult to formally prove an endpoint is jointly
>authoritative over multiple certificates instead of individually
>authoritative over each.
>
>  * There is no feedback on if authenticator was processed, at what
>point of connection it was processed nor if it was accepted. Any
>such feedback needs to be implemented at application layer.if
>required.
> --
>
> (As note, the TLS-built-in authentication fails most of the second
> part as well, for various reasons.
>

Yes, it was hard to read. Thanks for the summary, I've re-written it to be
more clear in the PR.

>
>
> - Section 4:
>
> Perhaps add consideration that this SHOULD be implemented inside TLS
> library (or at least as an library), even if it is possible to implement
> outside it.
>

 Updated text.

>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

Hi Brian,

Thanks for your comments. Answers inline.

On Mon, Mar 13, 2017 at 8:13 PM Brian Sniffen <bsnif...@akamai.com> wrote:

> Can you help me understand what this means?
>
>   servers that are authoritative for multiple domains the same
>   connection but do not have a certificate that is simultaneously
>   authoritative for all of them
>
> I'm sure there's a word or two missing between "domains" and "the" in
> the first line, but I'm not sure what they are.
>

This should be:
servers that are authoritative for multiple domains but do not
have a certificate that is simultaneously authoritative for all of them

A common example is an HTTPS reverse proxy that sits in front of
domain1 and domain2, has a certificate for each, but not a single
certificate
that covers both.


>
> More generally, it's great to see a replacement for renegotiation.  Can
> you expand (maybe just here?) on the last paragraph of the security
> considerations?  I think you mean that the sender of an authenticator
> can't tell when it was received & understood.  But I'm not sure the
> receiver can tell when it was sent---say, in the case of a smartcard
> insertion, or access to a key from satisfying some local attestation
> scheme, whether that key access precedes or follows the sending of a
> request.
>

The application protocol can and should do the accounting for which
exported authenticators are created and when they are accepted.
The authenticating application can choose its own context id when
creating the authenticator and the reciever can use it to map the opaque
blob back to the same context id.

Here's a simple example:
- Party 1 creates an authenticator A1 = authenticate(id1, cert chain, key)
- Party 1 sends A1 to Party 2 as part of the application protocol (say as
an H2 frame)
- Party 2 receives and validates A1, obtaining id1 and cert chain
- Party 2 sends back an ACK message such as (id1, valid) at the Application
layer.

At this point, both parties know the authentication 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
>
> Nick Sullivan <nicholas.sulli...@gmail.com> writes:
>
> > 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 cryptographic soundness of the construction.
> >
> > Nick
> >
> > On Tue, Jan 3, 2017 at 8:59 PM Joseph Salowey <j...@salowey.net> wrote:
> >
> >> There seemed to be support for
> draft-sullivan-tls-exported-authentication
> >> (
> https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00)
> >> in Seoul.   Since there has not been much discussion of this draft on
> the
> >> list we are giving the working group a chance to review the draft before
> >> calling for adoption later this month.
> >>
> >> Cheers,
> >>
> >> J
> >> ___
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >>
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> --
> Brian Sniffen
> Akamai Technologies
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 cryptographic soundness of the construction.

Nick

On Tue, Jan 3, 2017 at 8:59 PM Joseph Salowey  wrote:

> There seemed to be support for draft-sullivan-tls-exported-authentication
> (https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00)
> in Seoul.   Since there has not been much discussion of this draft on the
> list we are giving the working group a chance to review the draft before
> calling for adoption later this month.
>
> Cheers,
>
> J
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 TLS 1.3.
>
>
>
> I hope all other three options (TLS 2.0, TLS 2 and TLS 4) will make
> confusion with SSL versions for end user.
>
>
> --
>
> Raja Ashok VK
> 华为技术有限公司 Huawei Technologies Co., Ltd.
> [image: image001.jpg]
>
> Phone:
> Fax:
> Mobile:
> Email:
> Huawei Technologies Co., Ltd.
> Bangalore, India
>
> http://www.huawei.com
> --
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not 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!
>
>
>
>
>
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner
> Sent: 18 November 2016 07:43
> To: 
> Subject: [TLS] Confirming consensus: TLS1.3->TLS*
>
>
>
> At IETF 97, the chairs lead a discussion to resolve whether the WG should
> rebrand TLS1.3 to something else.  Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf
> .
>
>
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to not
> rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this decision
> on the list so please let the list know your top choice between:
>
>
>
> - Leave it TLS 1.3
>
> - Rebrand TLS 2.0
>
> - Rebrand TLS 2
>
> - Rebrand TLS 4
>
>
>
> by 2 December 2016.
>
>
>
> Thanks,
>
> J
>
> ___
>
> TLS mailing list
>
> TLS@ietf.org
>
> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 positive message of progression, rather than
embody a condescending message such as "we gave it this name because people
aren't able to understand that TLS 1.3 is newer than SSL 3". It will also
immediately make sense to people who were exposed to the marketing around
Windows 7.

Without this framing, TLS 4 (or 4.0) will seem like a confusing choice.

(for the record, I'm still for TLS 1.3)

On Fri, Nov 18, 2016 at 11:13 AM Sean Turner  wrote:

At IETF 97, the chairs lead a discussion to resolve whether the WG should
rebrand TLS1.3 to something else.  Slides can be found @
https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf
.

The consensus in the room was to leave it as is, i.e., TLS1.3, and to not
rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this decision
on the list so please let the list know your top choice between:

- Leave it TLS 1.3
- Rebrand TLS 2.0
- Rebrand TLS 2
- Rebrand TLS 4

by 2 December 2016.

Thanks,
J
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

<https://tools.ietf.org/html/
<https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>
draft-sullivan-tls-exported-authenticator-00>
<https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>

I just posted a new Internet-Draft called "Exported Authenticators in TLS"
in the TLS working group.

The intent of this draft is to enable participants in a TLS connection to
prove ownership of additional certificates. This differs from previous
proposals (https://tools.ietf.org/html/draft
-sullivan-tls-post-handshake-auth-00) in that these proofs are not sent as
part of the TLS connection, but instead exported so that they can be sent
out of band (as part of an application layer message, for example).

This proposal should enable a radical simplification of the Secondary
Certificate Authentication in HTTP/2 proposal (
https://tools.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)

[Nick Sullivan]

The major thing that this proposal achieves is that it makes post-handshake
auth an optional part of the implementation. Instead of this, I would also
be in favor of a simpler change that modifies the text to say that
post-handshake CertificateRequest messages are fatal by default and only
permitted if the application permits their use in a given context (say if
the application is HTTP 1.1, only directly after requests).

Embedded implementations may choose to simply fail on unexpected
CertificateRequests, and that way not have to implement any code around
post-handshake finished messages or updating the transcript when one
arrives.

This default wording should also apply to other types of post-handshake
messages, though NST and KU could be exceptions that should always be
supported and non-fatal.


On Tue, Oct 11, 2016 at 9:37 AM Hannes Tschofenig <hannes.tschofe...@gmx.net>
wrote:

> Hi Nick,
>
> given my discussion with Martin in this thread
> https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like
> your idea of making the post-handshake messages optional since it allows
> me to develop a TLS 1.3 client that is smaller in code 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 explicit by adding a new
> > post_handshake extension to TLS 1.3.
> >
> > Supporting all types of post-handshake messages can require extra
> > complexity and logic, even when the features that these messages enable
> > are not needed. Some types of connections/implementations don't need to
> > support key updates (some unidirectional connections), session tickets
> > (pure PSK implementations) and post-handshake client auth (most
> > browsers). These are all currently SHOULDs in the spec and they don't
> > need to be.
> >
> > In order to simplify the logic around dealing with post-handshake
> > messages, this proposal makes support for each of these modes explicit
> > via a new handshake extension. This change also makes the path to
> > introducing other types of post-handshake messages in future drafts more
> > explicit.
> >
> > PR:
> > https://github.com/tlswg/tls13-spec/pull/676
> >
> > Nick
> >
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
>
___
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)

[Nick Sullivan]

I agree that "I don't like NST or KU" is not a very useful thing to add to
the spec. I added them as part of a general move towards clarity and
conservatism about which types of post-handshake messages are permissible
in TLS 1.3. Right now the spec is ambiguous about what each side of the
connection is supposed to do when it receives an unexpected or unknown
post-handshake message. This change hopefully makes it crystal clear: any
post-handshake message that wasn't agreed upon by both parties should be
fatal.

David suggested that the behavior with respect to post-handshake messages
should be negotiated at the application layer. This also seems reasonable,
but I worry about how this policy would be communicated from the
application layer to the TLS stack. Would the application layer be alerted
of incoming CertificateRequests and either terminate the connection or
reply with an empty certificate and finished message? If we want to support
"2018" post-handshake messages, will we just end up re-inventing this
post_handshake extension in a later draft to advertise support? Different
post-handshake messages have different uses, so I see how this more
case-by-case application-dependent policy could be more expressive than
what I proposed, but I worry we may end up with something more complex than
necessary.

In any case, post-handshake authentication as currently described is
problematic. I'd be open to seeing a text change along the lines of what
David proposed instead of the wire change I'm proposing as long as it
includes some guidance around how it should interact with policies from the
application layer.



On Sat, Oct 8, 2016 at 9:55 AM Eric Rescorla <e...@rtfm.com> wrote:

> I could go either way on this. It seems like this pushes complexity from
> the client to the server.
>
> Consider the case of NST. Presently, a client which doesn't want
> resumption can just ignore NST,
> but in your proposed change, the server needs to read this extension and
> then conditionally send
> NST, and the client still needs the logic to detect unexpected handshake
> messages and abort
> on them.
>
> As I said, I could go either way, and I do think it's potentially useful
> to be able to say "I won't do
> post-handshake client auth" and even more useful to be able to say "I
> would do post 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
> > wrote:
>
> I'm not proposing any new post-handshake authentication mechanisms or
> anything relating to HTTP/2 renegotiation in this change. I'm simply making
> support for the existing post-handshake messages optional.
>
> With this change, if the client does not opt in, unexpected
> CertificateRequests are fatal to the connection. Same with unexpected
> KeyUpdates and SessionTickets. This will hopefully reduce the complexity of
> TLS 1.3 implementations that don't need these features.
>
> Nick
>
> On Sat, Oct 8, 2016 at 8:06 AM David Benjamin <david...@chromium.org>
> wrote:
>
> On Sat, Oct 8, 2016 at 5:03 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 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 require extra
>
> > complexity and logic, even when the features that these messages enable
> are
>
> > not needed. Some types of connections/implementations don't need to
> support
>
> > key updates (some unidirectional connections), session tickets (pure PSK
>
> > implementations) and post-handshake client auth (most browsers). These
> are
>
> > all currently SHOULDs in the spec and they don't need to be.
>
>
>
> Post-handshake authentication is the only one of these that is genuinely
>
> annoying. This is because you can't even reject it without a MAC, that
>
> additionally continues the handshake hash.
>
>
>
> KeyUpdate is rather simple, and NST can just be ignored (leading to some
>
> waste in bandwidth).
>
>
> Yeah, after the fix to how KeyUpdate is acked, I don't think we'd have
> problems with either of the way, while post-handshake auth is indeed
> horrific.
>
>
>
> Furthermore, the post-handshake authentication mechanism doesn't look t

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

[Nick Sullivan]

I'm not proposing any new post-handshake authentication mechanisms or
anything relating to HTTP/2 renegotiation in this change. I'm simply making
support for the existing post-handshake messages optional.

With this change, if the client does not opt in, unexpected
CertificateRequests are fatal to the connection. Same with unexpected
KeyUpdates and SessionTickets. This will hopefully reduce the complexity of
TLS 1.3 implementations that don't need these features.

Nick

On Sat, Oct 8, 2016 at 8:06 AM David Benjamin <david...@chromium.org> wrote:

> On Sat, Oct 8, 2016 at 5:03 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 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 require extra
>
> > complexity and logic, even when the features that these messages enable
> are
>
> > not needed. Some types of connections/implementations don't need to
> support
>
> > key updates (some unidirectional connections), session tickets (pure PSK
>
> > implementations) and post-handshake client auth (most browsers). These
> are
>
> > all currently SHOULDs in the spec and they don't need to be.
>
>
>
> Post-handshake authentication is the only one of these that is genuinely
>
> annoying. This is because you can't even reject it without a MAC, that
>
> additionally continues the handshake hash.
>
>
>
> KeyUpdate is rather simple, and NST can just be ignored (leading to some
>
> waste in bandwidth).
>
>
> Yeah, after the fix to how KeyUpdate is acked, I don't think we'd have
> problems with either of the way, while post-handshake auth is indeed
> horrific.
>
>
>
> Furthermore, the post-handshake authentication mechanism doesn't look to
>
> be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants,
>
> And there are serious questions about how it should interact with
>
> applications.
>
>
> An extension also doesn't really capture things if we intend for, say,
> this to be used for legacy protocols like HTTP/1.1 (where we don't have as
> rich a framing layer) but not HTTP/2 (where we do and can use it as a
> substrate for all this silliness). I was anticipating that, if this ends up
> being used in the HTTP world like renego is, it would be like our renego
> stuff: off by default, forbidden in HTTP/2, and with all interleave
> forbidden.
>
> Further, what useful thing could a server even do with this extension?
> Decline to do post-handshake auth doesn't work. Either the application
> protocol doesn't use post-handshake auth (please pick this one) or it does.
> One doesn't need to send a client_writes_first extension in HTTP/1.1.
>
> Post-handshake auth another knob on the TLS <-> application protocol
> boundary. This means each application protocol must specify for itself what
> post-handshake auth means: what to do with the context field, when it may
> be received, what it does to application flow, etc. Then the spec must be
> clear that if the application protocol does not opt in, CertificateRequest
> is forbidden. A CertificateRequest at an unexpected point (say, half-way
> through a HTTP/1.1 body) is also forbidden. Also make it clear this is for
> legacy protocols and new ones do not use it.
>
> This is analogous to how HTTP/2 forbids renego at the spec level. (TLS 1.2
> got the "defaults" for renego wrong.) No one ever wrote down the exact
> rules for the client-auth/renego hack in HTTP/1.1, but whatever spec does
> this for post-handshake auth should do the same for renego.
>
> It is a lot of spec work for such a tiny-seeming feature, but this is
> consistent with how messy the feature actually is.
>
> David
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Sullivan]

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 require extra
complexity and logic, even when the features that these messages enable are
not needed. Some types of connections/implementations don't need to support
key updates (some unidirectional connections), session tickets (pure PSK
implementations) and post-handshake client auth (most browsers). These are
all currently SHOULDs in the spec and they don't need to be.

In order to simplify the logic around dealing with post-handshake messages,
this proposal makes support for each of these modes explicit via a new
handshake extension. This change also makes the path to introducing other
types of post-handshake messages in future drafts more explicit.

PR:
https://github.com/tlswg/tls13-spec/pull/676

Nick
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls