from:"Stephen Farrell"

Re: [TLS] Dnsdir early review of draft-ietf-tls-wkech-04

2024-04-16 Thread Stephen Farrell



Hi David,

Thanks for taking the time to review this.

On 15/04/2024 23:44, David Blacka via Datatracker wrote:

Reviewer: David Blacka
Review result: Ready with Issues

This is an early review, so the actual status simply means that I didn't find
anything alarming in this draft.


Ta. The authors do agree that it's not actually ready though
so no need to be so nice:-)


At its core, this I-D is a registration for a well-known URI, using the
criteria described in RFC 8615.  The use of this well-known URI is that a
separate software component from the web server itself can poll the URI and,
based on the response, update DNS RRsets.  This seems pretty straightforward.

The JSON format is encoding of the SVCB ServiceParams, plus the priority,
target, and "regeninterval" fields.  This makes sense, since we are asking the
"Zone Factory" to generate a SVCB or HTTPS record from the data.  This leads to
some obvious questions:

* What happens if there are unknown keys in the JSON?  (e.g, is the response
considered invalid? 


Yeah, that's TBD for now. Authors need to chat about it and
probably reflect on how we've seen new tags for SVCB being
added over the last while.


Or does the Zone Factory ignore them and create the RRs
anyway?) * how are changes to the underlying SVCB service parameter registry
handled?  This I-D asks IANA to create another registry for the JSON fields.
Does this have to "keep up" with the SVCB IANA registry?


Good questions that'll need answering. Will create GH issues
for those (and for issues raised in Martin Thomson's review);
I plan to create those this week when I get time.


This I-D talks about web servers running in "split mode".  Is this a common
term in the web world?  Is there a reference to this practice?  


It's not common in the web world, but is part of the design
of ECH and defined in that draft. I added a sentence saying
that to my local copy.


If not, could
it be described more completely? I found the abbreviation "BE" to be jarring,
possibly more so because it is used without any English articles.


We already changed some terminology based on Martin's review
so those all now say "backend" rather than "BE."


Since I don't really understand "split-mode" (which is presumed to be the norm
based on the example), I don't understand why the distinction is relevant to
the proposal?  Does the Zone Factory behave differently if the web server is in
"split-mode"?  Section 5 suggests that is does, but I'm not sure exactly what
is going on there.


Yeah, there're a few things still to be figured out wrt split
mode but we'll be working on it next week or so - probably ok
to keep an open issue for that.


I found the term "Zone Factory" a bit odd as well, but I couldn't think of a
better name.  "Zone Agent"?  "SVCB Update Client"?


ZF still seems better to me, but we'll doubtless get feedback
as the draft progresses in the WG and gets further dnsdir
review as things settle down.


The I-D in section 6 says:

 ZF SHOULD set a DNS TTL short enough so that any cached DNS resource
 records are likely to have expired before the JSON object's content is
 likely to have changed. The ZF MUST attempt to refresh the JSON object and
 regenerate the zone before this time. This aims to ensure that ECHConfig
 values are not used longer than intended by BE.

This could be couched more precisely in terms of "regeninterval".  We might
want to avoid being overly prescriptive, though.  Something like "The ZF SHOULD
set a DNS TTL less than 'regeninterval'", perhaps.


WFM. Made that change locally.


In Section 6 (and maybe section 3), it isn't spelled out how the Zone Factory
determines the "owner" of the SVCB and or HTTPS records.  I only ask about this
because, if it isn't the domain part of the well-known URI used, then it should
be accounted for in the JSON format.

I'll also note that this early I-D does have a number of obvious typos, at
least one was noticed by the ART reviewer:

* "For many applications, that requires publication of ECHConflgList data
structures in the DNS" -- there is an ell masquerading as an i. * "Zone factory
(ZF): an entity that has write-accsss to the DNS" -- should be "access".


Ta. Fixed locally.


There are likely others.


Doubtless:-)

Thanks again,
S.

PS: In case someone cares - the draft may well expire before we
get -05 out, but it should be a short interregnum:-)








OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] I-D on TLS authentication with VC

2024-04-05 Thread Stephen Farrell



Hiya,

On 05/04/2024 12:54, Achim Kraus wrote:

Hi,


On that basis, I'd consider this a bad idea that
ought not be pursued, and certainly not by the TLS
WG.


for me this sounds more like an argument for a

"recommended (for general use-cases) n".


I'd go further - ISTM an argument for a re-design
that just doesn't have the privacy problem. (And
maybe come back to the TLS WG after that's done.)


Or does the TLS group focus on Web only and I missed that?


My mail made no reference to the web. The problem,
if it exists, would apply to all uses of TLS that
enabled this mechanism.

Cheers,
S.



best regards
Achim



OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] I-D on TLS authentication with VC

2024-04-05 Thread Stephen Farrell



Hiya,

On 04/04/2024 09:53, Andrea Vesco wrote:
I-D: https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/ 

From figure 2 it looks as if use of this mechanism
would have bad privacy properties as the DLT would
end up knowing which clients accessed which servers
at what times. That's v. similar to the problems
caused by clients checking OCSP.

On that basis, I'd consider this a bad idea that
ought not be pursued, and certainly not by the TLS
WG.

Or, am I wrong about the privacy issue here?

Thanks,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Working Group Last Call for SSLKEYLOG File

2024-04-02 Thread Stephen Farrell



Hiya,

This is basically for the record and not an objection to proceeding.

On 02/04/2024 17:34, Sean Turner wrote:

This WGLC has concluded.  There is consensus to move this document forward.

The material change was to add a security consideration about forward secrecy 
guarantees being negated if the key material is leaked:
https://github.com/tlswg/sslkeylogfile/pull/7/files

We will not be asking the formal analysis folks to weigh in on this I-D; we all 
know the file’s content are the keys to the kingdom.

Martin: If you can spin a new version, I can get the Shepherd write-up drafted.


I like the addition in -01 but would still have preferred if we
weren't so awfully oblique about the consequences of running a
production system with this logging enabled.

Were it up to me (and it's not) I'd suggest an additional addition
along the lines of:

"Systems that enable logging as described here are (while logging
is enabled) unlikely to be consistent with requirements to make use
of state-of-the-art protections, as e.g. is called-for by GDPR
article 32 [1]"

I suppose one could also re-do the above suggested text to refer
to RFC6919, section 3:-) [2]

Again, I'm not objecting to proceeding, just bemoaning what I see
as us being so oddly timid in calling out real issues.

Cheers,
S.

[1] https://gdpr-info.eu/art-32-gdpr/
[2] https://datatracker.ietf.org/doc/html/rfc6919#section-3



spt


On Mar 28, 2024, at 09:24, Sean Turner  wrote:

Just a reminder that this WGLC ends soon!

spt


On Mar 12, 2024, at 10:57, Sean Turner  wrote:

This is the working group last call for the SSLKEYLOGFILE Format for TLS 
Internet-Draft [1]. Please indicate if you think the I-D is ready to progress 
to the IESG and send any comments to the list by 31 March 2024.

The GH repo for the I-D can be found at [2].

Thanks,

Joe, Deirdre, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
[2] https://github.com/tlswg/sslkeylogfile




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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Working Group Last Call for ECH

2024-04-02 Thread Stephen Farrell



Hiya,

On 02/04/2024 15:17, Russ Housley wrote:

Joe:

The ECH Internet-Draft includes this reference:

[ECH-Analysis]
   "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
   Client Hello", November 2022.


I'm guessing that'd be:

@inproceedings{bhargavan2022symbolic,
  title={A symbolic analysis of privacy for tls 1.3 with encrypted 
client hello},
  author={Bhargavan, Karthikeyan and Cheval, Vincent and Wood, 
Christopher},
  booktitle={Proceedings of the 2022 ACM SIGSAC Conference on Computer 
and Communications Security},

  pages={365--379},
  year={2022}
}

Cheers,
S.



This reference does not provide enough information for anyone to locate the 
document.  I think a reference that everyone can locate is needed here.

Russ



On Apr 1, 2024, at 6:12 PM, Joseph Salowey  wrote:

This WGLC has concluded.  There is consensus to move this document forward.  I 
think there are one or two minor changes proposed that should be incorporated 
into the revision we forward to the IESG.

Joe

On Thu, Mar 28, 2024 at 6:23 AM Sean Turner mailto:s...@sn3rd.com>> wrote:

Just a reminder that this WGLC ends soon!

spt


On Mar 11, 2024, at 18:00, Joseph Salowey mailto:j...@salowey.net>> wrote:

This is the working group last call for TLS Encrypted Client Hello [1].  Please 
indicate if you think the draft is ready to progress to the IESG and send any 
comments to the list by 31 March 2024.  The comments sent by Watson Ladd to the 
list [2] on 17 February 2024 will be considered last call comments.

Thanks,

