Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

[Tommy Pauly]

As a co-author, I do support adoption, as this will help optimize client 
connection racing.

Tommy

> On Nov 8, 2018, at 8:07 AM, Martin Thomson  wrote:
> 
> Adopt it.  It's a small, useful feature.
> On Wed, Nov 7, 2018 at 2:48 PM Sean Turner  wrote:
>> 
>> At TLS@IETF103, there was consensus in the room to adopt 
>> draft-wood-tls-ticketrequests.  This message is to confirm that consensus.  
>> If you do not support adoption of draft-wood-tls-ticketrequests as WG item 
>> please say so by 2359UTC on 30 November 2018 (and say why).
>> 
>> Thanks,
>> 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

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

[TLS] TLS 1.3 in iOS

[Tommy Pauly]

Hi all,

Last week, we shipped the first developer seed of iOS 12.2. Among other 
features, TLS 1.3 is now enabled by default for the entire system. All users of 
Network.framework and NSURLSession APIs will now negotiate TLS 1.3. The number 
of TLS 1.3 capable clients on the Internet should take quite a leap forward, 
and we are pleased to help move the needle towards faster and more secure 
network connections. 

We'd like to thank the members of this working group, and Eric Rescorla in 
particular, for all the work put into this protocol and its deployment on the 
Internet.

Enjoy!

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

Re: [TLS] draft-kinnear-tls-client-net-address comments

[Tommy Pauly]

The QUIC and TLS drafts were written together, and are quite similar as you 
note. The intention is to use the TLS extension over TLS/TCP connections, and 
the QUIC extension for QUIC/UDP.

I agree that QUIC as a protocol benefits more from the extension than TLS does, 
but applications on top of both can benefit by detecting NATs, for making 
decisions about long-lived connections and privacy mitigations. 

Thanks,
Tommy

> On Mar 20, 2019, at 2:26 AM, Martin Thomson  wrote:
> 
> I see a substantially similar draft in draft-pauly-quic-address-extension.  
> I'd like to understand how these might be complementary, or whether the idea 
> is to pursue only one.  The QUIC extension seems superior, if you have QUIC.  
> There are a lot more plausible reasons to want this information in QUIC 
> though.
> 
> Nits:
> 
> The format of the extension is not ideal.  Wouldn't you want to know which 
> family it came from?

I think the intention was to use the length to infer the family. 
> 
> The term of art is reflexive address (or reflected address).

Thanks, good to know!
> 
> ___
> 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] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

[Tommy Pauly]

> On Sep 24, 2019, at 7:32 AM, Stephen Farrell  
> wrote:
> 
> 
> Hi Erik,
> 
> FWIW, if browsers preferred this to an ESNI RR and
> we could forget the ESNI RR then I'd be ok with that.
> I'm not clear if they do or not though.

Regarding the status of which RR we use, I think the main goal for a system 
(speaking as an operating system vendor, rather than specifically just a 
browser vendor) would be to minimize the number of records we need to look up 
in order to get a usable set of information for connecting. To that end, I 
appreciate the generality and extensibility of the SCVB approach. It should 
ideally include any functionality needed for an ESNI-only deployment, but also 
allow for the specification of alt-svc, as well as other extensions that may 
come in the future.

Thanks,
Tommy

