Re: [TLS] ESNI Android Implementation

[Stephen Farrell]

Sorry, I had meant to reply to this but forgot...

On 13/02/2020 21:34, Nick Sullivan wrote:
> 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.

I agree with Nick.

If you did want to play with draft-02 code on android,
then you could see if my fork of openssl [1] works. It
has support for drafts -02 to -04.

There is a CI setup that builds it for android but it
hasn't really been tested ever. Happy to help if that
was of interest.

Cheers,
S.

[1] https://github.com/sftcd/openssl/

> 
> 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&T 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
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] New direction for TLS?

[Michael D'Errico]

Hi,

It's been a long time since I posted to this list but saw that the charter is 
being updated and wanted to share an idea I had a while ago but have not found 
the time to work on.  The TL;DR is to deprecate TLS and rebuild security on top 
of DTLS. With DTLS, you have encrypted packets, so think of them as the new IP 
and build TCP on top of that.  It'd be like making the internet run on TCP/DTLS 
instead of TCP/IP, so most of the work is already done.  I think this is all I 
need to say to get the idea across, but I can add detail if needed.

Mike

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

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

[Jonathan Hammell]

I would like to see this work adopted by the working group. I think the
language issues can be addressed after adoption.

However, given the disagreements raised, I would also be okay if the
adoption decision was postponed until after discussion in Vancouver.

Jonathan

On Thu., Feb. 13, 2020, 4:29 p.m. Martin Thomson,  wrote:

> On Fri, Feb 14, 2020, at 06:00, Salz, Rich wrote:
> > >I think the draft would be ok to adopt if we don't finish
> > it until the outcome from the NIST competition is known.
> > Otherwise I would be against adoption.
> >
> > I think I agree with this, but am not sure. Can we have this on the
> > agenda for Vancouver?
>
> That's a good idea.  Because I'm fairly sure that I disagree.
>
> This work might form the basis of experiments.  If the competition result
> is known, we might instead want to start the process of defining key
> exchange with a single algorithm rather than concern ourselves with
> compositions.  Having the document in place so that we can define
> experiments with a degree of surety with respect to their risks is best.
>
> In any case, we should adopt this work.
>
> ___
> 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: draft-stebila-tls-hybrid-design

[Panos Kampanakis (pkampana)]

I support adoption



From: TLS  On Behalf Of Joseph Salowey
Sent: Thursday, February 13, 2020 12:13 PM
To:  
Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design



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/







smime.p7s
Description: S/MIME cryptographic signature
___
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]

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
).



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
> contradict the above.
>
> Then because *_rsae is not allowed in expected algorithm, clients would
> need to include algorithm that can not be used, if they support *_rsae
> for PKIX signatures (however, there could be reasons not to support
> *_rsae for signing DCs, see below).
>
>
> An

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 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 are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-tls-subcerts-06
> > https://

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

[Carrick Bartle]

Great! I'll push it on over and continue reviewing.


> On Feb 14, 2020, at 11:36 AM, Nick Sullivan 
>  wrote:
> 
> 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 
> mailto:40icloud@dmarc.ietf.org>> 
> 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 delegate their own credentials for use in TLS,
> >   without breaking co

Re: [TLS] New direction for TLS?

[Benjamin Kaduk]

Hi Mike,

On Fri, Feb 14, 2020 at 09:46:56AM -0500, Michael D'Errico wrote:
> Hi,
> 
> It's been a long time since I posted to this list but saw that the charter is 
> being updated and wanted to share an idea I had a while ago but have not 
> found the time to work on.  The TL;DR is to deprecate TLS and rebuild 
> security on top of DTLS. With DTLS, you have encrypted packets, so think of 
> them as the new IP and build TCP on top of that.  It'd be like making the 
> internet run on TCP/DTLS instead of TCP/IP, so most of the work is already 
> done.  I think this is all I need to say to get the idea across, but I can 
> add detail if needed.

This sounds really similar to QUIC
(https://datatracker.ietf.org/wg/quic/documents); perhaps you could take a look
and try to describe any differences between your idea and what's being done
there?

-Ben

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

Re: [TLS] New direction for TLS?

[Yoav Nir]

> On 14 Feb 2020, at 22:03, Benjamin Kaduk  wrote:
> 
> Hi Mike,
> 
> On Fri, Feb 14, 2020 at 09:46:56AM -0500, Michael D'Errico wrote:
>> Hi,
>> 
>> It's been a long time since I posted to this list but saw that the charter 
>> is being updated and wanted to share an idea I had a while ago but have not 
>> found the time to work on.  The TL;DR is to deprecate TLS and rebuild 
>> security on top of DTLS. With DTLS, you have encrypted packets, so think of 
>> them as the new IP and build TCP on top of that.  It'd be like making the 
>> internet run on TCP/DTLS instead of TCP/IP, so most of the work is already 
>> done.  I think this is all I need to say to get the idea across, but I can 
>> add detail if needed.
> 
> This sounds really similar to QUIC

If it’s TCP (rather than HTTP) on top of the encryption layer, it sounds more 
like transport-mode IPsec. That gives you encrypted packets.

The difference is whether the authentication and encryption is part of the 
service provided by the OS (like IP) or part of the application.

Yoav

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

[TLS] ESNI/ECHO updates

[Rob Sayre]

Hi,

Are there any updates to ESNI/ECHO to share as a draft or an update?

It's been a few months, so just wondering (even if there's not much to say).

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