Joe, Deirdre, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
[2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/



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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Artart early review of draft-ietf-tls-wkech-04

2024-04-02 Thread Stephen Farrell



Hi Martin,

Thanks for the review. (More such are v. welcome esp as ECH is
now past WGLC.)

On 02/04/2024 00:40, Martin Thomson via Datatracker wrote:

Reviewer: Martin Thomson
Review result: Not Ready

This document describes how an HTTP origin can publish information about its
ECH configuration so that other nodes can aid it in setting up the DNS records
necessary to run DNS.

Issues:

Most of the document talks about having the back-end servers produce content
for the well-known resource, but there is mention of other servers being
involved as well.  ECH depends on having shared configuration at the
client-facing side for servers, so any configuration process should probably
involve something different.  That is, having each server produce information
about its own (perceived) configuration, with the zone factory being
responsible for synthesizing the information from each into a coherent whole.

In that design, a back-end server would indicate that they are using a shared
client-facing server, and point to it.  The client-facing server would supply
its ECH configuration (which might be different for different back-end
servers).  There are cases where a client-facing server might be able to
produce the content for a back-end server, so that a single resource could make
sense. That might lead to the design we see, but that is not obviously correct
for all aspects of the design.


I'm not really sure how to interpret the above tbh. Was that intended
as a summary of the draft or as a synopsis of the problem space?


The current design involves publishing information for a multitude of


Well, s/involves/allows/ is maybe more accurate but that's a nit-pick...


ECHConfigList values and multiple target names (and ports).  It is not obvious
that it is safe to have one origin speak for multiple others in this way or
what conditions might be necessary to have that happen safely.  If there is a
validation process involved, that might work.  The process in S6 is too loose
for me to be confident in that being sufficient.


That's fair. What's defined now supports (hourly) ECH key rotation for
the set of test servers I have on different ports of the same VM. In
that case, there's a different http server implementation listening on
each port, which I guess would be an extremely unlikely production
configuration, but OTOH, it seems right to be able to support that odd
case. And I think if we can support that odd case, then we'll also be
ok for more likely production cases.


The design for publishing alias records is something I cannot decipher at all.
There's a description of the field, but no real supporting material for that.


Also fair. Will add more description of that and we can see if it makes
more sense then. I'm a bit unsure what to add right now though given
it's been hard to test aliasMode - does anyone know if browsers now
support that (with ECH)? (Been a while since I tried that, but will
do some more testing as we produce a -05 draft.)


The different deployment options need to be more clearly articulated in support
of different modes of use, along with any validation that is needed.


Happy to document the validation more, but the basic idea is that the
ZF checks ECH works, and if it does, then the ZF is ok to re-publish.
If anyone has ideas on other kinds of checks that'd be sensible, be
happy to consider incorporating those.



It might be the case that the design is fundamentally sound, but it isn't clear
to me that this is true.


I'm happy to try convince you over time:-)

More concretely, I can try add text to the security considerations
that argues that the design meets some security goal(s) and we can
discuss that text as we go forward.



Nits:

Titles are not sentences.  Lose the period.


Where? (Sorry, not sure, but the RFC editor will fix anyway
so no worries.)



S1, typo: ECHConflgList


Fixed.


Use of the term "front-end" and "back-end" is likely confusing for some
consumers of this specification.  Front-end overwhelmingly refers to the
development of web-facing content, whereas back-end refers to the development
of servers and services.  Why not use client-facing as the ECH specification
does?


I'll give it a shot, but have always found that terminology a
bit confusing. I could also add a diagram too I guess, which
may help the reader a bit.



S3, please avoid using things like "cronjob".  Periodic is fine and doesn't
presume the use of a particular tool.


It's an example, but a fairly well known one. Will look at the wording
though.



S3, typo: regularaly


Fixed.



S4:


The well-known URI defined here MUST be an https URL and therefore the ZF

verifies the correct BE is being accessed. If no new ECH value resulting
"works," then the zone factory SHOULD NOT modify the zone.

This is two very different concepts in the one paragraph.  The first is about
authenticating the content at the .w-k resource.  The second is about
validating it.  There is no segue between the two.

Re: [TLS] should we say anything about ECH in the face of fragmentation?

2024-03-16 Thread Stephen Farrell



Hiya,

On 15/03/2024 21:55, Watson Ladd wrote:

On Fri, Mar 15, 2024 at 2:23 PM Stephen Farrell
 wrote:



Hiya,

I think the outcome here is maybe most likely to do nothing but
since the WGLC is ongoing I figured it best to bring it up in
case others have better ideas.

I got a mail yesterday from someone who had played with the nginx
"stream module" setup ECH-split-mode PoC stuff we've done and found
a difference in how IP fragmentation affected that configuration,
depending on whether or not ECH was enabled.


I am very confused here. Is this over TCP? 


Yeah, sorta, but...

TBH  I only looked at how to get ECH split-mode decryption working but
IIUC the nginx stream modules enable examining packets for load
balancing so that the TCP (and TLS) session ends up between the client
and back-end. So in that mode, nginx (or haproxy similarly) is mostly
looking into the 1st packet seen, maybe for a CH with an SNI, and
then uses what it finds to route the packet to some back-end. It
(nginx) then also sets itself as a proxy between the client and
server for remaining packets in the connection.

If the 1st packet has an outer CH then we can attempt to ECH decrypt
that and then do whatever nginx would've done in stream-mode and that
does work.

I never did look at what else nginx does at the IP or TCP layer,
once I got stuff to work, but I suppose I should, to do it right.

Handling split-more + HRR was even more fun so I'd not be surprised
if IP fragmentation caused issues there too.

All that said, I'm still not sure that even attempting to support
split-mode ECH in the face of IP fragmentation would be a good plan
though.

Cheers,
S.


If so, why isn't the MSS
preventing IP fragmentation? Is this in QUIC?



The pcaps I've seen show fragmentation of the CH after 588 octets.

In the ECH-using case, nginx aborts the connection as it sees a
malformed outer CH. In the non-ECH case, nginx can decide how to
forward the packets as it can decode into the partially rx'd CH
and see the SNI (which is what's used to decide where to fwd the
connection). I don't (yet) know what'd happen if fragmentation
happened in the middle of the SNI in the non-ECH case. (I'd bet
it'd not be good though:-)


This sounds like an NGINX bug/misfeature. How the data ends up on the
wire below TCP shouldn't affect what happens beyond e.g. timing out.



The reason for the difference is relatively obvious but I guess
could be stated in the draft: an ECH split-mode front-end can't
decrypt the ECH until it's seen the entire CH, due to the use of
the ClientHelloOuterAAD as aad.

I've not yet thought about whether it'd make sense to try to
buffer up partially rx'd fragments to see if those eventually
do turn out to be a nicely encoded outer CH - I suspect that
may be more of a footgun than useful;-(

I think all the exact same things would happen with our haproxy
split-mode PoC, so this isn't an nginx specific issue.

Cheers,
S.

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




--
Astra mortemque praestare gradatim


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

[TLS] should we say anything about ECH in the face of fragmentation?

2024-03-15 Thread Stephen Farrell



Hiya,

I think the outcome here is maybe most likely to do nothing but
since the WGLC is ongoing I figured it best to bring it up in
case others have better ideas.

I got a mail yesterday from someone who had played with the nginx
"stream module" setup ECH-split-mode PoC stuff we've done and found
a difference in how IP fragmentation affected that configuration,
depending on whether or not ECH was enabled.

The pcaps I've seen show fragmentation of the CH after 588 octets.

In the ECH-using case, nginx aborts the connection as it sees a
malformed outer CH. In the non-ECH case, nginx can decide how to
forward the packets as it can decode into the partially rx'd CH
and see the SNI (which is what's used to decide where to fwd the
connection). I don't (yet) know what'd happen if fragmentation
happened in the middle of the SNI in the non-ECH case. (I'd bet
it'd not be good though:-)

The reason for the difference is relatively obvious but I guess
could be stated in the draft: an ECH split-mode front-end can't
decrypt the ECH until it's seen the entire CH, due to the use of
the ClientHelloOuterAAD as aad.

I've not yet thought about whether it'd make sense to try to
buffer up partially rx'd fragments to see if those eventually
do turn out to be a nicely encoded outer CH - I suspect that
may be more of a footgun than useful;-(

I think all the exact same things would happen with our haproxy
split-mode PoC, so this isn't an nginx specific issue.

Cheers,
S.



OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Working Group Last Call for SSLKEYLOG File

2024-03-15 Thread Stephen Farrell




On 15/03/2024 03:43, Martin Thomson wrote:

Reasonable statement.  It's a variation on what we already have, but the focus 
on forward secrecy is worth a small paragraph:

How about this: https://github.com/tlswg/sslkeylogfile/pull/7/files


I think that's a good addition (with or without Dennis's comment).

Thanks,
S.



On Thu, Mar 14, 2024, at 22:51, Dennis Jackson wrote:

I have a suggestion which keeps things technical but hopefully
addresses Stephen's concern:

In Security Considerations:

"TLS1.3 requires the use of forward secret key exchanges (RFC 8446,
1.2, E.1). Using SSLKEYLOGFILE breaks this security property as it
records the used session key and so invalidates many of the security
claims made in RFC 8446. If SSLKEYLOGFILE is in use, the transferred
data does not benefit from the security protections offered by RFC 8446
and systems using SSLKEYLOGFILE cannot be considered compliant with RFC
8446 or offering similar security to the protocol outlined in that
draft."

I don't think the wording there is quite right, but I do think the
Security Considerations should clearly call out the impact on forward
secrecy and RFC 8446 in general and so dissuade use.

Best,
Dennis

On 12/03/2024 23:07, Eric Rescorla wrote:



On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell  
wrote:


I'll argue just a little more then shut up...

On 12/03/2024 22:55, Martin Thomson wrote:



Sorry also for a late suggestion, but how'd we feel about adding
some text like this to 1.1?

"An implementation, esp. a server, emitting a log file such as this
in a production environment where the TLS clients are unaware that
logging is happening, could fall afoul of regulatory requirements
to protect client data using state-of-the-art mechanisms."



I agree with Ekr.  That risk is not appreciably changed by the
existence of a definition for a file format.

I totally do consider our documenting this format increases
the risk that production systems have such logging enabled,
despite our saying "MUST NOT." So if there's a way to further
disincentivise doing that, by even obliquely referring to
potential negative consequences of doing so, then I'd be for
doing that.


Aside from this particular case, I don't think technical specifications
should "obliquely" refer to things. Technical specifications should be
clear.

-Ekr


Hence my suggestion.

S.
___
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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] ML-KEM key agreement for TLS 1.3

2024-03-15 Thread Stephen Farrell

Hiya,

On 14/03/2024 01:41, Deirdre Connolly wrote:

Oh and one more consideration: hybrid brings complexity, and presenting the
pure-PQ solutions and their strictly lesser complexity (at the tradeoff of
maybe taking more risk against newer schemes no matter how good we feel
about their fundamental cryptographic foundations) is worthwhile in my
opinion.

I'm all for reduced complexity, but in the case of hybrid KEMs, I don't
think we can directly trade off the systems complexity in having to add
support for hybrids vs. not doing that so easily - the one and only
thing we get from hybrid KEMs is protection against record-now-decrypt-
later attacks and those aren't visible in analysis of code.

Generally on this draft: I think this is a case where we do not want
to skate to where we think the pq-puck is going as there is too much
uncertainty as to possible future (super:-)positions for the puck.

So, I'd suggest leaving this until we have more information. If people
who need to adhere to odd govt. dictates to not use hybrid KEMs have to
get codepoints in the meantime, then that's a pity for them, but I'd
prefer to see the WG only spend time on crypto in which we claim to
have sufficient confidence, which for now, means hybrid KEMs.

Cheers,
S.

On Wed, Mar 13, 2024 at 9:39 PM Deirdre Connolly
wrote:

Some considerations for ML-KEM alone (or another trusted PQ-only key
agreement) are mainly looking towards the desired next step after hybrid
key agreement, and instead of leaving that fuzzy and far off, talking about
it in the present. This is also motivated by -hybrid-design allowing
several traditional NamedGroups to be negotiated on their own, as hybrid
NamedGroups with ML-KEM (although currently both are specified as Kyber but
those will change), but no option to negotiate the other side of the hybrid
alone, the PQ algorithm alone, Shaking out all the negotiation decisions is
desirable as well as 'drawing the rest of the owl' for the pure PQ option
implied in the negotiation (are we going to copy the same ~1000 bytes for
the PQ and hybrid name groups, when sharing an ephemeral KEM keypair?).

For CNSA 2.0, it is cited not as a compatibility _requirement_ of TLS, but
a note that a non-trivial segment of users of standard TLS that have been
traditionally compliant will not be in a few years, and they will come
knocking anyway. This is trying to skate where the puck is going.

But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key
agreement in the next ~6-9 years is a strong vote of confidence in any
protocol doing this at all, so, TLS wouldn't be out on a limb to support
this, basically.

I don't have a strong opinion on whether this should be Recommended = Y.

On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla wrote:

On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie wrote:

Greetings Deirdre and TLS,

I read through draft-connolly-tls-mlkem-key-agreement-00 (and
https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
and I have a few comments. First, though, I want to say thank you for
writing this draft. I'll echo some of what has already been voiced on this
thread and say that, while some plan to use composite key establishment, it
makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
another option. Other WGs (lamps and ipsecme) have already begun to specify
the use of standalone FIPS 203, 204, and 205 in various protocols. With
respect to this draft, there is certainly interest from National Security
System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
compliance (as CNSA 2.0 does not require nor recommend hybrid solutions for
security).

I wanted to address this CNSA 2.0 point, as I've now seen it brought up a
couple of times.

The IETF, together with the IRTF, needs to make an independent judgement
on whether using PQ-only algorithms is advisable, and if we do not think
so, then we should not standardize them, regardless of what CNSA 2.0
requires. The supported groups registry policies are designed explicitly to
allow people to register non Standards Track algorithms, so nothing
precludes the creation of an ML-KEM only code point if some vendors find
that necessary, without the IETF standardizing them or marking them as
Recommended=Y.
-Ekr

A few specific comments:

1. In Section 1.1 (or Introduction - Motivation in the github version),
I would suggest that the second sentence ("Having a fully post-quantum...")
is not needed, i.e. that there need not be a justification for why it is
necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
appropriate to contextualize the specification of ML-KEM w.r.t the advent
of a CRQC, though I also don't think that is necessary. As an example, we
can compare to the Introduction in draft-ietf-lamps-cms-kyber-03.

2. Section 3 (Construction on github) currently reads, "We align with
[hybrid] except that

Re: [TLS] Working Group Last Call for SSLKEYLOG File

2024-03-12 Thread Stephen Farrell



I'll argue just a little more then shut up...

On 12/03/2024 22:55, Martin Thomson wrote:


Sorry also for a late suggestion, but how'd we feel about adding 
some text like this to 1.1?


"An implementation, esp. a server, emitting a log file such as this
in a production environment where the TLS clients are unaware that
logging is happening, could fall afoul of regulatory requirements
to protect client data using state-of-the-art mechanisms."



I agree with Ekr.  That risk is not appreciably changed by the
existence of a definition for a file format.

I totally do consider our documenting this format increases
the risk that production systems have such logging enabled,
despite our saying "MUST NOT." So if there's a way to further
disincentivise doing that, by even obliquely referring to
potential negative consequences of doing so, then I'd be for
doing that. Hence my suggestion.

S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Working Group Last Call for SSLKEYLOG File

2024-03-12 Thread Stephen Farrell




On 12/03/2024 22:06, Eric Rescorla wrote:

I don't think we should make statements about regulatory requirements
in this kind of specification. That's not our lane.


I'd weakly disagree about making statements such as suggested,
while agreeing with "not out lane." I don't think the text I
suggested crosses that line, but it's fine if others disagree
of course.

I'd also be ok if we only stated that emitting these logs in
production systems means not deploying state of the art security
and letting the rest of the world connect the dots.

Cheers,
S.

PS: to be clear, I'm not objecting to progression if my
suggestion isn't adopted.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Working Group Last Call for SSLKEYLOG File

2024-03-12 Thread Stephen Farrell



Hiya,

On 12/03/2024 14:57, Sean Turner wrote:

This is the working group last call for the SSLKEYLOGFILE Format for
TLS Internet-Draft [1]. Please indicate if you think the I-D is ready
to progress to the IESG and send any comments to the list by 31 March
2024.


This is not my fav thing, but I guess I've also benefited from
it during development, so with a bit of nose-holding, I suppose
it's ready. (Apologies to Martin for the grudging acceptance of
his worthy effort;-)

Sorry also for a late suggestion, but how'd we feel about adding
some text like this to 1.1?

   "An implementation, esp. a server, emitting a log file such
as this in a production environment where the TLS clients are
unaware that logging is happening, could fall afoul of regulatory
requirements to protect client data using state-of-the-art
mechanisms."

Another thought occurred to me that I don't recall being mentioned
before: given we're defining a mime type, that suggests sending
these files by mail or in an HTTP response. Doing that could
be leaky, esp. if only one side of the TLS connection reflected in
the file were aware that logging was being done and if the other
side then sends the file via unencrypted email. I guess one
could also envisage a weird case where a server did this and
also located the log file inside the DocRoot enabling some
clients to see the secrets of some other clients (or their own).
I'm not sure if either scenario, or any similar scenario justifies
an additional warning to be careful where you send files using
that mime type? If it seems worth including, grand. If not, that's
ok.

Cheers,
S.



OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Working Group Last Call for ECH

2024-03-11 Thread Stephen Farrell

Hiya,

On 12/03/2024 01:25, Rob Sayre wrote:

The one that got to me was:

"It SHOULD place the value of ECHConfig.contents.public_name in the
"server_name" extension. Clients that do not follow this step, or place a
different value in the "server_name" extension, risk breaking the retry
mechanism described in Section 6.1.6 or failing to interoperate with
servers that require this step to be done; see Section 7.1."

So, that seemed like it might be a problem for the previous analysis.

I guess that's a reasonable question to ask, though I'd be
surprised if it that case were represented in the analyses.

If asked, (and who'd ask me:-), I'd probably argue that it
doesn't affect the security properties of ECH though, as a
server could always have been presented with an outer CH
that has some random SNI value, so I'd guess that change
ought not affect the security properties of ECH. Clients
that follow the SHOULD get the same as before, as do those
that don't, and servers should in any case have been able
to handle unexpected values in inputs.

Hopefully, some of the people who did the analyses will
chime in on the WGLC though, it'd be good if they had the
time to do that.

Cheers,
S.

thanks,
Rob

On Mon, Mar 11, 2024 at 6:12 PM Stephen Farrell
wrote:

On 12/03/2024 00:49, Rob Sayre wrote:

On Mon, Mar 11, 2024 at 5:21 PM Christopher Patton <

cpat...@cloudflare.com>

wrote:

I don't believe there were any changes from draft 13 to 18 that would
invalidate security analysis for draft 13:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-esni-13=draft-ietf-tls-esni-18=--html

Hmm. It does look like there are few substantial changes in that diff

that

might be worth re-checking, but I'm not trying to delay things with
nitpicking. If others feel the analysis of -13 is enough, then let's go.

Not quite answering the question, but I don't recall any code
changes affecting the crypto plumbing or interop since -13.

Cheers,
S.

thanks,
Rob

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

OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key

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

Re: [TLS] Working Group Last Call for ECH

2024-03-11 Thread Stephen Farrell




On 12/03/2024 00:49, Rob Sayre wrote:

On Mon, Mar 11, 2024 at 5:21 PM Christopher Patton 
wrote:


I don't believe there were any changes from draft 13 to 18 that would
invalidate security analysis for draft 13:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-esni-13=draft-ietf-tls-esni-18=--html



Hmm. It does look like there are few substantial changes in that diff that
might be worth re-checking, but I'm not trying to delay things with
nitpicking. If others feel the analysis of -13 is enough, then let's go.


Not quite answering the question, but I don't recall any code
changes affecting the crypto plumbing or interop since -13.

Cheers,
S.



thanks,
Rob


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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Working Group Last Call for ECH

2024-03-11 Thread Stephen Farrell



Hiya,

On 11/03/2024 22:08, Rob Sayre wrote:

I think it is ready and can live with the current draft.


Same here. The protocol's well baked. The text good
enough. I've written code to implement it, done the
interop with others, deployed test services and done
PoC integrations of my openssl ECH stuff and various
applications and it all works.

I do plan to give it a read-through again to see if
there are any bits that might be so confusing as to
need fixing, but I don't expect to find much, given
I've been over that text fairly often.

Cheers,
S.



OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Status of draft-ietf-tls-esni

2024-02-17 Thread Stephen Farrell




On 17/02/2024 18:56, Eric Rescorla wrote:

I should be able to spin a WGLC-ready version of ECH before the
draft deadline.


Good stuff, thanks. I'll plan to review the proposed
changes with a strong bias for not asking for more:-)

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Input on ECH specification

2024-02-07 Thread Stephen Farrell



Hiya,

Would have to read the other bits but this jumped out...

On 07/02/2024 22:06, Elardus Erasmus wrote:

Make it clear that if an ECH extension is absent from the
server_hello, it qualifies as an ECH disabling signal.

When ECH is in real use, most SH messages won't contain
an ECH extension as the acceptance signal is encoded in
bits of the SH.random. You only see an ECH extension in
a SH when we hit HRR. (IIRC.)

Apologies if I'm misinterpreting you in the quote above.
Just sending now in case correcting this changes other
bits of your mail (or how I should read it:-)

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Late holiday gifts

2024-01-18 Thread Stephen Farrell




On 18/01/2024 17:46, Salz, Rich wrote:

Per last IETF meeting [1] I thought ECH was going to go to WGLC.  Were we 
waiting for a new draft?  Something else?


Looking a bit like we're an errata-only mailing list last while:-)

Processing those is of course worthy (probably) but so is finishing
existing specs that've been deployed already.

So yeah, I agree WGLC would be timely.

S.



[1] https://datatracker.ietf.org/doc/minutes-118-tls-202311060830/


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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] ECH: Changes to IANA consideration section

2024-01-15 Thread Stephen Farrell



Hiya,

On 19/12/2023 16:42, Stephen Farrell wrote:



On 19/12/2023 16:34, Sean Turner wrote:

FYI the assignments have been made.


Great. Can I ask what's the plan for WGLC? Be great if that
could be started before the holidays:-)


Good that the IANA registrations are done.

Can I ask when will we see the long-overdue WGLC?

I would assert that this now almost 5 year old draft is pretty
well-baked, having been widely deployed already, and it's time
we extract it from of the IETF oven:-)

Thanks,
S.

PS: There is a previously-stated reason to push on this - with
some open source libraries, (in particular OpenSSL), having the
RFC issued is required before code is merged, and getting ECH
code into such libraries is a prerequisite for it getting into
some web server applications, so the longer we take with this,
the more we encourage centralisation of services and the worse
we do with encouraging potential adoption for de-centralised
sets of servers. So, how about we get off the pot?


Ta,
S.



spt


On Dec 12, 2023, at 09:11, Sean Turner  wrote:

I should also included a link to the revised PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/597

spt


On Dec 11, 2023, at 22:01, Sean Turner  wrote:

I am going to go ahead and forward this. Note that since the 
“Comments” column isn’t a thing until we get 8447bis through the 
door the note will follow.


spt


On Dec 6, 2023, at 14:46, Sean Turner  wrote:

Okay a new proposal the ech_outer_extensions registration:
- Set "TLS 1.3" column to “CH”
- Include the following note in our new “Comments” column [0]: 
"Only appears in inner CH."


spt

[0] PRs:
https://github.com/tlswg/rfc8447bis/pull/48
https://github.com/tlswg/rfc8447bis/pull/49

On Nov 29, 2023, at 16:09, Stephen Farrell 
 wrote:



Hiya,

On 27/11/2023 14:35, Sean Turner wrote:

Bumping this up in case anybody missed it.


'case it helps, I'm fine with the original mail you sent and any of
"n/a" or "CH" being used rather than "-". If it helps, I've a very
minuscule hint of a preference for "CH" so you can count me as 
agreeing

with MT.

But I won't object to any other thing, 'cause I don't think there's a
perfect answer, and it matters very little, and defining a new thing
like "CHI" just for this seems OTT, but meh, I could even live with
that too.

I'd also be fine with this just left to chair/editor discretion FWIW.
While it's good to bring things like that to the list, I don't
think you need to delay based on a small-ish set of responses.

Cheers,
S.




spt

On Nov 21, 2023, at 21:03, Sean Turner  wrote:

Hi! I sent over the early allocation request and the IANA folks 
rightly pointed out two things that need to be added. This email 
is to make sure we have agreement on the two changes to the 
registrations in s11.1. If you don’t agree with the values 
proposed below please let the list know by 1 December 2023.


1. The encrypted_client_hello and ech_outer_extensions 
registrations need to indicate the value for the "DTLS-Only” 
column. Unless I am mistaken, “N” is the obvious value for both. 
See https://github.com/tlswg/draft-ietf-tls-esni/pull/584


2. The "TLS 1.3” column for ech_outer_extensions registration 
needs to indicate a value; remember, this column indicates the 
messages in which the extension may appear.  Currently, it’s “”. 
“N/A" has been suggested, which makes sense to me considering 
this extension never directly appears in CH, SH, EE, CT, CR, 
NST, or HRR extensions field. We can’t use “-“ because that 
means not used in TLS 1.3. “” is used elsewhere in the registry 
by only for unassigned and reserved values.  The following PR 
change “” to “N/A”: 
https://github.com/tlswg/draft-ietf-tls-esni/pull/59


Cheers,
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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] 0RTT freshness test does not work well when delays are in minutes

2024-01-10 Thread Stephen Farrell



Hiya,

Interesting question...

On 11/01/2024 00:07, Christian Huitema wrote:

I am wondering what the proper fix should be.


I don't know the answer (or if there's one answer) but
suspect that it may be better to first explore various
scenarios (as you've kinda kicked off with forwarding to
the deepspace list) and then come back to TLS implementers
with an ask based on some of those.

I also suspect that one'd need to use some kind of callback
that e.g. can query ephemeris data, as a number of scenarios
would involve RTTs that vary significantly over time, but
adding such callbacks to implementations could be dangerous
in more typical Internet environments.

Lastly, I'd guess that replay of early_data for applications
in some deepspace scenarios would be so dangerous that one'd
be better to not use early_data but rather to export a key and
then use that with an application that itself knows how to handle
replayed data. So maybe exploring ways to use key exporters is
also something to consider, rather than using early_data. (For
cases where new deepspace applications are developed that want
to use TLS.)

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] ECH: Changes to IANA consideration section

2023-12-19 Thread Stephen Farrell

On 19/12/2023 16:34, Sean Turner wrote:

FYI the assignments have been made.

Great. Can I ask what's the plan for WGLC? Be great if that
could be started before the holidays:-)

Ta,
S.

spt

On Dec 12, 2023, at 09:11, Sean Turner wrote:

I should also included a link to the revised PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/597

spt

On Dec 11, 2023, at 22:01, Sean Turner wrote:

I am going to go ahead and forward this. Note that since the “Comments” column
isn’t a thing until we get 8447bis through the door the note will follow.

spt

On Dec 6, 2023, at 14:46, Sean Turner wrote:

Okay a new proposal the ech_outer_extensions registration:
- Set "TLS 1.3" column to “CH”
- Include the following note in our new “Comments” column [0]: "Only appears in
inner CH."

spt

[0] PRs:
https://github.com/tlswg/rfc8447bis/pull/48
https://github.com/tlswg/rfc8447bis/pull/49

On Nov 29, 2023, at 16:09, Stephen Farrell wrote:

Hiya,

On 27/11/2023 14:35, Sean Turner wrote:

Bumping this up in case anybody missed it.

'case it helps, I'm fine with the original mail you sent and any of
"n/a" or "CH" being used rather than "-". If it helps, I've a very
minuscule hint of a preference for "CH" so you can count me as agreeing
with MT.

But I won't object to any other thing, 'cause I don't think there's a
perfect answer, and it matters very little, and defining a new thing
like "CHI" just for this seems OTT, but meh, I could even live with
that too.

I'd also be fine with this just left to chair/editor discretion FWIW.
While it's good to bring things like that to the list, I don't
think you need to delay based on a small-ish set of responses.

Cheers,
S.

spt

On Nov 21, 2023, at 21:03, Sean Turner wrote:

Hi! I sent over the early allocation request and the IANA folks rightly pointed
out two things that need to be added. This email is to make sure we have
agreement on the two changes to the registrations in s11.1. If you don’t agree
with the values proposed below please let the list know by 1 December 2023.

1. The encrypted_client_hello and ech_outer_extensions registrations need to
indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” is the
obvious value for both. See https://github.com/tlswg/draft-ietf-tls-esni/pull/584