> In the meantime,
> assuming this went ahead instead of or in addition
> to an ESNI RR, I've a few questions below...
> 
> On 24/09/2019 14:21, Erik Nygren wrote:
>> Following the discussions in Montreal (as well as with some of the ESNI
>> authors),
>> we refactored the HTTPSSVC draft to make it more general.  The hope is that
>> it could be an alternative (or replace the need) for a distinct ESNI record.
> 
> So I think the basic ESNI case where there's no
> name changes nor alt-svc etc would be as below in
> presentation syntax, am I reading that right?
> 
>   example.com . 7200  IN HTTPSSVC 0 . ( 
> esnikeys="/wHrAh..." )
> 
> I'm also not clear if that's the exact same as:
> 
>   example.com . 7200  IN SVCB 0 . ( esnikeys="/wHrAh..." 
> )
> 
> ...is it? If so, which'd be preferred or would
> clients be expected to be able to handle both?
> And I don't get why two ways to say the same thing
> are useful.
> 
> Secondly, ESNIKeys currently supports versions,
> multiple keys, cipher_suites, extensions and even
> dns_extensions. And we could have >1 rrdata for
> ESNI or for SCVB/HTTPSSVC.
> 
> Would you envisage adoption of SVCB/HTTPSSVC meaning
> that we could drop some of the generality that's
> present in ESNIKeys? If so, what?
> 
> I'd like if ESNIKeys were made simpler FWIW, so if
> this had that effect, then I'd be more for it. If,
> OTOH, this just added complexity (for a library
> implementing ESNI), which currently seems to be the
> case, then it'd be less attractive, to me at least.
> (I guess I'm agreeing with Rich there:-)
> 
> Thanks,
> S.
> 
> 
>> The draft generalizes to a protocol-agnostic SVCB record, but also specifies
>> an HTTPSSVC record for the HTTP(S) use-case.
>> 
>> Based on discussions with various chairs, the plan is to call for adoption
>> in the DNSOP WG.
>> 
>> Comments/feedback are most welcome.
>> 
>>  Erik
>> 
>> 
>> -- Forwarded message -
>> From: Erik Nygren 
>> Date: Tue, Sep 24, 2019 at 9:17 AM
>> Subject: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
>> To: dnsop WG , Ben Schwartz , Mike
>> Bishop 
>> 
>> 
>> Following discussions around the "HTTPSSVC" record proposal in Montreal
>> with the DNSOP, HTTP and TLS WGs, we've updated what was previously
>> "draft-nygren-httpbis-httpssvc-03".  The new version is
>> "draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the
>> feedback from the WG discussions, as well as feedback from discussions with
>> the TLS WG (as we'd like to see this replace the need for a separate ESNI
>> record).
>> 
>> In particular, it generalizes the record into a new "SVCB" record which
>> doesn't have any protocol-specific semantics.  It also defines an
>> "HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and
>> parameter registry) and which defines the HTTP(S)-specific semantics such
>> as bindings to Alt-Svc.  Other protocols can either define bindings
>> directly to SVCB or can define their own RR Type (which should only ever be
>> needed if there is a need to use the record at a zone apex).
>> 
>> We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs
>> can go against:  https://github.com/MikeBishop/dns-alt-svc
>> 
>> Major changes from "draft-nygren-httpbis-httpssvc-03" include:
>> 
>> * Separation into the SVCB and HTTPSSVC RR Types  (and separated all of the
>> HTTPS-specific functionality and text to its own portion of the document).
>> * Elimination of the SvcRecordType field (and making the SvcRecordType
>> implicit)
>> * Changing the wire format of parameters from being in Alt-Svc text format
>> to a more general binary key/value pair format (with a mapping to Alt-Svc
>> for HTTPSSVC).
>> * Adding optional "ipv4hint" and "ipv6hint" parameters.
>> * Quite a few cleanups and clarifications based on input (and we
>> undoubtedly have more left to go)
>> 
>> This retains support for all of the use-cases that the previous HTTPSSVC
>> record had (such as for covering the ANAME / CNAME-at-the-zone-apex
>> use-case).
>> 
>> Feedback is most welcome.  If the TLS WG is going to use this instead of a
>> separate ESNI reco

Re: [TLS] Adopting HTTPSVC for ESNI

[Tommy Pauly]

I'm also supportive of this change, and in general of using HTTPSSVC for the 
transmission of ESNI keys, speaking as an implementer at Apple.