2. The "TLS 1.3” column for ech_outer_extensions registration needs to indicate a
value; remember, this column indicates the messages in which the extension may appear.
Currently, it’s “”. “N/A" has been suggested, which makes sense to me considering
this extension never directly appears in CH, SH, EE, CT, CR, NST, or HRR extensions
field. We can’t use “-“ because that means not used in TLS 1.3. “” is used elsewhere in
the registry by only for unassigned and reserved values. The following PR change “” to
“N/A”: https://github.com/tlswg/draft-ietf-tls-esni/pull/59

Cheers,
spt

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

OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-13 Thread Stephen Farrell



Hiya,

On 13/12/2023 13:18, Bas Westerbaan wrote:

Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's
deployable, and whether its performance is acceptable, is something we
should figure out.)


I guess we're just interpreting "as-is" differently. What I
meant by "as-is" was an implementation of the current draft.
I agree that we can figure out how to use a PQ KEM with ECH
but that's work still to be done, and hence wasn't included
in what I meant by "ECH as-is."

Cheers,
S.

PS: I do not want us to hold up producing the ECH RFC while
we figure that out - we should get the current thing out the
door first!


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-12 Thread Stephen Farrell



Hiya,

On 12/12/2023 17:08, Russ Housley wrote:

Stephen:

I've been thinking about your point.  Some people want to use RFC
8773 to protect data that is transmitted today and recorded from the
future invention of a quantum computer.  To do this, the handshake
includes the identifier for the external PSK, and an observer can get
tracking data by watching which clients and servers have the same
external PSK.  This tracking data does not need the same long-term
protection as the TLS protected content.  So, the high-level guidance
in the proposed text seems appropriate.  That is, rotation of the
external PSK identity or the use of the Encrypted Client Hello
extension.  I think you are correct, the "with algorithms that a
secure against a CRQC" should be dropped.


Right, I think that means that ECH as-is can be used, but in the face
of a CRQC, ECH as-is won't protect against the leakage about which
John was concerned.

If one is worried about a future CRQC, then using ECH as-is should be
fine and protects for now against that leakage. (One might even add a
bit of text recommending that this extension only be present in the
inner CH whenever ECH is in use?)

Using some future PQ version of ECH can't be done yet, and figuring
out how a PQ-version of ECH would work and not involve too-large a CH
is another day's work.

Cheers,
S.





Russ



On Dec 6, 2023, at 4:21 PM, Stephen Farrell
 wrote:


Hiya,

On 06/12/2023 21:06, Russ Housley wrote:

Stephen: Maybe.  ECH would need to be updated to use PQC
algorithms to get that protection. Ill add that point: Appendix
E.6 of [RFC8446] discusses identity-exposure attacks on PSKs.
Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses 
tracking prevention.  The guidance in these sections remain

relevant. If an external PSK identity is used for multiple
connections, then an observer will generally be able track
clients and/or servers across connections.  The rotation of the
external PSK identity or the use of the Encrypted Client Hello
extension [I-D.ietf-tls-esni] with algorithms that a secure
against a CRQC can mitigate this risk.


That'd be a fairly giant outer client hello though if you include 
real PSK stuff in the inner CH, more or less any PQ hybrid scheme 
and the phoney/GREASE PSK stuff in the outer CH. I dunno if it'd be

feasible to use in practice, which would seem telling in terms of
promotion from experimental. I think someone would need to check 
the numbers and/or maybe figure out if the phoney/GREASE outer PSK 
stuff can be safely omitted in this context, and then write down 
how to do that.


I suspect that could end up with something that'd work ok, but
it'd need some work, and that's in addition to saying how to do the
PQ thing for ECH, which'd involve a number of design decisions I
think, and might in itself be a bit of an experiment.

So I don't think a quick bit of text about ECH solves the problem 
John raised in this context, or, at least, it'd be a non-trivial 
solution, and maybe more that you'd want if starting with with the 
goal in the subject line? (Not trying to be negative, just not at 
all sure.)


Cheers, S.


Russ

On Dec 6, 2023, at 4:00 PM, Stephen Farrell
 wrote:


Hiya,


(3) The privacy considerations already talk about Appendix
E.6 of [RFC8446].  I am please to add a pointer to ECH, but I
do not think that ECH use should not be mandated.


While I'm a fan of ECH, does it actually do the trick here? If
the adversary has a CRQC then we'd need an updated ECH that's
not vulnerable in that scenario, and we don't have that now.
(And it might be hard to get to, given MTU sizes.)

Cheers, S.


I suggest: Appendix E.6 of [RFC8446] discusses
identity-exposure attacks on PSKs.  Also, Appendix C.4 of
[I-D.ietf-tls-rfc8446bis] discusses tracking prevention.  The
guidance in these sections remain relevant. If an external
PSK identity is used for multiple connections, then an
observer will generally be able track clients and/or servers 
across connections.  The rotation of the external PSK

identity or the use of the Encrypted Client Hello extension
[I-D.ietf-tls-esni] can mitigate this risk. Russ
On Dec 6, 2023, at 11:51 AM, John Mattsson 
 wrote: Hi, I

am quite convinced that the security properties are not
worse than a mixture of PSK authentication, PSK key
exchange, (EC)DHE key exchange, and signature
authentication. In some cases, this is very good. You get
the quantum-resistance of the PSK together with the PFS of
ECDHE, and the entity authentication and security policies
of certificates. In other cases, it is not so good as the
reuse of a PSK identifier enables tracking and potentially
identification of both the client and the server. I don’t
think that such a field enabling tracking belongs in modern
TLS, but reuse of a PSK identifier is already in RFC 8446 
so this document does theoretically not make the worst-case

worse. If RFC 8773 is updated. I think the following things
should be updated: - The title and abs

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-06 Thread Stephen Farrell



Hiya,

On 06/12/2023 21:06, Russ Housley wrote:

Stephen:

Maybe.  ECH would need to be updated to use PQC algorithms to get that 
protection.

Ill add that point:

Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
tracking prevention.  The guidance in these sections remain relevant.

If an external PSK identity is used for multiple connections, then an
observer will generally be able track clients and/or servers across
connections.  The rotation of the external PSK identity or the use of
the Encrypted Client Hello extension [I-D.ietf-tls-esni] with
algorithms that a secure against a CRQC can mitigate this risk.


That'd be a fairly giant outer client hello though if you include
real PSK stuff in the inner CH, more or less any PQ hybrid scheme
and the phoney/GREASE PSK stuff in the outer CH. I dunno if it'd
be feasible to use in practice, which would seem telling in terms
of promotion from experimental. I think someone would need to check
the numbers and/or maybe figure out if the phoney/GREASE outer PSK
stuff can be safely omitted in this context, and then write down
how to do that.

I suspect that could end up with something that'd work ok, but it'd
need some work, and that's in addition to saying how to do the PQ
thing for ECH, which'd involve a number of design decisions I think,
and might in itself be a bit of an experiment.

So I don't think a quick bit of text about ECH solves the problem
John raised in this context, or, at least, it'd be a non-trivial
solution, and maybe more that you'd want if starting with with the
goal in the subject line? (Not trying to be negative, just not at
all sure.)

Cheers,
S.



Russ


On Dec 6, 2023, at 4:00 PM, Stephen Farrell  wrote:


Hiya,


(3) The privacy considerations already talk about Appendix E.6 of
[RFC8446].  I am please to add a pointer to ECH, but I do not think
that ECH use should not be mandated.


While I'm a fan of ECH, does it actually do the trick here?
If the adversary has a CRQC then we'd need an updated ECH
that's not vulnerable in that scenario, and we don't have
that now. (And it might be hard to get to, given MTU sizes.)

Cheers,
S.


I suggest:
Appendix E.6 of [RFC8446] discusses identity-exposure attacks on PSKs.  Also, 
Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses tracking prevention.  The 
guidance in these sections remain
relevant.
If an external PSK identity is used for multiple connections, then
an observer will generally be able track clients and/or servers
across connections.  The rotation of the external PSK identity or the
use of the Encrypted Client Hello extension [I-D.ietf-tls-esni] can
mitigate this risk.
Russ

On Dec 6, 2023, at 11:51 AM, John Mattsson
 wrote:
Hi,
I am quite convinced that the security properties are not worse
than a mixture of PSK authentication, PSK key exchange, (EC)DHE key
exchange, and signature authentication.
In some cases, this is very good. You get the quantum-resistance of
the PSK together with the PFS of ECDHE, and the entity
authentication and security policies of certificates. In other
cases, it is not so good as the reuse of a PSK identifier enables
tracking and potentially identification of both the client and the
server. I don’t think that such a field enabling tracking belongs
in modern TLS, but reuse of a PSK identifier is already in RFC 8446
so this document does theoretically not make the worst-case worse.
If RFC 8773 is updated. I think the following things should be
updated: - The title and abstract only talks about PSK
authentication. The key exchange is likely more important to make
quantum-resistant than the authentication. I think the title and
abstract should talk about PSK key exchange. - I think the
paywalled references should be removed. I think paywalled
references are both a cybersecurity risk and a democracy problem
[1]. I don’t think they belong in RFCs unless absolutely necessary.
RFC 8446bis recently removed all paywalled references. - The
document should refer to section C.4 of RFC8446bis that now
includes a short discussion on that reuse of an PSK identifier
enables tracking. I think RFC8773bis should have a warning early
that the privacy properties are much worse than the normal
certificate-based authentication. This could be completely solved
by mandating ECH. Alternatively, it could be solved by sending the
PSK identifier after flight #1 when things are encrypted.
3GPP specified the use of server certificate authentication
combined with PSK authentication and key exchange for TLS 1.2. As
that mode was not available in RFC 8446, 3GPP does not specify this
mode for TLS 1.3 but there have recently been discussions in 3GPP
about adding RFC 8773. I think the really bad privacy properties of
PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy
properties of TLS 1.3 with PSK have also been discussed several
times in EMU WG. I think a mode

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-06 Thread Stephen Farrell



Hiya,


(3) The privacy considerations already talk about Appendix E.6 of
[RFC8446].  I am please to add a pointer to ECH, but I do not think
that ECH use should not be mandated.


While I'm a fan of ECH, does it actually do the trick here?
If the adversary has a CRQC then we'd need an updated ECH
that's not vulnerable in that scenario, and we don't have
that now. (And it might be hard to get to, given MTU sizes.)

Cheers,
S.



I suggest:

Appendix E.6 of [RFC8446] discusses identity-exposure attacks on 
PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses 
tracking prevention.  The guidance in these sections remain

relevant.

If an external PSK identity is used for multiple connections, then
an observer will generally be able track clients and/or servers
across connections.  The rotation of the external PSK identity or the
use of the Encrypted Client Hello extension [I-D.ietf-tls-esni] can
mitigate this risk.

Russ



On Dec 6, 2023, at 11:51 AM, John Mattsson
 wrote:

Hi,

I am quite convinced that the security properties are not worse
than a mixture of PSK authentication, PSK key exchange, (EC)DHE key
exchange, and signature authentication.

In some cases, this is very good. You get the quantum-resistance of
the PSK together with the PFS of ECDHE, and the entity
authentication and security policies of certificates. In other
cases, it is not so good as the reuse of a PSK identifier enables
tracking and potentially identification of both the client and the
server. I don’t think that such a field enabling tracking belongs
in modern TLS, but reuse of a PSK identifier is already in RFC 8446
so this document does theoretically not make the worst-case worse.

If RFC 8773 is updated. I think the following things should be
updated: - The title and abstract only talks about PSK
authentication. The key exchange is likely more important to make
quantum-resistant than the authentication. I think the title and
abstract should talk about PSK key exchange. - I think the
paywalled references should be removed. I think paywalled
references are both a cybersecurity risk and a democracy problem
[1]. I don’t think they belong in RFCs unless absolutely necessary.
RFC 8446bis recently removed all paywalled references. - The
document should refer to section C.4 of RFC8446bis that now
includes a short discussion on that reuse of an PSK identifier
enables tracking. I think RFC8773bis should have a warning early
that the privacy properties are much worse than the normal
certificate-based authentication. This could be completely solved
by mandating ECH. Alternatively, it could be solved by sending the
PSK identifier after flight #1 when things are encrypted.

3GPP specified the use of server certificate authentication
combined with PSK authentication and key exchange for TLS 1.2. As
that mode was not available in RFC 8446, 3GPP does not specify this
mode for TLS 1.3 but there have recently been discussions in 3GPP
about adding RFC 8773. I think the really bad privacy properties of
PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy
properties of TLS 1.3 with PSK have also been discussed several
times in EMU WG. I think a mode that sends the PSK identifier
encrypted would make a lot more sense for standard track.

I am not supportive of standard track unless the tracking problem
is solved. If the privacy problems are solved, I am however very
supportive. Adding an extra roundtrip is a small price to pay for
privacy. Adding a field (psk identifier) that can be used for
tracking to current certificate-based TLS is making privacy worse.
I don’t think that is a good idea or worthy of standards track.

Cheers, John Preuß Mattsson

[1]
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ

 From: TLS mailto:tls-boun...@ietf.org>> on
behalf of Dan Harkins mailto:dhark...@lounge.org>> Date: Wednesday, 6 December 2023 at
14:50 To: TLS@ietf.org  mailto:tls@ietf.org>> Subject: Re: [TLS] Call to Move RFC 8773
from Experimental to Standards Track


Hi,

I approve of this transition to standards track and I am
implementing this as well.

regards,

Dan.

On 11/29/23 7:51 AM, Joseph Salowey wrote:

RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication
with an External Pre-Shared Key) was originally published as
experimental due to lack of implementations. As part of
implementation work for the EMU workitem
draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
ongoing implementation work. Since the implementation status of
RFC 8773 is changing, this is a consensus call to move RFC 8773
to standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis).




This will also help avoid downref for the EMU draft.  Please indicate

if you approve of or object to this transition to standards
track status by December 15, 2023.

Thanks,

Joe, Sean, and Deirdre

___ TLS mailing

Re: [TLS] ECH: Changes to IANA consideration section

2023-12-06 Thread Stephen Farrell

Hiya,

On 06/12/2023 19:46, Sean Turner wrote:

Okay a new proposal the ech_outer_extensions registration:
- Set "TLS 1.3" column to “CH”
- Include the following note in our new “Comments” column [0]: "Only appears in
inner CH."

Plenty good enough from my POV.

Cheers,
S.

spt

[0] PRs:
https://github.com/tlswg/rfc8447bis/pull/48
https://github.com/tlswg/rfc8447bis/pull/49

On Nov 29, 2023, at 16:09, Stephen Farrell wrote:

Hiya,

On 27/11/2023 14:35, Sean Turner wrote:

Bumping this up in case anybody missed it.

I'd also be fine with this just left to chair/editor discretion FWIW.
While it's good to bring things like that to the list, I don't
think you need to delay based on a small-ish set of responses.

Cheers,
S.

spt

On Nov 21, 2023, at 21:03, Sean Turner wrote:

Cheers,
spt

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

OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-06 Thread Stephen Farrell




On 06/12/2023 05:33, Deirdre Connolly wrote:

At the TLS meeting at IETF 118 there was significant support for the draft
'TLS 1.2 is in Feature Freeze' (
https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
is to confirm this on the list.  Please indicate if you support the
adoption of this draft and are willing to review and contribute text.


I read the draft and support adopting this. It'll probably
change as we go in some way or other but it's better that
the WG figure that out based on a WG draft.

Cheers,
S.



OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] ECH: Changes to IANA consideration section

2023-11-29 Thread Stephen Farrell

Hiya,

On 27/11/2023 14:35, Sean Turner wrote:

Bumping this up in case anybody missed it.

I'd also be fine with this just left to chair/editor discretion FWIW.
While it's good to bring things like that to the list, I don't
think you need to delay based on a small-ish set of responses.

Cheers,
S.

spt

On Nov 21, 2023, at 21:03, Sean Turner wrote:

Cheers,
spt

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

OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key

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

Re: [TLS] ECH: What changed?

2023-11-14 Thread Stephen Farrell



Hiya,

On 15/11/2023 02:09, Raghu Saxena wrote:
Interesting how the browsers have already rolled it out, but no major 
website (afaik) has. Even Cloudflare had to rollback their beta due to 
some issues[0]. Are there any websites (not test ones like defo.ie) that 
actually support ECH?


defo.ie is indeed a test site, but if anyone has an interest in
doing any larger scale web-site trials of ECH, please do ping me.
(That's probably off-topic for the TLS wg list, so off-list is
better.) We'd (the people behind defo.ie) be happy to chat
about what might be doable, and to offer what help we can. That
said, it'll take a while before web server ECH code is upstreamed
and can be easily switched on, so we'll need yet more patience;-)

Cheers,
S.



Regards,

Raghu

[0] 
https://community.cloudflare.com/t/early-hints-and-encrypted-client-hello-ech-are-currently-disabled-globally/567730


On 11/14/23 23:57, Dennis Jackson wrote:


Hi Rich,

During 117, both Firefox and Chrome were just starting to roll out ECH 
to release users and we had no sense of how it would go and I at least 
didn't feel we should progress without some deployment experience. 
These roll outs finished a few weeks later, see e.g [1,2] and went 
fairly smoothly, and today its deployed at 100% in both Firefox and 
Chrome, with ECH GREASEing enabled as well.


Best,
Dennis

[1] https://blog.mozilla.org/en/products/firefox/encrypted-hello/

[2] https://chromestatus.com/feature/6196703843581952



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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] SVCB codepoint for ECH

2023-09-21 Thread Stephen Farrell




On 21/09/2023 16:01, Salz, Rich wrote:



   
https://github.com/tlswg/draft-ietf-tls-esni/pull/553


Looks good to me.


+1

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

2023-09-18 Thread Stephen Farrell



Hiya,

On 19/09/2023 01:45, Sean Turner wrote:

Hi! After discussions with the authors of draft-ietf-tls-esni, Joe
and I would like to determine whether there is consensus to request
two early code point assignments; see RFC 7120. One is for the
encrypted_client_hello extension and one is for the ech_required
alert; see s11 of the I-D. Please let the list know by 03 October
2023 if you support these early allocations.


I support doing that.

I wonder if we also need to say something about the ech= SVCB
parameter value 5 that's reserved at [1]? Not sure, but maybe
no harm to make that "official" at the same time if possible.
(There could be current code that assumes that 5 in a wire-
format HTTPS RR value maps to 0xff0d within an ECHConfigList
even if that isn't really right.)

I'd also like if we had some agreement about how to handle
experiments that should migrate from current codepoints to
new ones. I don't really mind how we do that, but it should
help if we try publicly co-ordinate the timing for changing
from 0xff0d to a new codepoint. Given there aren't that many
implementations or deployments, a flag-day might be ok, (or
even useful?) but I dunno if a flag-day would be ok for
everyone, or if we need to plan for some short-ish duration
during which both old and new codepoints warrant some level
of support, just so as not to break existing things and look
bad:-) And if we will have some such interregnum, then it'd
probably also be good to say if we expect that to be handled
via ECHConfigList's that have >1 entry and version or if we
expect people to support >1 HTTPS RR value be published. I
think all of that could be handled via a "here's the
plan:..." mail sent to this list though and doesn't need
more than that.

Cheers,
S.

[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#name-initial-contents


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] ECH-HRR Design Team output

2023-08-29 Thread Stephen Farrell



Hiya,

Wasn't sure which email to reply to, but this one'll do...

Until very recently I was of the opinion that ECH split-mode
when one hits HRR with our current design was significantly
problematic.

The main reason was that supporting that scenario with
haproxy seemed like it'd require significant change to the
application, as haproxy is basically designed to only look
at the first ClientHello message when acting as a frontend
that doesn't terminate the TLS session, but just routes
sessions based on the first ClientHello SNI. (Doing ECH
decryption on the 1st ClientHello was ok, but getting at
the 2nd one with all the right state was the problem due
to how the application code was architected.)

With some more delving into things, I've managed to find
a relatively doable (if slightly iccky) way to support ECH
split-mode+HRR in both haproxy and nginx, so I think we can
strike this as an objection to the current design.

This likely affects a few of the issues in github, (in a
good way:-) but I didn't comment on those as it doesn't
quite fit any of 'em exactly. It should in any case help
as the editors set out to close issues,

My proof-of-concept code for nginx [1] and haproxy [2]
is available and if anyone's interested in details I'm
happy to point out specifics. (Note that that code is
far from production-ready but I think it's good enough
to show support is possible without that much change.)

Cheers,
S.

[1] https://github.com/sftcd/nginx/tree/ECH-experimental
[2] https://github.com/sftcd/haproxy/tree/ECH-experimental

On 03/06/2021 22:03, Christopher Wood wrote:

Hi folks,

Since the last IETF meeting, the HRR Design Team has worked through 
the issue of dealing with HRR. A writeup of the team's efforts, 
discussions, and recommendations is here:


https://github.com/tlswg/draft-ietf-tls-esni/wiki/HRR-Design-Team

We believe next steps are to merge the following PRs:

- https://github.com/tlswg/draft-ietf-tls-esni/pull/423 - 
https://github.com/tlswg/draft-ietf-tls-esni/pull/422


To that end, we would appreciate additional review. Hearing no 
objections, we'll plan to merge these at the end of next week and 
close out the relevant issues.


Thanks, all!

Best, Chris

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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge

2023-08-01 Thread Stephen Farrell



Hiya,

I saw the presentation and scanned the draft and support
adoption on the basis that this could be useful before
any certificates using PQC algorithms are in play so the
target of an experimental RFC is fine, even moreso as I
could imagine details/codepoints changing over time as
new better compressions are found.

I could see this also being a valuable input to work that
aims to evolve PKI in the face of a potential CRQC but I
think it'd be premature to adopt on that basis alone as
that overall topic needs broader consideration (best done
IMO in a year or two and not now). In any case, I guess
the CCADB doesn't and won't have entries using PQC algs
for some time, and they might decide to handle things in
some other way themselves so I'm not sure adopting this
as a PQ scheme now actually makes sense.

IIUC it's also a bit of a pity that this'd be formally
limited to the WebPKI, being based on the CCADB. I guess
handling the pretense that nobody uses letsencrypt for
smtp/tls is probably better handled as part of another
discussion elsewhere. (One worth having though.)

Cheers,
S.


On 01/08/2023 20:35, Christopher Wood wrote:

Hi all,

Based on positive feedback received during IETF 117, this email begins an adoption call 
for "Abridged Compression for WebPKI Certificates" 
(draft-jackson-tls-cert-abridge).

The datatracker page for this document can be found here:
https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/

And the GitHub repository can be found here:
https://github.com/dennisjackson/draft-jackson-tls-cert-abridge

Please indicate whether or not your support adoption of this document in its 
current state. Procedure questions raised during the WG meeting last week can 
be ironed out in the event of this item being adopted.

This call for adoption will conclude on August 16.

Thanks,
Chris, for the chairs
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] tls@ietf117

2023-07-18 Thread Stephen Farrell



Will probably turn up anyway in the draft status section
but last time a couple of people said they hoped to be
able to report on ECH experimentation in roughly this
timeframe, so be great if someone could pull together a
short slot with that info (if it's ready).

Cheers,
S.

On 17/07/2023 17:22, Sean Turner wrote:

And another gentle reminder.

Cheers,
spt


On Jul 11, 2023, at 10:42, Sean Turner  wrote:

Now that the submission deadline has passed … here’s a gentle reminder!

Cheers,
spt


On Jun 18, 2023, at 19:25, Sean Turner  wrote:

The TLS WG is planning to meet at IETF 117. A 2 hour slot has been requested, 
but not yet scheduled. The chairs would like to solicit input from the WG for 
agenda topics. Please send your agenda topics request and an estimate for how 
much time you will need to tls-cha...@ietf.org. Please note that we will 
prioritize existing WG items. Please also review the guidance for TLS WG 
presenters that can be found at [1].

Cheers,
Chris, Joe, and Sean

[1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md




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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] NIST Draft comments period: Addressing Visibility Challenges with TLS 1.3

2023-05-18 Thread Stephen Farrell



Hiya,

On 18/05/2023 05:43, John Mattsson wrote:

I think IETF should state in the LS that:

The IETF maintains copyright and change control for TLS
specifications. Having a separate, different, protocol named "TLS"
but developed by another SDO is a recipe for confusion among
developers, implementers, and users alike. 


I'm not sure that the copyright issue really comes up
wrt this NIST activity - seems more likely NIST would
issue some report on "NIST's ideas for HOWTO do TLS
badly" rather than try define a borked version of TLS
a la ETSI. (I'd also guess that even people who want
to weaken TLS would learn lessons from others failed
attempts;-)


Reuse of key shares
violate the design and operational assumptions of TLS 1.3 


The above is the key point yes. I do think there's
value in having something to point imeplementers at
that says the IETF don't agree with NIST's bad ideas
here.


and render
this NIST profile as a qualitatively different protocol that should
be named accordingly. We therefore formally request that NIST alter
the name of its work on a protocol with key share reuse so that
implementors, users, and governments are not confused about its
properties or the properties of TLS.


Again, not sure thinking about this in terms of a
different "weaker NIST-version of TLS" is likely the
best way to try get them to see sense. In this case
it may be better to point at MUSTs or SHOULDs or
other RFC text they're asking be violated.

Cheers,
S.

PS: FWIW, mostly unrelated, but this NIST activity (and
I guess the dual-ec debacle) makes at least me somewhat
less keen on just accepting NIST's choices for PQ things.
If that applied to others, it may become relevant (in
terms of the ease of achieving consensus) when we get to
which hybrid stuff to standardise for TLS in the not too
distant future.



Where the above text is more or less copy pasted from the LSs to
ETSI.

Cheers, John


On 2023-05-17, 20:43, "Stephen Farrell" 
wrote:

Hiya,

On 17/05/2023 18:49, John Mattsson wrote:

Hi,

Should IETF / SEC / TLS send an LS to NIST as was done with
ESTI-TC-CYBER?


Yes. Other relevant bodies defining ways to weaken the hard-won
security of IETF protocols really ought always be (nicely) told
they're doing a bad thing.

I sent NIST my own comments (also with an attempt at "nicely":-) and
would encourage others to do similarly, even though it's not that
likely they'll take much notice I suspect (on the basis that they
even started this IMO bad-idea-factory activity).

Cheers, S.



https://datatracker.ietf.org/liaison/1538/ 
https://datatracker.ietf.org/liaison/1616/


A lot of the comments in the LSs to ESTI-TC-CYBER also apply to the
NIST work.

"Our foremost concern is the use of the name Transport Layer
Security (TLS), a well-known protocol which has been developed by
the IETF for over twenty years. The IETF maintains copyright and
change control for TLS specifications. Having a separate,
different, protocol named "TLS" but developed by another SDO is a
recipe for confusion among developers, implementers, and users
alike."

"The IETF remains strongly committed to fostering end-to-end
security, and the properties of TLS enable that for key IETF
protocols. We believe the ETSI work to proceed from a different
design goal: to enable third-party monitoring. Because applications
using TLS expect its end-to-end security properties, the re-use of
the name will create misunderstandings. We therefore formally
request that ETSI alter the name of its work enabling third-party
monitoring so that implementors, users, and governments are not
confused about its properties or the properties of TLS."

"the main area of divergence from TLS 1.3 to this MSP profile is
the replacement of the server’s "ephemeral" DH key with a "static"
DH key, which suffices to violate the design and operational
assumptions of TLS 1.3 and render this MSP profile as a
qualitatively different protocol that should be named
accordingly."

My feeling is that the IETF community is much more against reuse of
key shares now than in 2017. At IETF 116 there seemed to be
consensus to discourage psk_ke. RFC8446bis and RFC9325 now have
strong normative text discouraging key share reuse.

I personally think it is problematic and not very constructive if
IETF states that all visibility solutions are bad. It would in my
view be more pragmatic to state that some technical solutions are
better than other.

Cheers, John

From: TLS mailto:tls-boun...@ietf.org>> on
behalf of John Mattsson
mailto:40ericsson@dmarc.ietf.org>>



Date: Tuesday, 16 May 2023 at 15:59

To: Salz, Rich
mailto:40akamai@dmarc.ietf.org>>,
tls@ietf.org<mailto:tls@ietf.org>
mailto:tls@ietf.org>> Subject: Re: [TLS] NIST Draft
comments period: Addressing Visibility Challenges with TLS 1.3 Hi
Rich,

Good that you inform the TLS WG. I was plann

Re: [TLS] NIST Draft comments period: Addressing Visibility Challenges with TLS 1.3

2023-05-17 Thread Stephen Farrell



Hiya,

On 17/05/2023 18:49, John Mattsson wrote:

Hi,

Should IETF / SEC / TLS send an LS to NIST as was done with ESTI-TC-CYBER?


Yes. Other relevant bodies defining ways to weaken the
hard-won security of IETF protocols really ought always
be (nicely) told they're doing a bad thing.

I sent NIST my own comments (also with an attempt at
"nicely":-) and would encourage others to do similarly,
even though it's not that likely they'll take much notice
I suspect (on the basis that they even started this IMO
bad-idea-factory activity).

Cheers,
S.



https://datatracker.ietf.org/liaison/1538/
https://datatracker.ietf.org/liaison/1616/

A lot of the comments in the LSs to ESTI-TC-CYBER also apply to the NIST work.

"Our foremost concern is the use of the name Transport Layer Security (TLS), a well-known 
protocol which has been developed by the IETF for over twenty years. The IETF maintains copyright 
and change control for TLS specifications. Having a separate, different, protocol named 
"TLS" but developed by another SDO is a recipe for confusion among developers, 
implementers, and users alike."

"The IETF remains strongly committed to fostering end-to-end security, and the 
properties of TLS enable that for key IETF protocols. We believe the ETSI work to proceed 
from a different design goal: to enable third-party monitoring. Because applications 
using TLS expect its end-to-end security properties, the re-use of the name will create 
misunderstandings. We therefore formally request that ETSI alter the name of its work 
enabling third-party monitoring so that implementors, users, and governments are not 
confused about its properties or the properties of TLS."

"the main area of divergence from TLS 1.3 to this MSP profile is the replacement of the server’s 
"ephemeral" DH key with a "static" DH key, which suffices to violate the design and 
operational assumptions of TLS 1.3 and render this MSP profile as a qualitatively different protocol that 
should be named accordingly."

My feeling is that the IETF community is much more against reuse of key shares 
now than in 2017. At IETF 116 there seemed to be consensus to discourage 
psk_ke. RFC8446bis and RFC9325 now have strong normative text discouraging key 
share reuse.

I personally think it is problematic and not very constructive if IETF states 
that all visibility solutions are bad. It would in my view be more pragmatic to 
state that some technical solutions are better than other.

Cheers,
John

From: TLS  on behalf of John Mattsson 

Date: Tuesday, 16 May 2023 at 15:59
To: Salz, Rich , tls@ietf.org 
Subject: Re: [TLS] NIST Draft comments period: Addressing Visibility Challenges 
with TLS 1.3
Hi Rich,

Good that you inform the TLS WG. I was planning to do that but forgot. Ericsson 
is likely to provide the comments in the link below. We think it is good that 
NIST is doing this project, visibility is a problem, but our position is that 
reuse of key shares is not an acceptable solution.

https://github.com/emanjon/Publications/blob/main/Ericsson%20comments%20on%20NIST%20SP%201800-37A%20May%2013.pdf

Cheers,
John


From: TLS  on behalf of Salz, Rich 

Date: Tuesday, 16 May 2023 at 13:19
To: tls@ietf.org 
Subject: [TLS] NIST Draft comments period: Addressing Visibility Challenges 
with TLS 1.3
Public comment period open until June 26.

Quoting from https://content.govdelivery.com/accounts/USNIST/bulletins/359534b

This project builds on our earlier work, 
“https://www.nccoe.nist.gov/tls-server-certificate-management,” which showed 
organizations how to centrally monitor and manage their TLS certificates. We 
are now focusing on protocol enhancements such as TLS 1.3 which have helped 
organizations boost performance and address security concerns. These same 
enhancements have also reduced enterprise visibility into internal traffic 
flows within the organizations' environment. This project aims to change 
that--and has two main objectives:
• Provide security and IT professionals practical approaches and tools to help 
them gain more visibility into the information being exchanged on their 
organizations’ servers.
• Help users fully adopt TLS 1.3 in their private data centers and in hybrid 
cloud environments—while maintaining regulatory compliance, security, and 
operations.


___
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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [TLS] FW: New Version Notification for draft-rsalz-tls-tls12-frozen-00.txt

2023-05-17 Thread Stephen Farrell



Hiya,

On 17/05/2023 15:11, Salz, Rich wrote:

This is the "TLS 1.2 is frozen" draft promised in Yokohama.  I am
pleased to have Nimrod as co-author.  We think this is ready for
adoption :)


I'd be supportive of adoption. I think the draft could
do with a clearer statement to the effect that this one
will likely be "held" in the WG until there's rough
consensus that it's timely to make it an RFC, but
otherwise it seems good enough to adopt.

I'd guess this probably ought be a BCP too though, but
don't care that much.

I don't know if there'll need to be more exceptions
carved out for IANA registries or not, but that is
probably better debated after adoption.

Cheers,
S.




On 5/17/23, 10:08 AM, "internet-dra...@ietf.org
" mailto:internet-dra...@ietf.org>> wrote:




A new version of I-D, draft-rsalz-tls-tls12-frozen-00.txt has been
successfully submitted by Rich Salz and posted to the IETF
repository.


Name: draft-rsalz-tls-tls12-frozen Revision: 00 Title: TLS 1.2 is
Frozen Document date: 2023-05-17 Group: Individual Submission Pages:
8 URL:
https://www.ietf.org/archive/id/draft-rsalz-tls-tls12-frozen-00.txt 
Status:

https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/ Html:
https://www.ietf.org/archive/id/draft-rsalz-tls-tls12-frozen-00.html 
Htmlized:

https://datatracker.ietf.org/doc/html/draft-rsalz-tls-tls12-frozen




Abstract: TLS 1.2 is in widespread use and can be configured such
that it provides good security properties. TLS 1.3 is also in
widespread use and fixes some known deficiencies with TLS 1.2, such
as removing error-prone cryptographic primitives and encrypting more
of the traffic so that it is not readable by outsiders.


Both versions have several extension points, so items like new 
cryptographic algorithms, new supported groups (formerly "named 
curves"), etc., can be added without defining a new protocol. This 
document specifies that TLS 1.2 is frozen: no new algorithms or 
extensions will be approved.



Further, TLS 1.3 use is widespread, and new protocols should require 
and assume its existence.









The IETF Secretariat







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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

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

2023-04-21 Thread Stephen Farrell



This is just a keep-alive. We do plan substantive work before
the next IETF but this isn't it:-)

S

On 21/04/2023 20:45, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Transport Layer
Security (TLS) WG of the IETF.

Title   : A well-known URI for publishing ECHConfigList values.
Authors : Stephen Farrell
  Rich Salz
  Benjamin Schwartz
Filename: draft-ietf-tls-wkech-02.txt
Pages   : 8
Date: 2023-04-21

Abstract:
We propose use of a well-known URI at which an HTTP origin can inform
an authoritative DNS server, or other interested parties, about this
origin's Service Bindings, i.e. its "HTTPS" DNS records.  These
instructions can include Encrypted ClientHello (ECH) configurations,
allowing the origin to publish and rotate its own ECH keys.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-wkech/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-wkech-02

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-wkech-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-04 Thread Stephen Farrell



Hiya,

On 05/04/2023 02:47, Sean Turner wrote:

A post IETF 116 bump to make sure folks get their reviews in. If you
look at the diffs from RFC 8446 you can see not that much has
changed. We will also take “I read it and it looks good” response.


I looked at the diff between 8446bis-07 and 8446 and it seems
fine to me. My only comment is that C.4 says one "SHOULD NOT
reuse a key share" - I'd be happier if that was a "MUST NOT"
but understand if we stick with SHOULD NOT. If there were a
good reference showing that it's quite feasible to never
deliberately re-use a key share, even at scale, that'd be a fine 
addition. (I don't have such a reference to offer,

sorry;-)

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech

2023-03-27 Thread Stephen Farrell




On 28/03/2023 05:57, Salz, Rich wrote:

At TLS@IETF116, the sense of the room was that there was WG support to adopt 
draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus in the 
room. Please indicate whether you do or do not support adoption of this I-D by 
2359UTC on 18 April 2023. If do not support adoption, please indicate why.


Strong support.


Yep. No-brainer that one.

S.



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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] Merkle Tree Certificates

2023-03-11 Thread Stephen Farrell



Hiya,

I had a read and think this is a great topic for
discussion.

A few points:

- I think we'd benefit from trying to think through
the dynamics of this, e.g. how many of each entity
might we see and how'd that differ from the current
web PKI and possibly affect the web? (It's fine that
that analysis emerge in time, not asking for it now.)

- I do think the trust_anchors extension values might
be better off as e.g. truncated hashes of public keys
or something like that.

- Aside from better on-the-wire efficiency, I think
another reason to examine designs like this is that
adding multiple public keys and signatures to x.509
certs (one of the alternative designs) seems like it
might be a bit of a nightmare, as PKI libraries are
buggily updated to try handle that - designs like
this seem better in terms of keeping the new code in
a less risky place.

Cheers,
S.

On 10/03/2023 22:09, David Benjamin wrote:

Hi all,

I've just uploaded a draft, below, describing several ideas we've been
mulling over regarding certificates in TLS. This is a draft-00 with a lot
of moving parts, so think of it as the first pass at some of ideas that we
think fit well together, rather than a concrete, fully-baked system.