With regards to the per-version structure, I agree with Steven that the 
structure of the configuration should be able to change between versions. I 
think that either specifying that the structure can change with versions, or 
just moving the version into the label (Stephen's suggestion) would work. I 
have a *slight* concern for the case of using a different HTTPSSVC label for 
each version or set of extensions, since the code that parses out the records 
may be distinct from the code that uses the keys, and it may be easier to fetch 
the right information out if it has a consistent label name. Not a huge issue 
either way, though.

Thanks,
Tommy

> On Oct 25, 2019, at 7:57 AM, Steven Valdez 
>  wrote:
> 
> Chrome is supportive of this change, and will likely work on implementing 
> HTTPSSVC into our DNS stack once the draft progresses further.
> 
> As for the ESNIKeys/ESNIConfig change, we were actually thinking of something 
> that further abstracted HTTPSSVC having to understand anything about ESNI 
> from the ESNI versioning:
> 
> The ESNIKeys naming was always a bit confusing since you could have multiple 
> ESNIKeys, and there wasn't a great way of referring to those.
> 
> HTTPSSVC records include a single ESNIBundle which is length prefixed and 
> contains one or more ESNIConfigs. (to allow an endpoint to publish multiple 
> ESNIConfigs, potentially supporting multiple versions of the ESNI record).
> 
> Each ESNIConfig is then just a version and then a version-specific structure. 
> (to allow the entire structure of the ESNIConfigInner to arbitrarily change 
> at different versions).
> 
> Something roughly like the following:
> 
> ESNIBundle {
>   ESNIConfig<2..2^16-1>;
> };
> 
> ESNIConfig {
>   version,
>   select (version) {
> case 0: {
>   opaque public_name<1..2^16-1>;
>   KeyShareEntry keys<4..2^16-1>;
>   CipherSuite cipher_suites<2..2^16-2>;
>   uint16 padded_length;
>   Extension extensions<0..2^16-1>;
> }
>   }
> };
> 
> (alternatively maybe make an ESNIConfigInner and stuff an opaque in 
> ESNIConfig that is version-specific, not sure what the right presentation 
> looks like)
> 
> On Fri, Oct 25, 2019 at 6:29 AM Stephen Farrell  > wrote:
> 
> Hiya,
> 
> On 25/10/2019 01:28, Christopher Wood wrote:
> > Hi folks,
> > 
> > DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of
> > doing the same thing, I've put together a PR that drops the custom
> > ESNI RRType in favor of this more general (yet feature compatible)
> > Resource Record:
> > 
> > https://github.com/tlswg/draft-ietf-tls-esni/pull/187 
> > 
> > 
> > Please have a look and comment before next Friday. We'd like to land
> > this before Singapore.
> 
> I'm supportive of this change, on the assumption that browsers are
> really going to use HTTPSSVC.
> 
> If that lands as-is, please bump the version to ff04 and I don't
> see much benefit in changing from ESNIKeys to ESNIConfig (seems
> more likely to confuse than help to me).
> 
> Going further, I think we ought also take advantage of this to
> simplify the ESNIKeys/ESNIConfig structure. We don't need to do
> that right now but we could.
> 
> There are two related simplifications that'd make sense to me:
> 
> - remove the version field and encode that in the HTTPSSVC label
> (so it'd be something like esnikeys05="/wElr6L2ACQAHQ...") - I
> think that'd lead to fewer cases where HTTPSSVC code needs to
> understand what's inside the ESNIConfig structure.
> 
> - similarly, remove the extensions field from ESNIConfig, and
> require a new label in HTTPSSVC if something new is really needed
> 
> Cheers,
> S.
> 
> > 
> > Best, Chris (no hat)
> > 
> > [1]
> > https://mailarchive.ietf..org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s 
> > 
> >
> >  ___ 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 
> 
> 
> 
> -- 
> 
> Steven Valdez |Chrome Privacy Sandbox |sval...@google.com 
>  |210-692-4742
> ___
> 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-ticketrequests

[Tommy Pauly]

> On Nov 19, 2019, at 5:20 PM, Daniel Migault 
>  wrote:
> 
> Hi, 
> 
> Just to followup the discussion. I support Viktor,'s proposal as it provides 
> the ability to the client to specify what it wants rather than let the server 
> guess. What I am wondering is whether we are catching all possible client 
> "policies" or whether we should consider some additional reserved values. 
> Typically I do not see case where 200 tickets may be requested, so we may 
> have some place for reserved bits if needed. 
> 
> I see my comment of how tickets are generated as complementary.
> 
> Yours, 
> Daniel
> 
> 
> 
> On Sun, Nov 17, 2019 at 8:23 AM Viktor Dukhovni  > wrote:
> On Sat, Nov 16, 2019 at 03:59:53PM -0800, Benjamin Kaduk wrote:
> 
> > > That also works, effectively treat 0xff as "-1", but all other
> > > values as non-negative, with 0 a request for re-use.  An isomorphic
> > > encoding, but without the "-1".
> > 
> > [Jeremy had a more eloquent description of the vague sketch of an idea that 
> > I had in my head]
> 
> Jeremy's "isomorphic" encoding works fine for me, and is likely less 
> confusing.
> So, FWIW, it has my support.  Fleshing it out a bit more, I am proposing:
> 
> - 0xff => send no tickets
> 
> - 0x00 => reuse requested:
> + send no tickets if presented ticket is accepted and reusable
> + send one ticket if presented ticket is accepted, but is not reusable
>   (expired, or reuse is not allowed).
> + Also send one ticket if session could not be resumed and a full
>   handshake was performed.  Clients that reuse tickets don't need a
>   separate one for each session, so one per full handshake should
>   suffice.
> 
> - 0x01-0xfe => client wants single-use tickets:
> + send up to that many tickets on full handshake,
> + however, generally send just 1 ticket on resumption, or when
>   replacing tickets during long-lived connections.  This helps to
>   reduce chronic ticket "oversupply".

Having a recommendation to generally just send one ticket doesn't address the 
motivating use case for the document, which is Happy Eyeballs (connection 
racing). Having multiple tickets is required in a steady state, so we shouldn't 
recommend against that.

Any client that wants to only do the reuse case can just not use this extension.

Thanks,
Tommy
> 
> -- 
> Viktor.
> 
> ___
> 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-ticketrequests

[Tommy Pauly]

> On Nov 20, 2019, at 11:48 AM, Viktor Dukhovni  wrote:
> 
> On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote:
> 
>>>- 0x01-0xfe => client wants single-use tickets:
>>>+ send up to that many tickets on full handshake,
>>>+ however, generally send just 1 ticket on resumption, or when
>>>  replacing tickets during long-lived connections.  This helps to
>>>  reduce chronic ticket "oversupply".
>> 
>> Having a recommendation to generally just send one ticket
> 
> You left out the key qualification: "on resumption".  Now perhaps
> that strategy is only needed in the *absence* of any signal from
> the client, and with the extension the onus is perhaps on the client
> to send "1" once it has enough tickets, in which case the server
> does not need to apply the heuristic that helps it to avoid chronic
> ticket oversupply.  In which case, the "generally send just 1" can
> be left out, it is a side comment, not essential to the overall
> proposal.

That would be great to leave that out.
> 
> Somebody should try to avoid ending up with N new tickets after
> every connection, but in could well be the client.

Yes, I think that can and ought to be the client. The client is really the only 
party that can know how many tickets have been "consumed" by potentially failed 
attempts to connect that the server didn't see in time or got dropped.

Thanks,
Tommy
> 
>> doesn't address the motivating use case for the document, which is Happy
>> Eyeballs (connection racing). Having multiple tickets is required in a steady
>> state, so we shouldn't recommend against that.
>> 
>> Any client that wants to only do the reuse case can just not use this 
>> extension.
> 
> No, the extension is *very* useful to such clients, to signal to the server
> that that's what they want to do, so that the server then only issues new
> tickets when necessary.
> 
> -- 
>Viktor.
> 
> ___
> 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] Adoption call for draft-rescorla-tls-ctls

[Tommy Pauly]

I support adoption of this work.

Best,
Tommy

> On Nov 21, 2019, at 1:36 PM, Sean Turner  wrote:
> 
> At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG 
> and the LAKE BOF, which is now a chartered WG [3].  After some discussions, 
> the ADs suggested [4] that the TLS WG consider whether this draft be adopted 
> as a TLS WG item. LAKE could then later specify/refer/adopt/profile it, as 
> appropriate. The authors revised cTLS and presented the revised draft at IETF 
> 106 [5].  At IETF 106 there was support for adoption of cTLS as a WG item.  
> To confirm this on the list: if you believe that the TLS WG should not adopt 
> this as a WG item, then please let the chairs know by posting a message to 
> the TLS list by 2359 UTC 13 December 2019 (and say why).
> 
> NOTE:
> : If the consensus is that this draft should be adopted as a WG item, then 
> this will necessarily result in a WG rechartering discussions.  We would have 
> gotten to this rechartering discussion anyway now that DTLS 1.3 is 
> progressing out of the WG.
> 
> Thanks,
> Chris, Joe, and Sean
> 
> [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/
> [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
> [2] https://github.com/ekr/draft-rescorla-tls-ctls
> [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
> [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk
> [5] 
> https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf
> ___
> 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-ticketrequests

[Tommy Pauly]

First off, thanks for the lively discussion on ticket reuse! I think it's a 
valid use case and something that should continue to be discussed.

However, for the purposes of the WGLC for this draft, 
draft-ietf-tls-ticketrequests, it may be best to separate the conversation. It 
seems that the negotiation of ticket reuse would be best served by another 
document that could be adopted by the WG. The ticket request document, as it 
was adopted, was specifically a mechanism to request multiple tickets so as to 
*avoid* ticket reuse. This is stated several times in the use cases (section 2) 
and security considerations (section 5). While this does not preclude a future 
extension that negotiates ticket reuse, I believe, as an author, that enabling 
ticket reuse is out of scope of this particular document.

Best,
Tommy

> On Jan 23, 2020, at 1:01 PM, Viktor Dukhovni  wrote:
> 
> On Thu, Jan 23, 2020 at 01:32:51PM -0600, Nico Williams wrote:
> 
>> On Thu, Jan 23, 2020 at 09:43:21AM -0800, Watson Ladd wrote:
>>> Sending a new ticket doesn't force clients to store it.
>> 
>> Sure, but if the old ticket will not be accepted again then the client
>> will incur a full handshake later.  The client doesn't know if the old
>> ticket will or will not be accepted again.  Extending the protocol to
>> have the server signal that bit will require new OpenSSL extensions,
>> which is why that is not a sufficiently good response to the Postfix
>> issue.
> 
> Indeed, not storing the ticket breaks resumption.  So I always store the
> ticket (actually what OpenSSL hands me is a serializable opaque
> SSL_SESSION).  For example, when the server allows reuse, but has a
> shorter maximum ticket lifetime, its "as needed" new ticket needs to be
> stored, in order to replace a stale cached session and start using the
> fresh one.
> 
> Regardless, I also believe that not applications need or want the
> marginal privacy offered by single-use tickets (none for clients
> with stable dedicated IP addresses) and it should be possible
> in such cases (at effectively zero cost as proposed) to negotiate
> reuse in a way that allows servers to handle both types of client.
> 
> This would allow Postfix to vend single-use tickets to clients
> that request that (e.g. MUAs).  Right now the code is statically
> optimized for the MTA-to-MTA use-case.
> 
> So making reuse *negotiable* would in fact enhance privacy for MUAs on
> ephemeral IPs sending sufficiently frequent email (from behind a NAT or
> otherwise shared or changing address) to a sufficiently popular
> submission server that it is not trivial to link resumed TLS sessions to
> a given client.
> 
> -- 
>Viktor.
> 
> ___
> 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-ticketrequests

[Tommy Pauly]

Hi Viktor,

> On Jan 31, 2020, at 5:24 PM, Viktor Dukhovni  wrote:
> 
>> On Jan 31, 2020, at 8:15 PM, Rob Sayre  wrote:
>> 
>> If the scope of a document can be continually expanded during last call, it 
>> can be indefinitely postponed.
> 
> I'm not proposing a change of scope.  The document specifies how a client
> and server negotiate the number of tickets the server should send.  This
> remains the case.  The -04 document leaves out a relevant scenario where
> the client does want tickets to be refreshed (so not unconditionally zero),
> but does not want gratuitous tickets (new one each time).
> 
> The scope of the document per the abstract includes the following:
> 
>   This extension aims to provide a means for
>   servers to determine the number of tickets to generate in order to
>   reduce ticket waste, while simultaneously priming clients for future
>   connection attempts
> 
> My proposal falls squarely in the "in order to reduce ticket waste" category.

The document also is focused on use cases that are all about "avoid[ing] ticket 
re-use". The security considerations state that "Ticket re-use is a security 
and privacy concern".

While there are some use cases in which ticket re-use allows the reduction of 
ticket waste, we cannot state that every possible approach to reduce ticket 
waste is in scope for this particular document. Rather, this document defines 
its scope as simply: "This document describes a mechanism by which clients can 
specify the desired number of tickets needed for future connections." Enabling 
ticket reuse is not part of that scope.

Beyond discussing scope creep, I think an even bigger reason to decouple the 
idea of ticket requests from explicit ticket re-use is the notion of working 
group consensus. I think the WG has clearly expressed consensus on the fact 
that ticket requests are a useful and non-harmful extension. Indeed, the 
proposals to add ticket reuse logic to ticket requests that you want relies on 
such an extension. However, the group certainly does not seem to have consensus 
on the idea that there should be an extension to allow ticket reuse. As an 
author, I don't know if I'd support that. Thus, the working group can progress 
with the tightly-scoped document that it has consensus on, and leave other use 
cases to future documents.

Thanks,
Tommy
> 
> -- 
>   Viktor.
> 
> ___
> 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-ticketrequests

[Tommy Pauly]

Hi Nico,

As a point on the process, I don't think anyone is proposing rubber-stamping. 
We are instead only suggesting that a set of work that has consensus does not 
need to be held up by adding new work that does not have consensus.

The outcome of points raised during a WGLC does not need to be a change in the 
document, if the group does not have consensus that the suggested change is 
correct. Particularly, as in this case, a comment during WGLC to add new 
functionality that is not part of addressing the intended scope of a working 
group deliverable does not need to be added before progressing. I think this is 
a case in which we have consensus on the basic ticket requests, but adding 
ticket reuse is (based on the way this thread has not converged) is in the 
rough. 

Thanks,
Tommy

> On Jan 31, 2020, at 5:23 PM, Nico Williams  wrote:
> 
> On Fri, Jan 31, 2020 at 05:15:40PM -0800, Rob Sayre wrote:
>> If the scope of a document can be continually expanded during last call, it
>> can be indefinitely postponed.
> 
> There is no attempt to postpone, and the WGLC has finished.  No new
> issues will be raised.  But the ones that were raised _will_ be
> addressed.  Being left on the rough side of consensus happens; having
> substantive issues raised in a timely manner ignored must not.
> 
> The IETF is not a rubber-stamp SDO.  We have a process.  We don't just
> pay it lip service.  WGLC is not going through the motions.  The
> prescribed process will be followed.
> 
> Nico
> -- 

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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Tommy Pauly]

> On Jan 31, 2020, at 6:14 PM, Stephen Farrell  
> wrote:
> 
> 
> Hiya,
> 
> I have no particular position about this draft but
> am curious about 2 things:
> 
> #1 I don't get why it's not possible for postfix to
> determine the best way to manage tickets based on the
> destination port to which the ClientHello is sent. I
> totally get why that won't solve 100% of cases, but it
> would surely solve a huge percentage? Apologies if an
> answer was already posted as part of this v. long
> thread.
> 
> #2 I don't get why Viktor's request for special handling
> for value 255 is a real problem for anyone. We have
> another thread today envisaging 2040 extensions flags,
> so I really have a hard time seeing what here justifies
> rejecting Viktor's argument. FWIW, this thread has not
> provided me with an obvious answer to #2 other than "not-
> invented-here." I'm not sure that declaring things in the
> rough where the only identifiable issue is NIH is the
> overall best outcome, longer term.

That’s a fair point, and worth clarifying. Totally agree that NIH isn’t a good 
reason. Instead, it seems unclear what value the special use of 0 and 255 adds 
that wouldn’t be better served by a separate extension.

Today, without any sentinel values, 0 means the client hints that it doesn’t 
need any tickets, and N means that the client hints that it would like N 
tickets. Whether or not a ticket is intended to be reused is not part of this, 
and ticket reuse is elsewhere discouraged.

As far as I understand the proposal, the meaning currently expressed by sending 
0 would be expressed by sending 255 instead; and sending 0 would take on a new 
meaning that is “send a ticket if you want, and I may try to reuse a ticket if 
you don’t send one”, which seems like the behavior already expressed by not 
sending the ticket request message at all (since not passing the message is 
equivalent to no hint).

To that end, the proposed change doesn’t seem to add any new signaling 
capabilities, but makes the meanings of numbers less intuitive.

If the hint is intended to be “I’m planning on reusing tickets, let me know 
ahead of time if I shouldn’t”, that seems like it could be an explicit signal 
sent that doesn’t need to reuse a field that is a numeric count of tickets 
being requested. It seems like there is a small number of clients that would 
use this, so adding another message to signal this and potentially more info 
about reuse policy would make more sense and could be fleshed out in more 
detail separately. For example, if we add the proposed hint that presumably 
means “if you give me a new ticket, I’ll use it; but if you don’t, I’ll reuse 
an old one”, the client is essentially forcing a server that doesn’t want 
ticket reuse to issue a new ticket; whereas a more explicit signal could 
indicate that the server won’t allow ticket reuse, so the client shouldn’t even 
try, etc, without necessarily giving out new tickets. 

Best,
Tommy

> 
> Cheers,
> S.
> 
> <0x5AB2FAF17B172BEA.asc>
> ___
> 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-ticketrequests

[Tommy Pauly]

> On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni  wrote:
> 
> On Sat, Feb 01, 2020 at 08:05:28PM -0800, Watson Ladd wrote:
> 
>>> Sorry, no idea what that above means.  And is it simpler than the
>>> proposal under discussion (which got some fine-tuning in early
>>> feedback)?
>> 
>> So one proposal in above is we treat 0 tickets as "ensure I have a valid
>> ticket, either this one or a new one" and all other numbers are straight
>> asks for that many tickets.
> 
> This is indeed simpler, but it removes the ability to ask for zero
> tickets, which I think was one of the intended use-cases (that's what
> the 255 is for).
> 
>> The other proposal is N means "ensure I have N valid tickets, including the
>> one I used on this connection". I find both cleaner then the 0 and 255 swap.
> 
> The problem here is now reuse is implicit, and the only way for a client
> to ensure that it gets a fresh ticket, is by asking for 2.
> 
> So I now see where you're coming from, and it was worth a try at
> simplification, but I don't think it works out.  The reasons for
> two sentinels is that in fact are three separate cases.
> 
>1.  Client wants no tickets
>2.  Client wants to try to reuse an existing ticket
>3.  Client wants n > 0 fresh tickets.
> 
> I don't see how to handle 1 and 2 cleanly without two sentinels.

I think Watson’s point (which I fully agree with) is that sending the value “0” 
already means “the client wants no tickets”.  The document already explains 
this usage. Thus, you don’t need a sentinel value to express that case—is what 
the value of N already intuitively means. 

If you did need a sentinel to indicate that you wanted to try to reuse a ticket 
(which you can always try if you want), it would make more sense to just make 
that sentinel be 255, etc, rather than creating two sentinels.

The ticket reuse signaling that is proposed really is orthogonal to the *count* 
of tickets.

When requesting a number of tickets, there is a signal in one direction from 
the client about how many tickets it wants; and the server signals back by 
issuing some number of tickets. There isn’t much ambiguity.

On the other hand, the proposed sentinel value indicates “I’d like to reuse 
tickets if I can”, but without any additional signaling from the server about 
the support of ticket reuse, a server response containing no tickets is 
ambiguous—maybe it means ticket reuse is fine; maybe it means the server isn’t 
giving out any more tickets and won’t allow resumption. It is much clearer if 
there is a bidirectional signal about negotiating ticket reuse.

Beyond that, it seems odd to mark a Boolean sent by the client to ask for 
ticket reuse in an integer that counts numbers of tickets. It’s not that one 
value (255) is precious, but it means that these orthogonal concepts can no 
longer be communicated separately. Let’s imagine a client that had received 4 
tickets the first time around, on request, and then wanted to either reuse some 
of them or ask for 2 more. Keeping the ticket request just a number and having 
a separate message for the reuse Boolean allows that. Allocating a sentinel 
means that a request for reuse to a server that doesn’t support reuse now loses 
the ability to request a particular number of tickets.

Thanks,
Tommy

> 
> -- 
>Viktor.
> 
> ___
> 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-ticketrequests

[Tommy Pauly]

> On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni  wrote:
> 
> On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote:
> 
>> If you did need a sentinel to indicate that you wanted to try to reuse
>> a ticket (which you can always try if you want), it would make more
>> sense to just make that sentinel be 255, etc, rather than creating two
>> sentinels.
> 
> Sure, if you want to swap my 0 <-> 255, that'd be fine by me, then
> 0--254 are "natural", and 255 means "only as needed".  If that's what it
> takes to reach a compromise, I'm on board.
> 
>> The ticket reuse signaling that is proposed really is orthogonal to the 
>> *count* of tickets.
> 
> Except that it really isn't.  Reuse means: 0 tickets or 1 ticket when
> the one presented is or soon will become unusable.  There's no way to
> decouple that from the ticket count.

I don’t see why one should limit the number of tickets that can be requested to 
only 1 in a case in which a client wants ticket reuse, since the entire point 
of this extension message is to allow requesting multiple. I understand that 
there may be some scenarios in which a client requests multiple on the initial 
handshake, and then wants only one more after that, but that’s not necessarily 
the case.

For example, I connect once, and request 4 tickets so I can do happy eyeballs 
attempts (one for v4 and v6 on each Wi-Fi and Cell, say). When I try to connect 
later, I end up using all four of those tickets on attempts, but only one 
succeeds. Now I want 4 more, but only have one connection. If you wanted to 
have your ticket reuse signaling in this case, you’d want to express “either 
give me 4 new tickets, or let me know I can reuse the previous four”, in which 
case overloading values in the number of tickets is indeed reducing the 
expressivity of the mechanism.

Tommy

> 
> 
> -- 
>Viktor.
> 
> ___
> 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-ticketrequests

[Tommy Pauly]

:
The proposal for hinting ticket reuse should be written up as a new draft 
proposing an extension, with discussion on use cases around ticket reuse. The 
reuse discussion can continue around that document.
Consider adding text to draft-ietf-tls-ticketrequests to explain the fact that 
when racing connections, the client won’t necessarily know the number of 
tickets it will “consume”, so it should either have enough tickets for two 
subsequent handshake resumptions; or else use fewer tickets but potentially run 
out.
Thanks,
Tommy

> On Feb 2, 2020, at 11:05 AM, Tommy Pauly  
> wrote:
> 
> 
> 
>> On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni  wrote:
>> 
>> On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote:
>> 
>>> If you did need a sentinel to indicate that you wanted to try to reuse
>>> a ticket (which you can always try if you want), it would make more
>>> sense to just make that sentinel be 255, etc, rather than creating two
>>> sentinels.
>> 
>> Sure, if you want to swap my 0 <-> 255, that'd be fine by me, then
>> 0--254 are "natural", and 255 means "only as needed".  If that's what it
>> takes to reach a compromise, I'm on board.
>> 
>>> The ticket reuse signaling that is proposed really is orthogonal to the 
>>> *count* of tickets.
>> 
>> Except that it really isn't.  Reuse means: 0 tickets or 1 ticket when
>> the one presented is or soon will become unusable.  There's no way to
>> decouple that from the ticket count.
> 
> I don’t see why one should limit the number of tickets that can be requested 
> to only 1 in a case in which a client wants ticket reuse, since the entire 
> point of this extension message is to allow requesting multiple. I understand 
> that there may be some scenarios in which a client requests multiple on the 
> initial handshake, and then wants only one more after that, but that’s not 
> necessarily the case.
> 
> For example, I connect once, and request 4 tickets so I can do happy eyeballs 
> attempts (one for v4 and v6 on each Wi-Fi and Cell, say). When I try to 
> connect later, I end up using all four of those tickets on attempts, but only 
> one succeeds. Now I want 4 more, but only have one connection. If you wanted 
> to have your ticket reuse signaling in this case, you’d want to express 
> “either give me 4 new tickets, or let me know I can reuse the previous four”, 
> in which case overloading values in the number of tickets is indeed reducing 
> the expressivity of the mechanism.
> 
> Tommy
> 
>> 
>> 
>> -- 
>>   Viktor.
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org <mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls 
>> <https://www.ietf.org/mailman/listinfo/tls>
> 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Bikeshedding ECHO

[Tommy Pauly]

ECHO is more fun to say, but I do see how it can be confusing (sounding like 
some sort of ping) when out of the context of TLS.

To that end, I’d have a minor preference for “ETCH”.

Thanks,
Tommy

> On May 7, 2020, at 3:52 PM, Christopher Wood  wrote:
> 
> Erik raises some compelling reasons to change the name from ECHO to... 
> something else less confusing or misleading [1]. Candidates from the PR 
> include ETCH (Encrypted TLS Client Hello), ECH, and EHELLO. Since the 
> HTTPSSVC draft aims for WGLC before IETF 108, it would be good if we got this 
> bikeshedding out of the way now. To that end, if you have an opinion on the 
> name and whether or not we should change it, please share it! 
> 
> Thanks,
> Chris (no hat)
> 
> [1] https://github.com/tlswg/draft-ietf-tls-esni/issues/232
> 
> ___
> 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] Bikeshedding ECHO

[Tommy Pauly]

ECH is good. Go for it!

Tommy

> On May 20, 2020, at 11:34 AM, Erik Nygren  wrote:
> 
> 
> 
> ECH works for me.  (I really don't care between ECH and ETCH and thing both 
> are fine.)
> 
> Erik
> 
> 
>> On Wed, May 20, 2020 at 2:20 PM Christopher Wood  
>> wrote:
>> On Tue, May 19, 2020, at 8:18 PM, Filippo Valsorda wrote:
>> > As a data point, I was fairly confused when ECHO came up in 
>> > conversation, and had to stop to ask what it was. I think I would have 
>> > had a better chance of figuring it out from context or search if it 
>> > were called ECH, but don't have a strong preference for any specific 
>> > name.
>> > 
>> > ECH does have a remarkable short Wikipedia disambiguation list, FWIW. 
>> > https://en.wikipedia.org/wiki/ECH
>> 
>> ECH also works for me.
>> 
>> Best,
>> Chris (no hat)
>> 
>> ___
>> 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] consensus call: changing cTLS and ECH to standards track

[Tommy Pauly]

I support moving both drafts to standards track. 

For ECH, there is a definite need to encrypt the SNI and other fields as a 
complement to using encrypted DNS. We have implemented draft versions, and will 
implement and use the final certain of ECH + HTTPSSVC. 

For cTLS, this is a prime candidate for use by future versions of QUIC. Since 
that would want to be a normative reference from a standards track document, it 
would need to be standards track at the time it was used.

Thanks,
Tommy 

> On May 21, 2020, at 7:11 PM, Sean Turner  wrote:
> 
> It looks like the intended status for both draft-ietf-tls-ctls (aka cTLS) 
> and draft-ietf-tls-esni (aka ECH) should be changed. It appears that both 
> should be set to standards track; cTLS is now Informational and ECH is 
> Experimental. If you object to changing the track for either of these drafts 
> please send an email to the list stating why by 2359 UTC on 5 June 2020.
> 
> Cheers,
> spt (for 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] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt

[Tommy Pauly]

I've gone through my review of the draft as well, and I think this version 
looks good!

Thanks,
Tommy

> On Apr 3, 2017, at 11:25 AM, David Schinazi  wrote:
> 
> Thanks for the update!
> 
> I've reviewed -04 and I think the draft is ready to move forward.
> 
> Regards,
> David Schinazi
> 
> 
>> On Mar 28, 2017, at 15:43, Daniel Migault > > wrote:
>> 
>> Hi, 
>> 
>> Thank you Jim for the update. Here is the version resulting from the 
>> discussion we had during the WG meeting yesterday.  Please review the 
>> document and provide your feed backs by April 4 so we can move the draft to 
>> the IESG. 
>> 
>> Yours, 
>> Daniel
>> 
>> -Original Message-
>> From: Curdle [mailto:curdle-boun...@ietf.org] On Behalf Of Jim Schaad
>> Sent: Tuesday, March 28, 2017 4:40 PM
>> To: cur...@ietf.org
>> Subject: [Curdle] FW: New Version Notification for 
>> draft-ietf-curdle-pkix-04.txt
>> 
>> Here is the promised updated draft.
>> 
>> Changes:
>> 1.  Fixed an example that David Benjamin found was wrong.  (Incorrect sign 
>> bit in public key.) 2.  Remove all of the pre-hash text except to note that 
>> it does exist.
>> 3.  No changes to the OID arc being used despite the agreement during the 
>> meeting.  After the meeting, Russ, the chairs and I had a short talk and 
>> decided that this did not need to occur.  The problem was only with getting 
>> new values assigned not with the current values which were already assigned.
>> 
>> That should be the final issues in the draft
>> 
>> Jim
>> 
>> 
>>> -Original Message-
>>> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>>> Sent: Tuesday, March 28, 2017 4:31 PM
>>> To: Jim Schaad ; Simon Josefsson 
>>> 
>>> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt
>>> 
>>> 
>>> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been 
>>> successfully submitted by Jim Schaad and posted to the IETF repository.
>>> 
>>> Name:   draft-ietf-curdle-pkix
>>> Revision:   04
>>> Title:  Algorithm Identifiers for Ed25519, Ed448, X25519 and 
>>> X448 for
>>> use in the Internet X.509 Public Key Infrastructure
>>> Document date:  2017-03-28
>>> Group:  curdle
>>> Pages:  15
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt
>>> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
>>> Htmlized:   https://tools.ietf.org/html/draft-ietf-curdle-pkix-04
>>> Htmlized:   
>>> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04
>>> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04
>>> 
>>> Abstract:
>>>  This document specifies algorithm identifiers and ASN.1 encoding
>>>  formats for Elliptic Curve constructs using the Curve25519 and
>>>  Curve448 curves.  The signature algorithms covered are Ed25519 and
>>>  Ed448.  The key agreement algorithm covered are X25519 and X448.  The
>>>  encoding for Public Key, Private Key and EdDSA digital signature
>>>  structures is provided.
>>> 
>>> 
>>> 
>>> 
>>> 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
>> 
>> 
>> ___
>> Curdle mailing list
>> cur...@ietf.org
>> https://www.ietf.org/mailman/listinfo/curdle
>> 
>> ___
>> Curdle mailing list
>> cur...@ietf.org 
>> https://www.ietf.org/mailman/listinfo/curdle 
>> 
> 
> ___
> Curdle mailing list
> cur...@ietf.org 
> https://www.ietf.org/mailman/listinfo/curdle 
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Re: WG Adoption Call for A PAKE Extension for TLS 1.3

[Tommy Pauly]

I support adoption; this is useful work for real-world use cases.

I also support adoption because I am responsible for sample code that makes 
peer-to-peer connections based on PIN codes in a much worse way than this, and 
I’d like to replace it. =)

Tommy

> On Jul 24, 2025, at 9:01 AM, Sean Turner  wrote:
> 
> At IETF 122 & 123 we discussed draft-bmw-tls-pake13 [0]. The sense of room @ 
> both sessions was that there was support for working on PAKEs in TLS.
> 
> This email starts the WG adoption call for draft-bmw-tls-pake13. If you 
> support adoption and are willing to review and contribute text, please send a 
> message to the list. If you do not support adoption of this draft, please 
> send a message to the list and indicate why. This call will close at 2359 UTC 
> on 07 August 2025.
> 
> Cheers,
> Deirdre, Joe, and Sean
> 
> [0] https://datatracker.ietf.org/doc/draft-bmw-tls-pake13/
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Intdir telechat review of draft-ietf-tls-esni-24

[Tommy Pauly via Datatracker]

Document: draft-ietf-tls-esni
Title: TLS Encrypted Client Hello
Reviewer: Tommy Pauly
Review result: Ready

"I am an assigned INT directorate reviewer for . These comments
were written primarily for the benefit of the Internet Area Directors. Document
editors and shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with any other
Last Call comments that have been received. For more details on the INT
Directorate, see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>."

Thanks to the authors for a clear and important document.

>From an INT perspective, I didn’t find any areas of concern. The example IP
addresses used are all v6, so that should make our ADs happy! :) Broadly, the
main relevance for INT here is that the privacy mechanism of obfuscating the
SNI works when at least several different names can be accessed via a common
address or set of addresses. The descriptions of this behavior looked correct.


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Tsvart last call review of draft-ietf-tls-esni-23

[Tommy Pauly via Datatracker]

Reviewer: Tommy Pauly
Review result: Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

Thanks to the authors for producing a clear and well-written document.
In reviewing it, I did not find any issues from a transport perspective
that raise concern. This protocol extension is defined to work with various
transport cases (TLS over TCP, DTLS over UDP, QUIC, etc), and otherwise
does not fundamentally change their properties.

>From a privacy and security perspective, it is good to see this work
progressing.


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org