The document describes a new certificate format based on Merkle Trees,
which aims to mitigate the many signatures we send today, particularly in
applications that use Certificate Transparency, and as post-quantum
signature schemes get large. Four signatures (two SCTs, two X.509
signatures) and an intermediate CA's public key gets rather large,
particularly with something like Dilithium3's 3,293-byte signatures. This
format uses a single Merkle Tree inclusion proof, which we estimate at
roughly 600 bytes. (Note that this proposal targets certificate-related
signatures but not the TLS handshake signature.)

As part of this, it also includes an extensibility and certificate
negotiation story that we hope will be useful beyond this particular scheme.

This isn't meant to replace existing PKI mechanisms. Rather, it's an
optional optimization for connections that are able to use it. Where they
aren't, you negotiate another certificate. I work on a web browser, so this
has browsers and HTTPS over TLS in mind, but we hope it, or some ideas in
it, will be more broadly useful.

That said, we don't expect it's for everyone, and that's fine! With a
robust negotiation story, we don't have to limit ourselves to a single
answer for all cases at once. Even within browsers and the web, it cannot
handle all cases, so we're thinking of this as one of several sorts of PKI
mechanisms that might be selected via negotiation.

Thoughts? We're very eager to get feedback on this.

David

On Fri, Mar 10, 2023 at 4:38 PM  wrote:



A new version of I-D, draft-davidben-tls-merkle-tree-certs-00.txt
has been successfully submitted by David Benjamin and posted to the
IETF repository.

Name:   draft-davidben-tls-merkle-tree-certs
Revision:   00
Title:  Merkle Tree Certificates for TLS
Document date:  2023-03-10
Group:  Individual Submission
Pages:  45
URL:
https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-00.txt
Status:
https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/
Html:
https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-davidben-tls-merkle-tree-certs


Abstract:
This document describes Merkle Tree certificates, a new certificate
type for use with TLS.  A relying party that regularly fetches
information from a transparency service can use this certificate type
as a size optimization over more conventional mechanisms with post-
quantum signatures.  Merkle Tree certificates integrate the roles of
X.509 and Certificate Transparency, achieving comparable security
properties with a smaller message size, at the cost of more limited
applicability.




The IETF Secretariat






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


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


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

Re: [TLS] New Version Notification for draft-ietf-tls-esni-15.txt

2023-01-07 Thread Stephen Farrell



Hiya,

On 07/01/2023 15:46, John Mattsson wrote:

My current understanding is that draft-ietf-tls-esni should require
that the server MUST NOT reuse a key shares. Unless I miss something
I suggest adding that and one or two of the above figures to the
draft. An alternative solution would be to extend the ECH encryption
to also cover ServerHello. If I understand ECH correctly, the
ServerHello is still unencrypted.


I'd support adding a requirement that key shares not be
re-used, either as a general thing or in an ECH-specific
manner.


- As a main goal of ECH is to hide the server name, I think the draft
should explicitly mention padding of the server certificate message.
Some web servers are using very large certificate messages. If
padding is not used, they can be identified with a quite high
probability just by looking at the size.


I agree, but thought we'd discussed that before and
had added some text (can check later). FWIW, my openssl
fork defaults in s_server to padding the certificate,
certificateverify and encryptedextensions messages to
multiples of #define'd values. I'd support adding some
guidance for server libraries as to what to do there in
general. (OpenSSL supports such padding via a callback
that application servers can set but IIRC doesn't do
such padding by default today.)

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

2022-11-28 Thread Stephen Farrell



I'm ok with adoption so long as we include sufficient
caveats along the way (and then add more caveats just
in case:-)

If there were some technical means to ensure that this
was less likely to be abused, I'd like it more. (Could
we e.g. require inclusion of a TLS extension that has a
100kB cat-picture payload?)

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

2022-10-26 Thread Stephen Farrell



Hiya,

This is a "just wondering" type email...

On 26/10/2022 23:32, Martin Thomson wrote:

harder part: getting people interested in deploying a fix.


If ECH+PQ-hybrid turns out to be problematic (size-wise) and
PQ-hybrid by itself increases occurrences of HRR, and if ECH
is generally desirable, I wonder would people then be more
interested in additional guidance as to ClientHello content
being placed in HTPPS RRs?

Too early to say I'd guess, but maybe worth pondering.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] Published RFC 8446bis -05

2022-10-24 Thread Stephen Farrell



Hiya,

On 25/10/2022 03:27, Eric Rescorla wrote:

On Mon, Oct 24, 2022 at 7:17 PM Rob Sayre  wrote:


Is removing HRR on the table?



No, I don't think so. It performs an important function.


Is there any public info as to how often HRR happens?
(Sorry if that's well known, but it's not well known to
me:-)

Were that rare enough, I'd hope it'd be a thing where we
could reach consensus for deprecation. If it's not yet
sufficiently rare, it might be worth considering if we
could change something to make HRR less likely.

Cheers,
S.


Moreover, the intent of this revision to TLS 1.3 was to clarify 8446,
and this would be a major (and breaking!) change.




Maybe just opening a new socket would suffice?



I don't see that this would help.

1. It would not be clear to the client what it had to do to provide
an acceptable CH. 2. Without some sort of HRR-like coupling, it would
allow downgrade attacks.

-Ekr




thanks, Rob

On Mon, Oct 24, 2022 at 13:08 Eric Rescorla  wrote:


Hi Folks,

I have just published draft-ietf-tls-rfc8446bis-05, with the
following changes:

* Update the extension table (Issue 1241) * Clarify user_canceled
(Issue 1208) * Clarify 0-RTT cache side channels (Issue 1225) *
Require that message reinjection be done with the current hash. 
Potentially a clarification and potentially a wire format change

depending on previous interpretation (Issue 1227)

I landed a few current PRs without review. If people think I
handled these incorrectly or mis-merged, please flag that.

This includes most of the outstanding issues and PRs. The
following remain:

PRS 1275 -- Clarifying unsolicited extensions [Waiting for review
from Kaduk] 1270 -- The impact of excessive key updates [Working
on text with MT] 1269 -- A new error for invalid tickets [see
below] 1231 -- Update in light of RFC 8773 [I missed this, but
will get to it on my next pass]


SUBSTANTIVE ISSUES 1223, 1224 -- Revising the HRR rules 1278 --
There are no entries in the table for which TLS 1.3 messages
token binding goes in.


As preview of our discussion in London.

I believe I can handle 1275, 1270, and 1231 at the editorial 
level.


I believe we should not land 1269. As noted in the issue there
is already an unknown_psk_identity, which captures this. I
propose to close this issue.

We need to agree on what appears in the table for token binding. 
I think this is mechanical. MT? DavidBen? Andrei?



This leaves us with 1223 and 1224. I agree that the HRR
semantics are a little confusing, but we don't seem to be making
much progress on revising them and given that 8446 is already 
out, I think we should just publish this revision and then if

people get energy to address this issue we can do so later.


-Ekr









___ 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


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] Securely disabling ECH

2022-10-20 Thread Stephen Farrell



Hiya,

On 21/10/2022 00:44, Rob Sayre wrote:

I think the WG might want to consider how it spends its time. The ECH draft
has been adopted as a work item. In case it’s not obvious, this one is
going to be deployed prior to its document status. 


The above seems correct and apposite.


There’s no point in
arguing in the standards work.


That's badly phrased I think. Personally I think there's no
point in this thread (other than to ponder the interestingly
unidentified OP), but there can well be a point to arguments
about ECH (for example, based on having coded it up for
haproxy,(*) I'd still like to revisit the HRR and split-mode
combo even if it turns out we can't figure out a better way
to handle that).

Cheers,
S.

(*) Out of curiosity: has anyone else implemented a split-
mode client-facing server that handles HRR?



thanks,
Rob


On Thu, Oct 20, 2022 at 11:48 Safe Browsing 
wrote:


Certainly, within the umbrella of "Network Security", privacy is a
category. ECH falls into that category.

As with many things in life there is also a trade-off that ECH brings
along. More privacy, at possibly less "Network Security" (not a less secure
TLS connection), as noted in some of the other emails.

Thanks,

On Thu, Oct 20, 2022 at 12:14 AM Salz, Rich  wrote:



- ECH is not a security feature per se.



The ability of a third party to not be able to see who is communicating
is something that many would consider a security feature. Within the US
infosec community there was a great deal of uproar about NSA data
collection, even if it was “just” (sarcastic airquotes) metadata. Some may
disagree with that assessment, as you apparently do, but please don’t make
definitive statements like the above.



- But yes, what I am talking about is disabling ECH by an
entity/appliance other than the endpoints. One that is authoritative for
the public name, of course



The simplest way for an entity to disable ECH is to not have the DNS
records with the ECH keys.  If that means that TLS-inspecting middleboxes
now need to also become DNS servers, many would say that is the cost of
interception. Many would probably also say that’s not a reasonable cost to
impose, but I expect them to be in the minority viewpoint at the IETF.






___
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


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs

2022-10-18 Thread Stephen Farrell




On 18/10/2022 16:36, Ben Schwartz wrote:

On the topic of smaller hosts: not every IETF specification is equally
useful to everyone, and this is fine.  ECH provides more benefit when
applied to large hosts, but it doesn't_reduce_  privacy for anyone, so it
is safe to deploy on essentially any TLS server.


FWIW, I consider that smaller sites can benefit to
some extent from ECH as it can hide the difference
between a WFH employee accessing marketing.example
vs. engineering.example. I've no idea if that'd be
a thing enterprises might do but they could.

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs

2022-10-13 Thread Stephen Farrell



I agree with what Ben said, but in particular this:

On 13/10/2022 15:35, Ben Schwartz wrote:

I do think we have a lot to learn about the operational challenges of
deploying ECH, but our discussion about that should be driven by technical
reports from deployments, not speculation about political problems.


ISTM getting trial deployments at various scales (not
only the largest) is the right next step.

Lastly, while censorship circumvention may not be the
goal for ECH, the IETF defines plenty of technologies
for other purposes that can also be used to censor so
defining protocols that also enable circumvention is
entirely fine.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH not protect SNI

2022-08-24 Thread Stephen Farrell



Hiya,

On 24/08/2022 16:36, 涛叔 wrote:

I can't agree with you.


FWIW, I agree with ekr. I don't think the scheme
you outlined works, nor would it be a good basis
for changes to ECH. (Sorry;-)

As I said before, there may be some guidance we
can offer web server deployers in such cases but
I really can't see that involving "fake" names,
which come with all sorts of problems. (See the
recent dnsop discussion related to .alt for some
of the reasons why;-)

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH not protect SNI

2022-08-24 Thread Stephen Farrell



Hiya,

On 24/08/2022 09:34, 涛叔 wrote:

I am not saying ECH isn't going to work at all. Even most sites need
to be deployed behind cloud services, it not means we could design a
standard to make it as a requirement.

So let me try see if I understand by trying to re-phrase
your concern: the operator of a single web server with a
single DNS name and nobody else to help (no CDN, no hoster
no split-mode front-end doing ECH) still has to expose
their name in the cleartext SNI, even if they publish an
HTTPS RR with an ECH public key.

Is that about right? If so, I agree that's a limitation
of the value one can get from ECH.

I think Chris' answer wrt encrypting ALPNs etc is correct,
the ECH mechanism does still provide a (perhaps minor)
benefit in such cases, and as Ekr says, a client could send
a bogus SNI in clear in such a case and things should still
work fine if the client gets the right ECH public key.

Perhaps it could be worthwhile exploring that last point a
bit more than the WG has, with a goal of helping get to the
point where turning on ECH could be the norm when putting
up any web server, just as interacting with LE is now?

I'm not sure that it'd be feasible to depend on DNSSEC in
such cases to handle mismatched ECH public keys though.

There's also a problem that if some clients GREASE ECH but
real uses of ECH don't have the real DNS name as the outer
ClientHello SNI, (e.g. the name.invalid case), or make use
of the published ECH config_id, one could easily distinguish
real uses of ECH vs. GREASE cases which seems a bad outcome
too.

I could envisage us trying to provide some guidance for such
a scenario (maybe like; servers: don't rotate your ECH public
key and do enable ECH trial decryption, clients: use a random
config_id when not GREASEing if outer SNI == inner SNI). And
I guess that might help a bit to move the overall ecosystem
towards ECH being the norm, even if the operator of that
isolated web server won't get much real benefit from ECH.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH not protect SNI

2022-08-23 Thread Stephen Farrell



Hiya,

On 24/08/2022 02:26, 涛叔 wrote:

Hi, Stephen,

I actually has some trouble to understand your point.


Yes, perhaps we're not understanding one another and
it might help if you could describe what you think is
the win here? What would you like to see?




On Aug 24, 2022, at 08:58, Stephen Farrell
 wrote:

Factually, many people do deploy a web server hosted as a VPS by a
small hoster, so could benefit from ECH, to some extent. I know in
the small part of the world where I live (.ie) there are dozens of
such hosters who run probably tens of thousands of web sites. ISTM
making accesses to those less easily distinguished from one another
brings potential benefits.


My point there is some people run their website without intermediary
proxy. They still deserve the protection of ECH. 


"Deserve" seems like an odd term to use. If a web site
operator wants to benefit from ECH, then they need to be
part of a set of web sites where it's hard to distinguish
which is being accessed based on the TLS traffic.

Perhaps you disagree with some of the content of RFC8744
rather than the ECH mechanism?


So what is you point
here?


I think I made my point, perhaps badly, but nonetheless
it was made as well as it was:-) I don't think it'd help
either of us to only re-iterate.




I think you're wrong to only consider there being two cases of
interest. People are fairly inventive in how they use new tools
like ECH. But time will tell I guess.


I have said there are two cases, but has not stated there are only
two cases. 


I'm glad we agree there are a bunch of different ways in
which ECH could be used. I read your earlier mail as you
discounting anything other than the two cases you mentioned.
Sorry if that was wrong.


The current design of ECH requires an intermediary proxy
with dedicated domain name and SSL certificate to work. And I think
it is huge burden for indie website. 


"Huge burden" seems entirely wrong based on my experience.
It's very easy to setup a web site with TLS these days in
many different ways.

Cheers,
S.


So again, what is your point
here?

Thanks.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH not protect SNI

2022-08-23 Thread Stephen Farrell



Hiya,

On 24/08/2022 01:11, 涛叔 wrote:

What if there is no small hoster? If a person just buy a VPS to
deploy a HTTPS server, what should he do to deploy ECH?


Factually, many people do deploy a web server hosted as a
VPS by a small hoster, so could benefit from ECH, to some
extent. I know in the small part of the world where I live
(.ie) there are dozens of such hosters who run probably tens
of thousands of web sites. ISTM making accesses to those
less easily distinguished from one another brings potential
benefits.


As you say, he could use  the example.com 
domain to protect the hr.example.com . But
how could he protect the entire example.com ?

With the current design, he could either register another domain like
example.net  or deploy his site behind some
hoster like Cloudflare or others.

The first case will leak example.net , which is
equivalent to leak example.com  and make ECH
useless. The second case will make the Internet centralized more and
more, and make it impossible for home-hosted website to deploy ECH.


I think you're wrong to only consider there being two cases
of interest. People are fairly inventive in how they use new
tools like ECH. But time will tell I guess.

Cheers,
S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH not protect SNI

2022-08-23 Thread Stephen Farrell



Hiya,

On 24/08/2022 00:39, 涛叔 wrote:

It may be right for a common cloud platform, but what about indie
server? Every site who need ECH have to deploy an addition outer
domain to*protect*  the inner one. But these indie servers can not
share a common outer domain, so the have to use some distinct one who
doe one-to-one respond the inner one.

I don't believe that is the case. A small hoster can choose a
"public_name" and use that for customers. An enterprise of
whatever size can choose a "public_name" like example.com and
then use that and ECH to cover accesses to other internal names like 
accounts.example.com or hr.example.com. I know

there are a bunch of people who think by far the main value
of ECH relates to CDNs, and they may be correct, but I tend
to think the above approaches also have value.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

2022-08-19 Thread Stephen Farrell




On 19/08/2022 15:05, Salz, Rich wrote:

If it's a framework, and the framework seems to work for known
algorithms, then let's just publish the framework and add specifics
later.

I didn't conclude that the framework works so I'd
be against publishing now. (I do still need to
respond to the recent follow ups from WGLC though,
sorry for being slow with that.)

S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

2022-08-07 Thread Stephen Farrell



Hiya,

On 07/08/2022 21:58, Scott Fluhrer (sfluhrer) wrote:

Hence, what we are proposing is no less secure than what we are currently doing 
now.


Well, except there'll be a whole pile of new code, which
is a fine way to be less secure.

Now for key establishment that's not too bad perhaps, but
when I hear some of the certificate proposals (in lamps,
not really this wg), I just shudder.

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

2022-08-06 Thread Stephen Farrell




On 06/08/2022 17:47, Phillip Hallam-Baker wrote:

Are you proposing pure Kyber or a hybrid though?


I've not heard anyone suggest securing an IETF protocol
only via PQC algs. It'd be incredibly dim to make that
suggestion IMO, esp now that two of the 3rd round entries
have been busted. So I'm not worried that we'd even come
close to landing there for TLS.

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] PQC key exchange sizes

2022-07-26 Thread Stephen Farrell




On 26/07/2022 13:15, Thom Wiggers wrote:

Hi all,

In yesterday’s working group meeting we had a bit of a discussion of the
impact of the sizes of post-quantum key exchange on TLS and related
protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide
deck (unlike the signature schemes), I thought it would be a good idea to
get the actual numbers of Kyber onto the mailing list.

Note that in the context of TLS’s key exchange, the public key would be
what goes into the ClientHello key_shares extension, and the ciphertext
would go into the Server’s ServerHello key_shares extension.

Kyber512: NIST level I, "strength ~AES128"
   public key: 800 bytes
   ciphertext: 768 bytes
   secret key: 1632 bytes


Be interested in how that'd change the CH if ECH is used too.
I guess the answer mightn't make us happy;-)

S.


Kyber768: NIST level III, "~AES192"
   public key: 1184
   ciphertext: 1088
   secret key: 2400 bytes
Kyber1024: NIST level V, "~AES256"
   public key: 1568
   ciphertext: 1568
   secret key: 3168

So for the key exchange at least, it seems to me Kyber512 should work for
TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if you want to
stay in QUIC’s default 1300 byte initial packet? Also, I don't really know
how the D of DTLS might change the story.

All the numbers we reported are as of the latest version of the individual
submissions (except as discussed below). The standards that NIST eventually
names FIPS-xyz might have (mildly) different sizes. NIST has said that
they’re always happy to receive feedback and information about use cases
and constraints.

Lastly, Bas Westerbaan has talked about a Kyber draft in yesterday’s CFRG
meeting. I believe a stated goal is to use that for coordinating any
experiments before the NIST standard is out. So keep an eye out if that
interests you.

Cheers,

Thom

PS: Let me also correct the mistake I had introduced in the SPHINCS+
numbers in the TLS talk: SPHINCS+ has indeed gotten slightly smaller than
the numbers I reported. The smallest SPHINCS+ variant (sphincs+-128s) has a
signature size of 7,856 bytes. There’s a nice table with the different
parameter sets of SPHINCS+ on their Github repository
https://github.com/sphincs/sphincsplus#parameters. I’m glad that people
were paying attention, apparently more than I was :-)

I will also clarify that when we mentioned that Falcon needs very careful
attention when implementing, this concerns Falcon's signing routines. These
require constant-time double-width floating point maths; on many CPUs this
will need to be emulated in software. Verification, on the other hand, is a
lot less sensitive.


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


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] Call for adoption of draft-farrell-tls-wkesni

2022-06-08 Thread Stephen Farrell



Hi Ben,

On 08/06/2022 20:35, Ben Schwartz wrote:

I am supportive of this effort, but I am not convinced that the proposed
mechanism is right.


That's fair. FWIW, I do agree the issues you identify below
warrant discussion (my preference of course is to do that
after WG adoption:-)



In ECH, there are two essential deployment topologies: "shared" and
"split".  In "shared" mode there is operationally only one TLS server
(processing inner and outer ClientHellos); in "split" mode there are two.
Note that CDNs are an instance of "shared" mode, whereas "split" mode is a
novel architecture that somewhat resembles a L3 load balancer.

For coordination of ECHConfigs between CDNs and their customers, the SVCB
draft defines a clear and simple mechanism: use CNAME and/or SVCB AliasMode
to point at the CDN's record.  This avoids the need to copy any information
from the CDN zone into the customer zone, which adds complexity and creates
a risk of desynchronization.  I don't think this draft should try to
address that use case.


Correct. And the draft doesn't try address such deployments
where other mechanisms would be better. (I think you made a
comment before that some text somewhere that describes a set
of ECH or SVCB deployment options could be useful. I agree
with you about that - not sure an I-D/RFC would be the best
place for it though.)


For coordination between a "shared mode" HTTP server and its own DNS zone,
this draft could apply (although perhaps not with the current draft's path
structure).  


Actually, I think you'd still need (to be able to) use a
scheme like the current draft's to handle VirtualHosts. But
I'm not particularly tied to the current path structure
either.


However, it strikes me as incomplete, as it does not convey
all the other information that an HTTP server would likely want to use to
populate its DNS zone, such as ALPN and perhaps even IP addresses.  For
this application, I would prefer a version that is extensible to future
SvcParamKeys as well (e.g. dohpath [1], oblivious [2]).


I agree that's a topic to discuss - the current draft only
does what I needed and I was only using v. simple HTTPS RRs.
My first cut for such things would be to handle 'em by
allowing that kind of data to be part of the JSON responses.
Be nice if there was some way to characterise what kinds
of data make sense there so avoid the potential slipperly
slope though. (I do agree about inner alpns though - that
definitely makes sense.)


For coordination between a "split mode" server and the "backend" origin
zone, this draft seems to provide the right functionality, but its use of
HTTP seems odd, as neither party is otherwise obligated to use HTTP at
all. 


Well, my focus has been on where the ECH front-end (whether
shared or not) is a web server on which the ECH key pairs
are generated, so using HTTP there seems natural to me.


It might be preferable to tell the split mode server to publish its
ECHConfigs in a SVCB record, and instruct backends to copy it into their
HTTPS record.  


Could be. My guess is organisationally that'd be harder to
arrange, for organisations where different people manage the
DNS and web servers.


This would avoid asking DNS servers to become HTTP clients.


I figure the zone factory thing is more likely a hidden
primary or similar so I don't think that's tricky, but
fair point I guess.


While DNS is not necessarily secured, ECH excludes DNS-modifying
adversaries from its threat model, so this might be acceptable (although
the location of the attack is different in this case).


Yeah, another benefit of HTTP is server authentication. An
HTTP client in the zone factory also enables validation that
the ECH keys provided actually do work, before publishing
them in the DNS, which seems desirable to me.


Alternatively, this coordination could be achieved by a simple TTL
extension to the ECHConfig structure.  Zone Factories could retrieve an
up-to-date ECHConfigList by sending an empty inner_client_hello extension,
triggering the fallback mechanism to learn the ECHConfigList and its TTL.


I thought about that (and it's noted in the draft.) The
argument against is that the retry-configs (at least as I
provide 'em from web servers) only include the most-recent
ECH public key whereas the HTTPS/SVCB RRs include that plus
the older ones that still work. I would guess what one gets
in retry-configs might be too variable to use as the source
of data to publish in the DNS. And of course, you'd also
miss out on the other data (alpn etc.) you'd like to see in
the JSON or wherever.


So in summary, I am willing to review this draft, but I would prefer to
have more discussion from first principles about the use case and mechanism
before we pick a direction.


Again, I'd argue that'd all be better done after WG adoption.

Cheers,
S.




[1]
https://datatracker.ietf.org/doc/html/draft-ietf-add-svcb-dns#section-5.1
[2]

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

2022-05-02 Thread Stephen Farrell



Hiya,

Just on this one point:

On 02/05/2022 10:58, Ilari Liusvaara wrote:

Furthermore the extension involved (key_share) REALLY SHOULD NOT
differ between inner and outer hello.


I kinda agree, but the ECH spec allows 'em to differ.

In any case, the main point here is that this compression
issue is not discussed in the draft and IMO ought be before
the draft could be considered ready.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

2022-04-30 Thread Stephen Farrell



Hiya,

On 30/04/2022 10:05, Ilari Liusvaara wrote:

On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:


Hiya,

On 27/04/2022 16:27, Christopher Wood wrote:

This email commences a two week WGLC for draft-ietf-tls-hybrid-design, located 
here:

 https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/


As I guess I've said before, I think progressing this draft
now, even with this WGLC-then-park approach, is premature.

However, I seem to be in the rough on that so can live with
this ad-hoc process (teeth grinding mind you:-) so long as we
park this for a sufficient period *and* are open to changing
anything at the end of the parking-lot period.

Even so, I think this is not yet ready for any such ad-hoc
parking-lot:

- section 1.5 implies a wish to reduce the number of
octets sent - ECH creates a way to point from one part
of the (encrypted, inner) ClientHello to another (the
outer ClientHello). I don't think we want two such
mechanisms, or one mechanism defined in ECH but none at
all here, or even worse a second method. For me, that
implies not "freezing" the structural work here 'till
we see if ECH gets widespread deployment at which point
we should consider re-use of the ECH mechanism. (Or maybe
even consider both cases of re-using octets and invent
another thing, but not 'till we see if ECH gets traction.)


I don't think compression method like ECH uses would work here.


Possibly so. But I don't think we want two potentially
interacting compression hacks do we? My main point is that
this draft isn't yet in a place where all one needs later
is codepoint registrations and PQ alg implementations. I
think this aspect demonstrates that lack of readiness, no
matter how one resolves compressing, unless one never
compresses, which seems undesirable to me.



However, I did come up with compression method:

1) Sub-shares in CH may be be just replaced by a group id (two octets).
The replacements can be deduced from length of the whole share.
2) First sub-share copies from first octets of share for the designated
group.
3) Second sub-share copies from last octets of share for the designated
group.

This can be decoded regardless of if the sever knows what the referenced
groups are. The compression can also never run into loop, as recursive
references are not allowed.


So for example, if one wants to send x25519, p256, x25519+saber and
p256+saber, one can do that as:

- x25519:  (32+4 octets)
- p256:  (65+4 octets)
- x25519+saber:  (2+992+4 octets)
- p256+saber:  (2+2+4 octets)

Total overhead is 22 octets. 16 for 4 groups, and 6 for the compression
itself.


So yes that could work. We'd need to think through how
it'd interact with the ECH scheme were both to end up
standardised.

- section 2: if "classic" DH were broken, and we then
depend on a PQ-KEM, doesn't that re-introduce all the
problems seen with duplicating RSA private keys in
middleboxes? If not, why not? If so, I don't recall
that discussion in the WG (and we had many mega-threads
on RSA as abused by MITM folks so there has to be stuff
to be said;-)


No. The private key is held by the client, and client sends the public
key to use in its client hello. Furthermore, every connection should use
different public key.


Ok. (Sorry I was looking at [1] too and had that in my head
when writing the above, which ought be ignored as mine was a
silly comment:-)

   [1] 
https://datatracker.ietf.org/doc/html/draft-perret-prat-lamps-cms-pq-kem





- similar to the above: if PQ KEM public values are
like RSA public keys, how does the client know what
value to use in the initial, basic 1-RTT ClientHello?
(sorry if that's a dim question:-) If the answer is
to use something like a ticket (for a 2nd connection)
then that should be defined here I'd say, if it were
to use yet another SVCB field that also ought be
defined (or at least hinted at:-)


Whatever public key the keygen() operation outputs.


As above.




- I'm also HRR-confused - if we don't yet know the
details of the range of possible PQ KEM algs we want to
allow here, how do we know that we almost always continue
to avoid HRR in practice and thus benefit from a mixture of
classic and PQ algs? (It's also a bit odd that HRR,
much as I dislike it, doesn't get a mention here;-) I
think the problem is that we don't want HRR to push a
client back to only "classic" groups, if the client but
not the server is worried about PQ stuff while both
prioritise interop.


Well, avoiding HRR impiles that client is willing to bloat its client
hello even for servers that do not support PQ. And for such clients,
using PQ at all requires servers to priorize it (send HRR even if
acceptable share is present).


I don't understand the above sorry;-)

ISTM one would need to analyse/guess what'll happen with
this scheme and HRR before being done. Maybe someone's
done that but if so, I'm surprised there's no mention in
the draft.




- section 4: if this can

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

2022-04-29 Thread Stephen Farrell



Hiya,

On 27/04/2022 16:27, Christopher Wood wrote:

This email commences a two week WGLC for draft-ietf-tls-hybrid-design, located 
here:

https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/


As I guess I've said before, I think progressing this draft
now, even with this WGLC-then-park approach, is premature.

However, I seem to be in the rough on that so can live with
this ad-hoc process (teeth grinding mind you:-) so long as we
park this for a sufficient period *and* are open to changing
anything at the end of the parking-lot period.

Even so, I think this is not yet ready for any such ad-hoc
parking-lot:

- section 1.5 implies a wish to reduce the number of
octets sent - ECH creates a way to point from one part
of the (encrypted, inner) ClientHello to another (the
outer ClientHello). I don't think we want two such
mechanisms, or one mechanism defined in ECH but none at
all here, or even worse a second method. For me, that
implies not "freezing" the structural work here 'till
we see if ECH gets widespread deployment at which point
we should consider re-use of the ECH mechanism. (Or maybe
even consider both cases of re-using octets and invent
another thing, but not 'till we see if ECH gets traction.)

- section 2: if "classic" DH were broken, and we then
depend on a PQ-KEM, doesn't that re-introduce all the
problems seen with duplicating RSA private keys in
middleboxes? If not, why not? If so, I don't recall
that discussion in the WG (and we had many mega-threads
on RSA as abused by MITM folks so there has to be stuff
to be said;-)

- similar to the above: if PQ KEM public values are
like RSA public keys, how does the client know what
value to use in the initial, basic 1-RTT ClientHello?
(sorry if that's a dim question:-) If the answer is
to use something like a ticket (for a 2nd connection)
then that should be defined here I'd say, if it were
to use yet another SVCB field that also ought be
defined (or at least hinted at:-)

- I'm also HRR-confused - if we don't yet know the
details of the range of possible PQ KEM algs we want to
allow here, how do we know that we almost always continue
to avoid HRR in practice and thus benefit from a mixture of
classic and PQ algs? (It's also a bit odd that HRR,
much as I dislike it, doesn't get a mention here;-) I
think the problem is that we don't want HRR to push a
client back to only "classic" groups, if the client but
not the server is worried about PQ stuff while both
prioritise interop.

- section 4: if this cannot support all NIST finalists
due to length limits then we're again being premature
esp. if NIST are supposed to be picking winners soon.
We'd look pretty dim if we didn't support a NIST winner
for this without saying why.

- section 5: IMO all combined values here need to have
recommended == "N" in IANA registries for a while and
that needs to be in this draft before it even gets
parked. Regardless of whether or not the WG agree with
me on that, I think the current text is missing stuff
in this section and don't recall the WG discussing that

Nits etc below:

- TLS1.1 and earlier mixed hash functions when deriving
keys on the basis of then-suspected weaknesses in MD5, yet
there were arguments made that that ad-hoc mixing wasn't
useful, so we moved away from that in TLS1.2+. I don't
see an argument or pointer in this draft to a justification
that this (also seemingly ad-hoc?) catenation approach
won't suffer analagous infelicity. Absent that, ISTM trying
to finalise the structural parts of this now may be a
cryptographically bad plan. (Even if in practice that's ok.)

- 1.2: it's longer 2019 - one of the year or tense (of
"include") should change, probably the former given the
idea of parking this for some time

- section 2: the tendency to document APIs (e.g. "KeyGen()")
in protocol documents seems to me a bit of a double-edged
sword - it should help some implementers but OTOH might
mean we fail to consider how implementations with other
internals might perform, so I'd prefer we are more clear
as to how those APIs are optional, but that's really a
matter of style I guess

- section 2: HPKE is now RFC9180

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] draft-farrell-tls-pemesni-02 status

2022-03-17 Thread Stephen Farrell



Hiya,

On 17/03/2022 20:57, Joseph Salowey wrote:

While we are all supportive of ECH, we are not sure that the PEM file
format for ECH I-D (draft-farrell-tls-pemesni-02) is within scope of the
TLS WG. 


Hmm. Gotta say I don't agree as a commonly supported
format like this (should this garner support) helps
enable TlS server deployments switch between server
implementations, but if that's the call...


The WG has not always but mostly recently stuck to adopting I-Ds
that relate to the TLS wire format. SECDISPATCH or UTA or even DNSOP might
be a better place for this work.


Can't see dnsop being relevant tbh.

I'm fine though with it being formalised however works.
Maybe this one's better just sent to the ISE? (I'll do
that during/after the meeting next week unless there's
feedback that something else is better.)

Cheers,
S.



Joe and Sean


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


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

[TLS] .well-known URL for ECH

2021-11-30 Thread Stephen Farrell



Hiya,

As discussed at IETF-112, I've done the ESNI -> ECH
substitutions for this draft. [1] I've implemented
this for some of my test servers so it "works" for
a micro-scale setup like mine, but of course if
something like this is useful for others, I'd be
happy to change it to suit.

Happy to take comments, and/or for the chairs to
decide to ask about adoption when/if they think
that useful.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-farrell-tls-wkesni/


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

[TLS] ECH: fuzzy DNS data

2021-11-28 Thread Stephen Farrell



Hiya,

Recently I've been doing a bit of testing of the effects
of retrieving dodgy or possibly unexpected ECH-related
data from DNS. I've setup a repo with a few of those and
am publishing 'em in DNS (one randomly selected every 30
minutes). That's explained at [1]. It might be useful for
others testing ECH clients. If anyone has any other bad
values to suggest, I'd be happy to add 'em to [1] (either
a PR or email would be fine).

Cheers,
S.

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


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

[TLS] updated PEM file format draft for ECH key pairs

2021-11-19 Thread Stephen Farrell



Hiya,

As discussed at IETF112, I've updated the PEM file format
draft for ECH. [1] Happy to take comments via mail or via
that github thing:-)

As and when the chairs think it's a good time to consider
adoption, or incorporation into the ECH draft, or sending
this somewhere else, I guess we can have that discussion.

This format is supported by my OpenSSL fork [2] which has
CLI tooling for making/consuming these and can be ingested
by the various TLS servers (lighttpd, apache, nginx and
haproxy) with which I've integrated that ECH-enabled build.
(There're pointers to forks for those servers at [3].)

I'll work on the well known url draft in the next while.
It likely needs a bit more work than simple substitution.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-farrell-tls-pemesni/
[2] https://github.com/sftcd/openssl/tree/ECH-draft-13a
[3] https://defo.ie/


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH - handling retry config with different public name?

2021-11-06 Thread Stephen Farrell



Hiya,

On 06/11/2021 22:20, Martin Thomson wrote:

I assume that you might add "just once" there.  Or at least a limited
number of times.  


Right. I think that's in the spec already.

Cheers,
S.


Infinite regress seems like something worth
avoiding.  outer1 -> outer2 -> outer1 is likely not a great outcome.

On Sat, Nov 6, 2021, at 02:20, David Benjamin wrote:

That's my inclination as well. It's an odd thing for a server to
do, but it seems fine to just retry with the new config without
much fuss?

On Fri, Nov 5, 2021 at 10:18 AM Stephen Farrell 
 wrote:


Hiya,

Bit of a corner case I'm not sure about. Apologies if this has
come up before.

The scenario:

- inner SNI is inner.example - ECHConfig from inner.example's DNS
has outer.example as public_name - client authenticates with
ClientHelloOuter and the ServerHello contains retry_configs with
one ECHConfig that has a public_name of another.example - client
decides to retry and a similar thing happens (authenticates with
ClientHelloOuter) but this time with public_name of
yetanother.example - rinse/repeat until the client is fed up with
retries or manages to authenticate using ClientHelloInner if ECH
eventually works

My question is: should the client care about those changes in
public_name or not? I think the answer is "not" but wanted to
check.

Ta, S.




___ 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




OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

[TLS] ECH - handling retry config with different public name?

2021-11-05 Thread Stephen Farrell



Hiya,

Bit of a corner case I'm not sure about. Apologies
if this has come up before.

The scenario:

- inner SNI is inner.example
- ECHConfig from inner.example's DNS has outer.example
  as public_name
- client authenticates with ClientHelloOuter and the
  ServerHello contains retry_configs with one ECHConfig
  that has a public_name of another.example
- client decides to retry and a similar thing happens
  (authenticates with ClientHelloOuter) but this time
  with public_name of yetanother.example
- rinse/repeat until the client is fed up with retries
  or manages to authenticate using ClientHelloInner if
  ECH eventually works

My question is: should the client care about those
changes in public_name or not? I think the answer is
"not" but wanted to check.

Ta,
S.






OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] NIST on addressing visibility challenges with TLS 1.3

2021-09-30 Thread Stephen Farrell



(I've no problem if the chairs want to shut this down as
we have gone over this ground a number of times - OTOH it
is I think important to not let such things pass by as if
they were fine, since they are not fine.)

Ruslan is correct wrt the EU stuff IMO.

Other than that, I don't consider it inappropriate to
criticise organisations that act as NIST are doing here.
Claims that that's tonally dodgy are IMO off the mark.

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] NIST on addressing visibility challenges with TLS 1.3

2021-09-28 Thread Stephen Farrell

Hiya,

On 28/09/2021 17:53, Salz, Rich wrote:

This will be of interest to some on this list. Quoting: “The NCCoE
at NIST recognizes the challenges associated with compliance,
operations, and security when enterprises employ encrypted protocols,
in particular Transport Layer Security (TLS) 1.3, in their data
centers. This project will use commercially available technologies to
demonstrate a range of approaches for enabling necessary
intra-enterprise access to unencrypted/decrypted information.

I'm glad I'm not a tax payer in a jurisdiction that's
encouraging people to weaken the security properties this
WG has tried hard to improve. I wonder do other parts of
NIST sponsor work like that - it'd be a bit like [1]
producing specs on how to get your thumb on the scales;-)

From my perspective this kind of thing also makes it harder
to figure out what overall evaluation to associate with the
agency that produced AES, dual-ec, this stuff, and presumably
some PQ alg "winners" in the near future. Quite the mixed
bag that.

Cheers,
S.

[1] https://www.nist.gov/pml/weights-and-measures

More at
https://www.nccoe.nist.gov/projects/building-blocks/applied-cryptography/addressing-visibility-challenges-tls-13
including how to participate.

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

OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key

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

[TLS] ECH draft-13 servers for interop testing

2021-09-14 Thread Stephen Farrell



Hiya,

I've put up a bunch of server instances for ECH draft-13
interop as described below and at [1].

- OpenSSL s_server: draft-13.esni.defo.ie:8413 using all algs
- OpenSSL s_server: draft-13.esni.defo.ie:8414 likely forces
HRR as it only likes P-384 for TLS  
- lighttpd: draft-13.esni.defo.ie:9413
- nginx: draft-13.esni.defo.ie:10413
- apache: draft-13.esni.defo.ie:11413
- haproxy: draft-13.esni.defo.ie:12413 shared mode
   (haproxy terminates TLS)
- haproxy: draft-13.esni.defo.ie:12414 split mode
   (haproxy only decrypts ECH)

Those all use the latest branch of my OpenSSL fork [2]. There
are links to the server source for each at [1]. Each of the
above have keys (well, the same key:-) published in DNS.

I also think my (of course still radically imperfect:-) code
interops with boringssl and the test server Cloudflare have
put up. I've still to try get HRR working in split mode but
will be working on that shortly, other than that though, the
spec seems implementable, if complex for my wee brain:-)

Those aren't setup to be resilient as I'd like to see some
detail if they crash, so in that case, or if stuff just
doesn't work, mail me and we can figure a way to test stuff.

Cheers,
S.

[1] https://defo.ie/
[2] https://github.com/sftcd/openssl/tree/ECH-draft-13a


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH AAD for HRR

2021-09-01 Thread Stephen Farrell



Earlier, I said:

On 01/09/2021 18:00, Stephen Farrell wrote:

I should have a server up in a few days


I now have an ``openssl s_server`` that thinks it speaks
draft-13 running on draft-13.esni.defo.ie on port 8413
with the relevant ECHConfig published in DNS etc.

It'll probably crash and burn if someone tries to talk
to it, but happy to see that happen:-)

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH AAD for HRR

2021-09-01 Thread Stephen Farrell



Great, thanks both

S

On 01/09/2021 19:04, Christopher Patton wrote:

Yup, that was my interpretation as well.

On Wed, Sep 1, 2021 at 10:14 AM David Benjamin 
wrote:


That's right. The AAD and actual CH should be exactly the same, apart from
the payload being zeroed in place. You don't need to reserialize the
structure as a server, or serialize ClientHelloOuter twice as a client.

On Wed, Sep 1, 2021 at 1:01 PM Stephen Farrell 
wrote:



(Apologies for the acronym laden subject:-)

I'm more or less at the "code complete" stage of
implementing draft-13 incl. HRR. (If anyone wants
to try interop, for now please contact me, but I
should have a server up in a few days.) I'm sure
as usual I'll have gotten some details wrong, but
I wasn't clear about one thing:

- When sending the 2nd CH following HRR, the spec
calls for omitting the "enc" field of the ECH
extension ("enc" holds the sender's public HPKE
value that's re-used from the 1st CH).
- The AAD for that ECH encryption is the outer
CH with zeros replacing where the ciphertext will
go.
- I concluded that the sender's ECH public value
(the "enc" field) ought not be present in the
AAD in that case, as well as being omitted in
the ECH value, but it wasn't entirely clear to me
from the spec (and it'd work either way).

So my question is: did I get that right or not?

Thanks in advance,
S.

___
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





OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

[TLS] ECH AAD for HRR

2021-09-01 Thread Stephen Farrell



(Apologies for the acronym laden subject:-)

I'm more or less at the "code complete" stage of
implementing draft-13 incl. HRR. (If anyone wants
to try interop, for now please contact me, but I
should have a server up in a few days.) I'm sure
as usual I'll have gotten some details wrong, but
I wasn't clear about one thing:

- When sending the 2nd CH following HRR, the spec
calls for omitting the "enc" field of the ECH
extension ("enc" holds the sender's public HPKE
value that's re-used from the 1st CH).
- The AAD for that ECH encryption is the outer
CH with zeros replacing where the ciphertext will
go.
- I concluded that the sender's ECH public value
(the "enc" field) ought not be present in the
AAD in that case, as well as being omitted in
the ECH value, but it wasn't entirely clear to me
from the spec (and it'd work either way).

So my question is: did I get that right or not?

Thanks in advance,
S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] GREASE ECH repeated value after HRR

2021-08-17 Thread Stephen Farrell



Thanks David.
Cheers,
S.

On 17/08/2021 21:15, David Benjamin wrote:

It's because of the rules in RFC8446. If the server doesn't utter an
extension in HelloRetryRequest, the client is not allowed to change the
corresponding ClientHello extension. We found an implementation which
actually enforces this.
https://github.com/tlswg/draft-ietf-tls-esni/issues/358

David

On Tue, Aug 17, 2021 at 4:03 PM Stephen Farrell 
wrote:



Hiya,

(I'm just getting around to playing with draft-13 ECH and
HRR and have a question...)

In 6.2 talking about GREASEd ECH, the draft says:

 If sending a second ClientHello in response to a
 HelloRetryRequest, the client copies the entire
 "encrypted_client_hello" extension from the first
 ClientHello.  The identical value will reveal to an
 observer that the value of "encrypted_client_hello" was
 fake, but this only occurs if there is a
 HelloRetryRequest.

I don't object to that, but can't recall why we wanted
the same value re-tx'd. (My code just naturally generated
a new GREASE ECH value and it all worked fine, so being
the lazy person I am, I'm wondering if doing nothing is
a good option:-)

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





OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

[TLS] GREASE ECH repeated value after HRR

2021-08-17 Thread Stephen Farrell



Hiya,

(I'm just getting around to playing with draft-13 ECH and
HRR and have a question...)

In 6.2 talking about GREASEd ECH, the draft says:

   If sending a second ClientHello in response to a
   HelloRetryRequest, the client copies the entire
   "encrypted_client_hello" extension from the first
   ClientHello.  The identical value will reveal to an
   observer that the value of "encrypted_client_hello" was
   fake, but this only occurs if there is a
   HelloRetryRequest.

I don't object to that, but can't recall why we wanted
the same value re-tx'd. (My code just naturally generated
a new GREASE ECH value and it all worked fine, so being
the lazy person I am, I'm wondering if doing nothing is
a good option:-)

Ta,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] esni-draft-13 suggestion

2021-08-09 Thread Stephen Farrell



Hiya,

On 09/08/2021 19:07, Christopher Wood wrote:

On Thu, Aug 5, 2021, at 10:30 AM, Salz, Rich wrote:
As you are an experienced reviewer, I really appreciate all your 
commentary, and I think an experienced, not-author, view is very

useful!


+1 -- thanks, Stephen! Most of the PRs have been reviewed and merged.
There's a couple lingering PRs that we may want to close or punt. 


I just closed one and punted one, leaving none:-)

Thanks,
S.


I'd
prefer we resolve them in the next day or two, update the change log,
and get the next version out. Of course, if folks are still reviewing
and want or need more time, please let me know!

Best, Chris



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] esni-draft-13 suggestion

2021-08-05 Thread Stephen Farrell



Hiya,

So I gave that a read through and created a pile of
PRs. [1] I didn't go over the appendices.

As I said, I'm fine if those are ignored - better to
get -13 out than spend ages discussing. (I'm fine with
chatting about 'em too for a bit of course.)

Cheers,
S.

[1] https://github.com/tlswg/draft-ietf-tls-esni/pulls

On 03/08/2021 21:58, Christopher Wood wrote:

On Tue, Aug 3, 2021, at 1:51 PM, Stephen Farrell wrote:



On 03/08/2021 21:44, Christopher Wood wrote:

Of course! We're happy to park the next version until the end of the
week (or longer), if that would yield more reviews. Please send any
editorial comments you have here on the list or as PRs against the
draft, and we'll work to try and incorporate them.


Great. I shouldn't need that long. I'll plan to do this
tomorrow (Wed). If it'd be better to wait 'till some
more PRs are merged that's fine just tell me when to
start.


Sounds good! Feel free to start at your earliest convenience. As of now, we 
weren't planning any more editorial changes for -13.

Best,
Chris



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] esni-draft-13 suggestion

2021-08-03 Thread Stephen Farrell




On 03/08/2021 21:44, Christopher Wood wrote:

Of course! We're happy to park the next version until the end of the
week (or longer), if that would yield more reviews. Please send any
editorial comments you have here on the list or as PRs against the
draft, and we'll work to try and incorporate them.


Great. I shouldn't need that long. I'll plan to do this
tomorrow (Wed). If it'd be better to wait 'till some
more PRs are merged that's fine just tell me when to
start.

Cheers,
S.





OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

[TLS] esni-draft-13 suggestion

2021-08-03 Thread Stephen Farrell



Hiya,

I see a bunch of activity in github that may be the precursor
to pushing out draft-13, which would be great.

One (ignorable) suggestion - as we're aiming for this draft
to be the basis for ongoing experiments, just before pushing
the publish button, it might be no harm to give people a day
or so to review the github version, on the understanding that
the editors will only accept  non-controversial editorial PRs
submitted over that short period. (And other comments/PRs
will not be accepted for -13.)

If given a day to do that, I'd prioritise it.

That said, this'd put more work on the editors, and maybe
they don't have time right now, and things can be fixed
later anyway, so it's very much ok to not do this.

(I'm suggesting this as it's been ages since I read the
whole thing through so if a few people in my situation
did a read-through we might catch stuff that'd save work
as we experiment.)

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

2021-07-19 Thread Stephen Farrell



Hiya,

On 19/07/2021 22:43, David Benjamin wrote:

No. I'm saying there is a need for text around resumption and privacy,
whether or not we publish this draft. There is a copy of the text to
address it in both documents. The text applies equally well to both, thus I
am satisfied with how this draft addresses the concerns.


Ack.



It sounds like you disagree with this reasoning because you are unhappy
with that text. 


I've not considered the text in 8446bis.

I'm against this draft entirely, as it adds to our problems
(IMO, but not yours).


Thus: what do you think are the privacy rules for TLS
resumption? An alternate suggestion of "don't publish the draft" does not
work, because having resumption in form means we need to consider this.


Of course that suggestion "works." It'd mean that this new
potential tracking vector doesn't turn into an actual one.

(We may still likely need more text in 8446bis about
resumption but that's different - were it precisely same
there'd be no need for this draft at all.)

Cheers,
S.




OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

2021-07-19 Thread Stephen Farrell



Hiya,

On 19/07/2021 22:13, David Benjamin wrote:

I don't think that's an accurate characterization of what's going on. I at
least care about both optimization and privacy. 


Sure. We just disagree, I've no doubt you care about those.


We should apply
optimizations only where they do not result in a privacy issue, and we
should not apply optimizations that result in a privacy issue. That means
taking the time to understand a system's privacy goals and how mechanisms
interact with them.

Even ignoring this document, rfc8446*already*  fails this test. By
omission, it implies applications needn't match up their privacy goals with
TLS resumption. This is false and indeed that results in a tracking vector
on the Web, and any other application where multiple contexts talk to the
same domain. That means this 3rd option does not replace the need for text.
We need to either find wording we're happy with, or remove resumption
entirely.

I've proposed some text for rfc8446bis. I think it captures the right
criteria: you may only resume if you were okay correlating the first and
second connections. If you think something is missing, I think that is
useful feedback. Given how widespread resumption is, it's important that we
fully understand the implications.
https://github.com/tlswg/tls13-spec/pull/1205


From there, we can look at this document.


Now it's me that's confused. Are you arguing that this draft
ought not progress until 8446bis is done?

Ta,
S.


Observe that the rule applies
equally well here. Moreover, on the Web, even after you apply the rule,
there is still a space where the optimization is useful. This is great. It
means we can both avoid a privacy issue*and*  make things faster. Even
better, the optimizations apply to XSS privsep schemes (subdomains within a
site), so there is an indirect security benefit. Other applications may
look different (no subresource-like construct, different correlation
boundaries), such that the optimization is not useful, but that's still
fine. The overall rule simply turns the flag into a no-op.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

2021-07-19 Thread Stephen Farrell



Hiya,

On 19/07/2021 17:50, David Benjamin wrote:

Do you have other text in mind? There doesn't seem to be any other possible
answer here, since there is only one decision to make in resumption.


There is a 3rd option: don't standardise the flag. That'd be
my preference, but as I said maybe I'm in the rough in not
preferring more optimisation at the cost of the additional
privacy concern.

Other than that I don't have better wording to offer at the
moment that I think would really help sorry. Maybe if others
chime in something'll become more apparent.

Cheers,
S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

2021-07-19 Thread Stephen Farrell



Hiya,

On 19/07/2021 17:35, David Benjamin wrote:

We need to*both*  not add new tracking vectors*and*  mitigate the existing
ones. Doing either one on its own is not useful. That means if the existing
mitigation for the existing vector applies just as well to this new
feature, we have not added a new vector.


I think that clarifies where we disagree, thanks - i'm
not convinced that our existing mitigations for tracking
via the web, or otherwise, are anywhere near sufficient.

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

2021-07-19 Thread Stephen Farrell



Hiya,

On 19/07/2021 17:17, David Benjamin wrote:

I'll add that, in the context of cross-domain tracking on the web, this
draft is a red herring. Remember that web pages have subresources. That
means looking at the destination domain isn't useful because two different
pages can embed a common destination domain. So the same concerns exist
with RFC8446 (TLS resumption), RFC7540 (connection-reuse, same- and
cross-domain), and RFC7230 (connection reuse). That's why we need a
holistic answer like network partition keys from [FETCH], that apply to
*all*  network state. That answer applies equally to plain resumption and
this draft.


That's true but isn't that also the old "adding this
one new way to track doesn't make it worse because it's
already horrible"?

My preference is to not add new mechanisms that can
enable cross-domain tracking as this one does.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

2021-07-19 Thread Stephen Farrell



Hiya,

On 19/07/2021 16:21, Ryan Sleevi wrote:

On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell 
wrote:


I don't find the reference to [FETCH] explains how that
problem can be mitigated by browsers. (IIRC, adding that
was the result of earlier discussion of this point?)



I'm not sure I'm parsing this correctly.

Are you saying that you don't believe network isolation keys are
sufficient? 


I'm saying I don't know. I'm not a browser implementer.
Nor are a bunch of other people who use TLS and who won't
be familiar with fetch.


That is, this is the current language from the draft:


For example, the Web use case uses network partition keys to separate

cache lookups [FETCH].

And the term there ("network partition keys") is a defined term in the
FETCH spec that forms the basis of cross-domain tracking prevention:
https://fetch.spec.whatwg.org/#network-partition-key

It's unclear whether you're saying that the spec should diverge from FETCH
and impose additional requirements, or whether you're saying you don't
believe the current FETCH spec is robust enough there.


The spec doesn't say how to mitigate the problem for any
other application using TLS, nor does it explain how to
mitigate the issue for a browser, other than via that one
sentence referring to a document that can change (though
that last isn't my problem with this spec).

I don't myself know how well that mechanism mitigates the
issue for browser users, nor how feasible it might be to do
something similar in a non-browser. (If the mechanism works
ok for browsers, that's fine for them of course.)


It's unclear that there's any benefit to having the Cross-SNI spec impose
additional requirements: you have to consider the Web application in its
entire context, which is precisely what network partition keys do.
Similarly, if the concern is that FETCH isn't sufficient for your concerns,
is that a concern with this spec, or with FETCH, and can/should they be
articulated there (and the related issue mentioned)




I think both of those are indicators that this mechanism
could be used at scale for tracking.



You opened by talking about MTAs,


It's very common to see web servers and MTAs on the same IP
address, and also common to see the same certificate used
for both. (My scans were of hosts listening on mail ports
but I also scanned 443.)


but it's unclear if this is meant to be a
general statement or specific to mail. 


The scale issue is general I think. I agree that trackers
today overwhelmingly enjoy the web as their preferred tool.

But again, my fundamental issue with this is that we ought
not be added new cross-domain tracking threats.

S.


In the context of the Web, then we
have to consider the holistic platform, and ask whether this hooks into the
same appropriate points - it does, as the partition keys are based on the
same cross-origin tracking protection mechanisms (e.g. the determination of
"first party" vs "third party" contexts is implicitly handled here). If
this is for mail, then isn't the point that this remains an
application-/protocol-specific consideration?



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

2021-07-19 Thread Stephen Farrell




On 19/07/2021 15:16, Salz, Rich wrote:

I support publication.


I don't, though I may be in the rough.

We did discuss this a bit earlier but from my POV this
adds a new vector for cross-domain tracking and we ought
be removing those, not adding them.

I don't find the reference to [FETCH] explains how that
problem can be mitigated by browsers. (IIRC, adding that
was the result of earlier discussion of this point?)

I have no idea if anything similar might protect mail user
agents when processing mailbug URLs, not other applications
using TLS.

To give a small sense of scale, in scans I did a few
years back [1], one wild-card certificate [2] was visible
at almost 2000 addresses in a range of different countries.
That appeared to be part of some multi-product marketing
campaign. (The names seen associated with the wildcard cert
were of the form ".campaign."
and the wildcard was for "*.campaign.".)
Another certificate (sorry had a quick look but didn't find
the specific ref) for parked domains had 1500 SANs.
I think both of those are indicators that this mechanism
could be used at scale for tracking.

Cheers,
S.

[1] https://eprint.iacr.org/2018/299
[2] https://crt.sh/?id=242683192




https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/
  


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



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH and resumption - what to put in SNI?

2021-06-25 Thread Stephen Farrell



So I guess we're landing on "if the client got a ticket via
a session that successfully used ECH, it MUST send a fresh
ECH when using that ticket"? That's ok I guess, but maybe
some more detail is needed...

On 25/06/2021 17:01, David Benjamin wrote:

1. Either this layer knows how to set up TLS, but doesn't know how to
establish connections. Low-level TLS APIs look like this. This layer must
take both the transport connection and ECHConfigList as an external
parameter. Resumption works orthogonally: the layers above run through the
same connection establishment procedure independent of resumption, so you
won't have any more stale of ECHConfigList for resumption as full
handshake. If this layer doesn't know how to establish connections for full
handshakes, it doesn't know how to do it for resumption handshakes either.

2. Or this layer knows how to establish a connection*and*  set up TLS.
Maybe this is a higher-level TLS API. Maybe this is the
MakeHTTPSConnection() portion of your HTTP stack. In this case, the layer
is responsible for DNS lookup, evaluating HTTPS/SVCB queries, and using the
ECHConfigList. Resumption is equally orthogonal: whenever you make a
connection, you do the DNS lookup, possibly using a cached record. Then you
check your session cache. Use ECH if you have an ECHConfigList. Offer
resumption if you have a session. Do both if you have both.

In both cases, resumption doesn't affect ECHConfigList availability.


I'm not sure yet that OpenSSL matches either 1 or 2, (I've
only done some basic tests) but in any case it seems like
the client could have a ticket cached but get an entirely
different SVCB RR with a different public_name the 2nd time
so I'm not sure that things work well in all cases.

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

[TLS] ECH and resumption - what to put in SNI?

2021-06-25 Thread Stephen Farrell



Hiya,

If a client established a session to foo.example.com
using ECH with a public_name of example.com, what ought
the client put in the SNI when resuming?

Ignoring ECH, 8446 seems to imply one ought put in
foo.example.com [1] but that'd defeat the purpose of
ECH.

If one omits SNI, that would likely be hard to handle
for a client-facing server when it tries to route
to a good split-mode backend. The same could be true
even if example.com is included as the SNI.

I guess the client could do ECH again, but that'd also
be odd, as it'd require asymmetric crypto when resuming
(which I guess is a lot of the point of tickets), and
depending on ticket ages vs. ECHConfig key rotation
times, might cause interesting failures for a library
client that can't do fresh DNS queries from within the
library (and might never see the TTL of the HTTPS/SVCB
RR in any case).

Am I missing something obvious? If not, what's best here?
(And we should probably have some text in the draft on
this too.)

Cheers,
S.

PS: I guess if the inner and outer ALPNs differed in
the original CH, similar issues might arise for a
client-facing server, in terms of figuring out the
right backend to which the resumed session should be
routed, if routing were based on e.g. the inner ALPN.




[1] https://datatracker.ietf.org/doc/html/rfc8446#page-57


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] Editorial: chronological order in ECH draft

2021-06-23 Thread Stephen Farrell




On 24/06/2021 00:37, Martin Thomson wrote:

Whatever you can do to improve the readability of this document would
be greatly appreciated. 


+1 though I have to admit I've really been mostly looking
at diffs at this stage - probably some new readers/coders
are needed,

S.


It's a complicated design and I always spend
far too much time trying to find answers to my questions.  A better
structure would be appreciated.

I do find that questions aren't always about behaviour.  They are
also about protocol elements, and those a scattered piecemeal
throughout.  So I would be disappointed if any restructuring were
limited to just getting the time sequence straightened out.

On Thu, Jun 24, 2021, at 09:04, Carrick Bartle wrote:

Hi all,

I'm bringing
https://github.com/tlswg/draft-ietf-tls-esni/issues/412 to the list
since it looks like we're (hopefully) getting close to the end game
with ECH.

The ECH draft is currently organized such that it describes all
client behavior and then all server behavior. Personally, I find
this very confusing to follow, and I'm constantly having to flip
back and forth between sections (which themselves constantly refer
to each other). Does anyone object to my rearranging the content to
be in more of the order in which things occur rather than being
divided into client and server sections? Of course, depending on
how I do it, it could end up being *more* confusing, but I just
wanted to see if people were opposed to it in principle.

Carrick ___ 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




OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH Padding

2021-06-22 Thread Stephen Farrell




On 22/06/2021 22:57, Christopher Patton wrote:

Just to be clear, (1), (2) and (3) are not alternatives to the same
problem. (1) solves client-side padding, whereas (2) and (3) are
alternatives for solving server-side padding.


Apologies. (Though I put part of the blame on excessive
githubbery leading to a lack of clarity and ambiguity, as
is my habit:-)

I can live with (1) and (2) but only see any need to change
because of the QUIC argument(s) - absent those we can work
around things and get ECH out the door IMO.

(3) is a mistake - a new handshake message shouldn't be
adopted until after that's been tested and shown not to
be problematic and I bet it would be problematic as well
as lots more work

S.






OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] ECH Padding

2021-06-22 Thread Stephen Farrell



(1) aka #443 is the way to go here I think. (Such an aptly
numbered PR has to be accepted I'd say:-) I'm only convinced
of that because of QUIC, but that seems like enough or a
rationale.

I'm against (3) - it'd break too much and cost too much.

WRT (2) I'd prefer to drop that extensibility rather than
try use it because it's there.

Cheers,
S.

On 22/06/2021 22:27, Christopher Patton wrote:

Hi all,

One of the last design questions for Encrypted ClientHello (ECH) is to
decide how to pad encrypted handshake messages so that their length does
not leak privacy-sensitive handshake-parameters. The current approach is to
insert padding into the record layer as needed. However, the consensus
reached in [1] is that computing record-layer padding based on the contents
of handshake messages entails implementation complexity that is untenable,
particularly for QUIC and DTLS. The alternative that most folks are happy
with is to insert padding into the handshake messages themselves, as this
prevents details of the handshake logic from bleeding into the record layer
code.

There are a few PRs for adding handshake-level padding that we could use
feedback on.

 (1) https://github.com/tlswg/draft-ietf-tls-esni/pull/443 Adds padding
to EncodedClientHelloInner, the message that is encrypted and stuck into
the ECH extension of the ClientHelloOuter. This prevents leakage of
sensitive parameters in ClientHelloInner.

 (2) https://github.com/tlswg/draft-ietf-tls-esni/pull/313 Defines a new
extension, which the client sends in ClientHelloInner in order to solicit a
response in the backend server's EncryptedExtensions message. The server''s
response contains padding it can use to prevent leakage of sensitive
parameters in its first flight of handshake messages.

 (3) https://github.com/tlswg/draft-ietf-tls-esni/pull/457 (alternative
to (2)) Defines a new handshake message, Padding, which the client and
backend server always send just before Finished in case of ECH acceptance.
One advantage of this approach over (2) is that the length of the padding
can be evaluated after the Certificate/CertificateVerify messages have been
chosen, making it possible to account for sensitive parameters in these
messages without needing to buffer the whole flight of messages. The
downside is that it may add complexity to the state machine of TLS 1.3
implementations.

There are some open questions regarding how to compute the padding length,
but these should be orthogonal to deciding the mechanism.

Thanks on behalf of (some of) the contributors,

Chris P.

[1] "Handshake-level vs record-level padding."
https://github.com/tlswg/draft-ietf-tls-esni/issues/264


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



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] Use-case for non-AEAD ciphers in network monitoring

2021-05-17 Thread Stephen Farrell



Hiya,

On 17/05/2021 21:33, Darin Pettis wrote:

TLS 1.3 did a great job regarding safety of data on the Internet. For the
next version, let’s focus on how to best meet this used case


I think we had this discussion a few years ago. There is
no sensible boundary at which TLS can apply different
cryptographic treatment.

There were also many many other points raised at that
time that I don't think we'll benefit from repeating.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


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

Re: [TLS] [Uta] Recommending ALPN (was Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11 ...)

2021-04-30 Thread Stephen Farrell



Hiya,

I like the text below as a starter. I'd suggest it also
include something to take into account the ECH issue
mentioned on the dpriv list [1]

S

[1] 
https://mailarchive.ietf.org/arch/msg/dns-privacy/3xL59_1P0ZHOUEYsDJ1Q22ZZVvo/


On 30/04/2021 07:46, Martin Thomson wrote:

On Fri, Apr 30, 2021, at 16:25, Valery Smyslov wrote:

The original motivation for 7525bis was to update RFC 7525 in light
of TLS 1.3 appearance. However, I believe that recommendations for
using ALPN are in scope of this document.


How about a new Section 3.7 "Application-Layer Protocol
Negotiation":

--- TLS implementations MUST support the Application-Layer Protocol
Negotiation (ALPN) extension [RFC7301].  Correct use of ALPN ensures
that clients and servers agree on a negotiated protocol.

Newly defined application protocols that use TLS MUST define an ALPN
identifier and mandate the use of ALPN for negotiating the protocol.

An existing application protocol might not have been assigned an ALPN
identifier.  For other protocols the ALPN identifier might not have
been part of the original protocol definition, or use of ALPN might
have been defined originally as being optional.  In all of these
cases, implementations cannot require the use of ALPN.  A server
implementation MUST fail a connection attempt with a fatal
"no_application_protocol" alert if it is configured to use a protocol
that has no assigned ALPN identifier and a client offers an
"application_layer_protocol_negotiation" extension. ---

This last bit might be an update to RFC 7301, but it's important for
protecting against cross-protocol attacks on clients that support
protocols with ALPN identifiers where the use of ALPN is not
guaranteed.

___ Uta mailing list 
u...@ietf.org https://www.ietf.org/mailman/listinfo/uta




OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

2021-04-29 Thread Stephen Farrell




On 29/04/2021 19:28, Salz, Rich wrote:

To make it obvious (I thought it was): I agree, and think we need to
make that fact more widely known.


I think I agree but seems like ECH may add a subtlety - maybe
what we need to promote is the idea that new protocols should
define new ALPN strings, but also that intermediaries can't
depend on those to route connections as the inner and outer
ALPN values can be independent in the case of ECH (use of
which might not that visible to the application if a library
were to default to use of ECH where possible).

Cheers,
S.



From: Eric Rescorla  Date: Thursday, April 29, 2021 at
2:24 PM To: Rich Salz  Cc: Martin Thomson
, "dns-priv...@ietf.org" ,
"tls@ietf.org"  Subject: Re: [dns-privacy] [TLS] Martin
Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with
COMMENT)

Probably not, but I agree with MT.

The general idea here is that any given protocol trace should only be
interpretable in one way. So, either you need the interior protocol
to be self-describing or you need to separate the domains with ALPN.
I don't believe that either the IP ACL or mTLS addresses this issue,
and in fact arguably mTLS makes the problem worse because it provides
authenticated protocol traces which might be usable for
cross-protocol attacks.

-Ekr


On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich
mailto:40akamai@dmarc.ietf.org>>
wrote:

No new protocol should use TLS without ALPN.  It only opens space
for cross-protocol attacks.  Did the working group consider this
possibility in their discussions?


I don't believe that message has been made as public as it should
be.

___ dns-privacy mailing
list dns-priv...@ietf.org 
https://www.ietf.org/mailman/listinfo/dns-privacy




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




OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

2021-04-20 Thread Stephen Farrell



Hiya,

To answer Chris' initial question: I can't currently think of
a real use-case where the client would need to authenticate
an IP address for a client-facing server in the event that
ECH decryption has been tried and failed.

And, I very much sympathise with Martin's goal of simplifying
if we can. (E.g. leave the public_name as-is and as we've got
implemented, but drop the extensions field entirely - I don't
think there's a shortage of code points for new extensions if
the first ECH one doesn't quite do what's needed.)

But I'm likely not the right person to ask - I'd guess that
the people who might have a use-case for this are smaller
hosters where the default listener on 443 is very minimal. I
don't know how common those are, but I'd suspect they are
fairly rare. And likely those with certs that have the
exactly right IP address are even rarer.

On 21/04/2021 02:48, Carrick Bartle wrote:

I'm not sure what you are implying might be impossible.  Are you
suggesting that it might be impossible to get a name for which you
could get a certificate?

No. I'm implying that if we don't allow clients to authenticate
client-facing servers with an IP-based certificate, ECH won't be
possible in cases where the client-facing server doesn't have a
name.


In general, I'd prefer we get ECH deployed for some major use
cases and not try fill in every possible niche at this point.
ISTM the overall win here is that we end up with ECH working
in many cases, but don't need all cases. And there's a danger
that we get zero cases if we make it too complex.

Cheers,
S.







OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] ECH-10 interop test server

2021-04-07 Thread Stephen Farrell



Hiya,

On 05/04/2021 18:07, Stephen Farrell wrote:


Hiya,

On 05/04/2021 18:01, Christopher Patton wrote:

Hi list, just FYI that Cloudflare's test server is upgrading to
draft-ietf-tls-esni-10 this morning. It should finish rolling out in a 
few

hours. Note that we've dropped support for draft-ietf-tls-esni-09.

The endpoint is https://crypto.cloudflare.com. You'll also find our ECH
config in the HTTPS resource record.


Good stuff. I have a client that thinks it's ready to go but
we'll see:-)


Well, surprisingly for me, that appears to have "just worked"
with no change to my draft-10 clients (neither s_client nor
curl).

(In case it helps someone else...) Is there any way that the
HTTP response content could differ if ECH succeeded or not?
I'm seeing the same 302 response in either case I think but
maybe there's some specific pathname or something that'd
result in different HTTP responses?

Thanks,
S.




I also have an openssl s_server running on port 8410 at
draft-10.esni.defo.ie with an ECHConfig published in the DNS
for that. It's probably v. fragile, so likely best to contact
me if playing with it. That works with my draft-10 openssl
s_client and with a build of curl using my fork of the
openssl library.

Cheers,
S.



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






OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] ECH-10 interop test server

2021-04-05 Thread Stephen Farrell



Hiya,

On 05/04/2021 18:01, Christopher Patton wrote:

Hi list, just FYI that Cloudflare's test server is upgrading to
draft-ietf-tls-esni-10 this morning. It should finish rolling out in a few
hours. Note that we've dropped support for draft-ietf-tls-esni-09.

The endpoint is https://crypto.cloudflare.com. You'll also find our ECH
config in the HTTPS resource record.


Good stuff. I have a client that thinks it's ready to go but
we'll see:-)

I also have an openssl s_server running on port 8410 at
draft-10.esni.defo.ie with an ECHConfig published in the DNS
for that. It's probably v. fragile, so likely best to contact
me if playing with it. That works with my draft-10 openssl
s_client and with a build of curl using my fork of the
openssl library.

Cheers,
S.



Best,
Chris P.


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



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] Don't Split HelloRetryRequest

2021-04-01 Thread Stephen Farrell



Hiya,

On 01/04/2021 19:24, Stephen Farrell wrote:

some guidance on checking your front-
end's choice of curves and failing when some of the HRR
cases get out of whack


Actually it occurs to me that we could for example say
that back-ends are RECOMMENDED to support the first
curve listed in ECHConfig for both ECH and the TLS h/s
and then also RECOMMEND that clients include a key share
for that curve as well. With that, it might be acceptable
to not use HRR (but fail) if the inner CH has no key
shares that the back-end can handle. Things like that
might reduce the number of HRR cases we need to handle
via new protocol mechanisms.

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] Don't Split HelloRetryRequest

2021-04-01 Thread Stephen Farrell



Hiya,

On 01/04/2021 19:28, Carrick Bartle wrote:

I absolutely agree both that we seem to be almost happily adding
complexity


I don't think you have to assume bad intent (or negligence). Several
people brought up valid concerns and we're trying to address them.


Hmm. I got an offlist mail on that too. I'm sorry
if I gave the impression that people's intentions
were dodgy, that really wasn't my intent. I think
it's entirely possible to have the best intentions
and yet to be too happy to add complexity. I've
done it myself loads of times in the past, and there
are even RFCs that show that;-) That is what I
think may be happening wrt ECH - we seem to be
forgetting that this stuff is inherently complex,
even in it's simplest case, and making it more
complex could kill it.

Cheers,
S.





On Apr 1, 2021, at 4:46 AM, Stephen Farrell
 wrote:


I'm not sure I agree with all of Martin's remarks below, but I
absolutely agree both that we seem to be almost happily adding
complexity and that that's a bad plan.

S.

On 01/04/2021 02:57, Martin Thomson wrote:

I just reviewed the proposal to split HelloRetryRequest into
outer and (encrypted) inner. 
https://github.com/tlswg/draft-ietf-tls-esni/pull/407/files I'm

strongly opposed to taking the change.  It complicates the design
greatly and unnecessarily. The existing design has some flaws,
but they can be fixed more elegantly than this. (Apologies if
this seems a little long.  I'm writing down every possible
argument I can think of, because I can't guarantee that I will be
coherent at the meeting.) # HelloRetryRequest Has a Narrow
Purpose Let's first address the key question of what
HelloRetryRequest exists to do.  It exists to ensure that the
client and server are able to jointly agree on keys to use for
the remainder of the handshake.  This is a very narrow scope. 
Furthermore, the particulars of key agreement are public.  This

is important as we can also say that all hidden servers need to
use the same configuration as it relates to cipher suites, key
exchange, and related parameters, as the results of negotiation
are sent in the clear in the ServerHello. My claim here is that
there is no value in protecting any parameter that might change
in response to HelloRetryRequest. # Don't Seek Complexity It is
entirely possible to imagine scenarios where an inner ClientHello
has different preferences from an outer ClientHello.  While in
theory we can construct a design that would support that (the
pull request does this well enough), to do so only serves to
increase complexity.  It does not address any real use case or
problem that I'm aware of. If we allow for the client to provide
different values in inner and outer ClientHello messages, then
the current design means that the client is faced with some
ambiguity about which of the two messages a HelloRetryRequest
applies to.  If we try to create an indicator, then that leaks. 
We could solve the problem by making the protocol more complex.

Or we could avoid it. This problem is entirely avoidable. #
Matching Inner and Outer Values When we get right down to it,
there are a very small number of things that truly change in
response to HelloRetryRequest.  And all of these changes are to
values that do not need confidentiality protection. The draft
lists three fields that change: ciphersuites, key_share, and
version.  From my perspective, changing cipher suites, supported
groups, or versions would be a big mistake.  So what changes is
even more limited.  Just the shares in key_share. On this basis,
a client that offers cipher suites, groups, versions, and key
shares that are identical in both inner and outer ClientHello
messages will always receive a HelloRetryRequest that applies
equally to both messages. The only adjustment that is acceptable
with respect to these fields being identical is the addition of
TLS 1.2-only options to the outer ClientHello (or the removal of
the same from the inner ClientHello if you prefer it that way
around).  This is a fine optimization on the basis that accepting
ECH represents a commitment to support TLS 1.3 (or higher).  But
it is really just an optimization (the draft makes this
mandatory, which is silly).  The client can therefore remove
options from the inner ClientHello only if it is impossible to
select them with TLS 1.3 or higher. For new extensions, if they
define a means of adjustment or correction via HelloRetryRequest
(there is currently just one: password_salt, which I haven't
examined), then they too need to follow this restriction.   It's
not an onerous one. Follow this simple constraint and
HelloRetryRequest will always apply equally to both inner and
outer ClientHello and everything works.  Conveniently, this is
more or less exactly what the current draft says.  Almost. The
draft currently allows inner and outer ClientHello to have
different types of key share.  The way it handles this is
terrible: it recommends breaking the transcript.  To me, that
seems like it would

1 2 3 4 5 >

1 - 100 of 477 matches

Mail list logo