[TLS]Re: Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Erik Nygren]

Submitted new revision:

 https://datatracker.ietf.org/doc/html/draft-ietf-tls-svcb-ech-02

Only change is adding the text to Security Considerations as discussed
above.

   Erik

On Wed, Apr 10, 2024 at 9:14 AM Sean Turner  wrote:

> Ted & ErikN,
>
> So it looks like ErikN submitted the following PR and ekr approved:
> https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/1
>
> If we have resolved your comments, can I ask on of the authors to spin a
> new version and we can look to move this I-D.
>
> Also, could I kindly ask you to revise your review to change to “ready”
> and maybe refer to thread:
> https://mailarchive.ietf.org/arch/msg/tls/VQcqUuOXSE8sgcp4_CHa6Jlc394/
>
> spt
>
> > On Mar 30, 2024, at 19:17, Eric Rescorla  wrote:
> >
> >
> >
> > On Sat, Mar 30, 2024 at 11:09 AM Ted Lemon  wrote:
> > Encrypted dns transport works if you can trust the provider you are
> talking to. DNSSEC works even if you can’t. And if your provider is
> trustworthy, DNSSEC validation of results acquired through this tunnel
> should work. So it’s silly in this case to trust the tunnel—there’s no
> upside to doing so other than avoiding a few signature verifications.
> >
> > I don't object to people doing DNSSEC validation of ECH records (though
> AFAIK no major browser does so), but...
> >
> > 1. The resolver only gains a limited amount by forging the SVCB response
> because the resolver already knows the domain name you are going to. This
> does conceal (say) the ALPN, but that's usually less interesting than the
> SNI.
> > 2. If the authoritative domain is misconfigured, which is not unheard
> of, then this can create resolution failures (this is true for A/, of
> course). Probably not much of an issue for the big public recursives, but
> can definitely be an issue if you are just talking to some locally-supplied
> resolver.
> >
> > -Ekr
> >
> >
> > Op za 30 mrt 2024 om 14:02 schreef Rob Sayre 
> > On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren 
> wrote:
> >
> > An attacker who can prevent SVCB resolution can deny clients any
> associated security benefits.
> >
> > Yes.
> >
> > A hostile recursive resolver can always deny service to SVCB queries,
> but network intermediaries can often prevent resolution as well, even when
> the client and recursive resolver validate DNSSEC and use a secure
> transport. These downgrade attacks can prevent a client from being aware
> that "ech" is configured which would result in the client sending the
> ClientHello in cleartext.
> >
> > I think s/would/could/ here.
> >
> > I don't know if we want to write it, but doesn't using encrypted
> transport DNS to an IP address avoid this problem? Like using 1.1.1.1 or
> 8.8.8.8 etc. I know that raises centralization issues, but it does help
> with this issue.
> >
> > thanks,
> > Rob
> >
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Erik Nygren]

I pulled some text directly over from the 9460 security considerations with
some minor tweaks:
 https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/1/files

An attacker who can prevent SVCB resolution can deny clients any associated
security benefits. A hostile recursive resolver can always deny service to
SVCB queries, but network intermediaries can often prevent resolution as
well, even when the client and recursive resolver validate DNSSEC and use a
secure transport. These downgrade attacks can prevent a client from being
aware that "ech" is configured which would result in the client sending the
ClientHello in cleartext. To prevent downgrades, {{Section 3.1 of !SVCB}}
recommends that clients abandon the connection attempt when such an attack
is detected.


On Sat, Mar 30, 2024 at 1:43 PM Rob Sayre  wrote:

> Yeah, that sounds fine. I think 9460 is pretty good in that it covers
> both DNSSEC and encrypted transports for DNS.
>
> thanks,
> Rob
>
>
> On Sat, Mar 30, 2024 at 10:27 AM Ted Lemon  wrote:
>
>> I think that would make sense, yes.
>>
>> On Sat, Mar 30, 2024 at 10:58 AM Erik Nygren 
>> wrote:
>>
>>> Do we want a few sentences in Security Considerations that references
>>> https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1 to call this
>>> out?
>>>
>>> This seems like something that became less clear when we split these two
>>> docs apart.
>>> Most of draft-ietf-tls-svcb-ech used to be a section of what is now
>>> rfc9460 but got split out
>>> due to publication timelines.  It may be that some non-normative
>>> references back to rfc9460
>>> might help readers not miss things like this which might have been more
>>> clear when they
>>> were a single document.
>>>
>>>Erik
>>>
>>>
>>>
>>>
>>> On Fri, Mar 29, 2024 at 11:31 PM Ted Lemon  wrote:
>>>
>>>> Yes, that fully addresses my concern. Thanks!
>>>>
>>>> Op vr 29 mrt 2024 om 22:54 schreef Eric Rescorla 
>>>>
>>>>>
>>>>> Hi Ted,
>>>>>
>>>>> Doesn't this section of RFC 9460 address this case and say what you
>>>>> are recommending:
>>>>>
>>>>> https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon  wrote:
>>>>>
>>>>>> Okay, I think I see the disconnect, maybe. The issue I'm pointing to
>>>>>> is that you may or may not be doing DNSSEC validation. And you may or may
>>>>>> not be /able/ to do DNSSEC validation if the infrastructure breaks it
>>>>>> accidentally or deliberately.
>>>>>>
>>>>>> The document says: "The SVCB-optional client behavior specified in
>>>>>> (Section 3 of [SVCB]) permits clients to fall back to a direct connection
>>>>>> if all SVCB options fail. This behavior is not suitable for ECH, because
>>>>>> fallback would negate the privacy benefits of ECH."
>>>>>>
>>>>>> So it's saying that the default handling of SVCB is incorrect and
>>>>>> would fail open, and overriding that behavior. Given that this is the 
>>>>>> case,
>>>>>> that implies that it matters whether the data has been validated, but
>>>>>> nowhere in the document, certainly not in Security Considerations, is any
>>>>>> mention made of this issue. So that's what I'm pointing out.
>>>>>>
>>>>>> It is absolutely not the case in practice that all stub resolvers do
>>>>>> validation. You are making a security decision about trust based on data
>>>>>> the trustworthiness of which you've not discussed, in a situation where 
>>>>>> the
>>>>>> implementor has meaningful choices to make with respect to validating 
>>>>>> that
>>>>>> trustworthiness. So it's worth mentioning that if the policy is not to
>>>>>> validate, this vulnerability exists.
>>>>>>
>>>>>> I'm a DNS guy, not a TLS guy, so I don't know the history of this
>>>>>> work—I'm just making this observation about the document I was asked to
>>>>>> review. The fact that (apparently) no DNSDIR review ever raised this 
>>>>>> issue
>>>>>> about the 

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Erik Nygren]

Do we want a few sentences in Security Considerations that references
https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1 to call this out?

This seems like something that became less clear when we split these two
docs apart.
Most of draft-ietf-tls-svcb-ech used to be a section of what is now rfc9460
but got split out
due to publication timelines.  It may be that some non-normative references
back to rfc9460
might help readers not miss things like this which might have been more
clear when they
were a single document.

   Erik




On Fri, Mar 29, 2024 at 11:31 PM Ted Lemon  wrote:

> Yes, that fully addresses my concern. Thanks!
>
> Op vr 29 mrt 2024 om 22:54 schreef Eric Rescorla 
>
>>
>> Hi Ted,
>>
>> Doesn't this section of RFC 9460 address this case and say what you are
>> recommending:
>>
>> https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1
>>
>> -Ekr
>>
>>
>>
>> On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon  wrote:
>>
>>> Okay, I think I see the disconnect, maybe. The issue I'm pointing to is
>>> that you may or may not be doing DNSSEC validation. And you may or may not
>>> be /able/ to do DNSSEC validation if the infrastructure breaks it
>>> accidentally or deliberately.
>>>
>>> The document says: "The SVCB-optional client behavior specified in
>>> (Section 3 of [SVCB]) permits clients to fall back to a direct connection
>>> if all SVCB options fail. This behavior is not suitable for ECH, because
>>> fallback would negate the privacy benefits of ECH."
>>>
>>> So it's saying that the default handling of SVCB is incorrect and would
>>> fail open, and overriding that behavior. Given that this is the case, that
>>> implies that it matters whether the data has been validated, but nowhere in
>>> the document, certainly not in Security Considerations, is any mention made
>>> of this issue. So that's what I'm pointing out.
>>>
>>> It is absolutely not the case in practice that all stub resolvers do
>>> validation. You are making a security decision about trust based on data
>>> the trustworthiness of which you've not discussed, in a situation where the
>>> implementor has meaningful choices to make with respect to validating that
>>> trustworthiness. So it's worth mentioning that if the policy is not to
>>> validate, this vulnerability exists.
>>>
>>> I'm a DNS guy, not a TLS guy, so I don't know the history of this
>>> work—I'm just making this observation about the document I was asked to
>>> review. The fact that (apparently) no DNSDIR review ever raised this issue
>>> about the other documents you mentioned is of no interest to me—I'm not
>>> reviewing those documents.Whether you take this advice is between you and
>>> the IESG. I'm not even claiming to be right—just pointing out the issue I
>>> see.
>>>
>>> On Fri, Mar 29, 2024 at 7:21 PM Rob Sayre  wrote:
>>>
 I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC
 failure) or you can fail during ECH (unless you want to use non-ECH, which
 is not ECH, and not part of this draft).

 It makes sense to me: one can reject a request unless the requirements
 embedded in the SVCB are met (the server chooses those, which can include
 many aspects of the request). I don't understand why one would insert
 DNSSEC here. That seems to be the whole point--it works without it.

 thanks,
 Rob


 On Fri, Mar 29, 2024 at 3:57 PM Ted Lemon  wrote:

> I'm not telling you that you have to require DNSSEC. I'm saying the
> document is incomplete if you don't talk about how it relates to DNSSEC. I
> think EKR got the point, so maybe go with his approach?
>
> On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:
>
>> It's a policy choice, though, right? I think ekr hinted at this issue
>> as well.
>>
>> It's that one might also view requests that reveal the SNI as
>> insecure. If that's the case, DNSSEC doesn't help. There will certainly 
>> be
>> a transition period where that will be impractical for many servers. I
>> think these are separate problems, though.
>>
>> thanks,
>> Rob
>>
>>
>> On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:
>>
>>> It looks like if you can't get the SCVB you're going to fail
>>> insecure, so being able to use DNSSEC to prevent that for signed domains
>>> seems worthwhile.
>>>
>>> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:
>>>
 On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
 nore...@ietf.org> wrote:

>
> I don't think it's reasonable to specify the privacy properties of
> SVCB and
> /not/ talk about DNSSEC validation.
>

 Could you explain more about this part? I think DNSSEC doesn't add
 much here, unless you want to accept non-ECH traffic. For example, 
 many of
 the test servers will bounce you to some other site if you don't send 
 

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

[Erik Nygren]

The registry already exists with the pointer to ech (5) :

https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml

so no action is needed to make sure it isn't allocated for something else.
(Removing it would be more effort and more problematic.)
Do we believe the draft is stable enough that we should reference it
informationally for that code point?


On Wed, Sep 20, 2023 at 3:01 PM David Benjamin 
wrote:

> I don't think what we do with the registry has any bearing on whether the
> codepoint is burned. There are already draft ECH deployments today, on both
> the client and server side, independent of what we later put in the
> registry. Rather, the ECHConfigList structure is internally versioned, so
> as long as we keep that structure, the codepoint isn't burned. If we find
> we need to change the versioning scheme, that will indeed be incompatible,
> and we'll need to switch codepoints. I wouldn't expect that to happen, but
> I don't think we need to be deathly worried about it either. Codepoints are
> plentiful.
>
> So I'd suggest that reserving it makes sense (to make sure no one
> allocates it for something unrelated to ECH), and we can
> leave draft-sbn-tls-svcb-ech to sort out the true allocation. If that
> doesn't work procedurally, it's probably not worth the energy and we can
> just omit the entry from the SVCB spec. We'd just then be relying on the
> expert review to not accidentally use the value for something else.
>
> On Wed, Sep 20, 2023 at 2:44 PM Erik Nygren  wrote:
>
>> We're going through AUTH48 with SVCB right now and reviewing edits from
>> the RFC Editor.  I think there is a good question of how to handle this.
>> Right now it is "RESERVED (will be used for ECH)" for SvcParamKey "ech" (5)
>> but we also say:
>>
>> New entries in this registry are subject to an Expert Review registration
>> policy ([RFC8126
>> <https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-12.html#RFC8126>],
>> Section 4.5 <https://rfc-editor.org/rfc/rfc8126#section-4.5>). The
>> designated expert MUST ensure that the Format Reference is stable and
>> publicly available, and that it specifies how to convert the
>> SvcParamValue's presentation format to wire format. The Format Reference
>> MAY be any individual's Internet-Draft, or a document from any other source
>> with similar assurances of stability and availability. An entry MAY specify
>> a Format Reference of the form "Same as (other key Name)" if it uses the
>> same presentation and wire formats as an existing key.
>>
>> This puts this in a weird state given that the ECH specification is not
>> stable yet and did have some changes.
>> Perhaps a question for the dnsops chairs and Warren as well?
>>
>> Should draft-ietf-tls-esni be referenced informationally?  It seems like
>> there's a risk of "ech=" (5) getting burned as a codepoint
>> given that implementations may exist with different interpretations...
>>
>>   Erik
>>
>>
>>
>> On Tue, Sep 19, 2023 at 11:22 AM Sean Turner  wrote:
>>
>>>
>>>
>>> > On Sep 18, 2023, at 21:39, Stephen Farrell 
>>> wrote:
>>> >
>>> > 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’ll check with the dnsops chairs.
>>>
>>> spt
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Erik Nygren]

We're going through AUTH48 with SVCB right now and reviewing edits from the
RFC Editor.  I think there is a good question of how to handle this.  Right
now it is "RESERVED (will be used for ECH)" for SvcParamKey "ech" (5) but
we also say:

New entries in this registry are subject to an Expert Review registration
policy ([RFC8126
],
Section 4.5 ). The
designated expert MUST ensure that the Format Reference is stable and
publicly available, and that it specifies how to convert the
SvcParamValue's presentation format to wire format. The Format Reference
MAY be any individual's Internet-Draft, or a document from any other source
with similar assurances of stability and availability. An entry MAY specify
a Format Reference of the form "Same as (other key Name)" if it uses the
same presentation and wire formats as an existing key.

This puts this in a weird state given that the ECH specification is not
stable yet and did have some changes.
Perhaps a question for the dnsops chairs and Warren as well?

Should draft-ietf-tls-esni be referenced informationally?  It seems like
there's a risk of "ech=" (5) getting burned as a codepoint
given that implementations may exist with different interpretations...

  Erik



On Tue, Sep 19, 2023 at 11:22 AM Sean Turner  wrote:

>
>
> > On Sep 18, 2023, at 21:39, Stephen Farrell 
> wrote:
> >
> > 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’ll check with the dnsops chairs.
>
> spt
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Erik Nygren]

I was thinking about the new extension idea more.  It has the downside of
potentially being an API change in client/server TLS stacks,
but opening this up might generally be worth considering.  If we added an
"Extended SNI" extension to support IPAddress,
we might also want to consider if there are other things worth adding.

Also including an Extended SNI option for "Certificate Fingerprint" would
solve a bunch of issues
that have come up from time-to-time.  For example, it might help with DANE.

We've also talked in the past about being able to include a certificate
fingerprint
in URIs, and being able to signal that in Extended SNI would likely make
that work better.
(A use-case for this is for using TLS in local/private network environments
such as to
home network devices or even localhost processes where being able to have a
URI
with an {IP,cert_fingerprint(s)} pairing would have better security
properties than trying
to use some global PKIX framework.)

Is this something worth considering or that others in the WG might be
interested in?

Erik





On Wed, Jul 27, 2022 at 4:16 PM David Benjamin 
wrote:

> I agree this is quite a compatibility risk. In addition to messing with
> SNI lookup, there are servers that try to correlate TLS SNI and HTTP Host.
> Indeed, when we accidentally sent IP literals in SNI, we broke a server
> that tried to do that but got very confused by the colons in an IPv6
> literal. That server would likely also be confused by this draft, less by
> syntax and more by SNI/Host mismatch. I would be surprised if this option
> were viable.
>
> Another option, which doesn't require redefining existing fields, is to
> simply allocate a new extension. Though I agree with Martin that one would
> expect the server to know its own IP. If you implicitly interpret a missing
> server_name extension as "I want the IP cert for this connection's IP",
> it's already unambiguous. Granted, there may be edge cases because missing
> server_name can also mean "I want the default cert" and perhaps your
> "default" cert and IP cert are different.
>
> On Wed, Jul 27, 2022 at 12:17 PM Martin Thomson  wrote:
>
>> Hi Erik,
>>
>> As far as it goes, this might work.  However, I'm not sure about the
>> effect of this on compatibility.  I'm concerned that maybe this would end
>> up causing some servers to choke.  Servers that receive SNI can sometimes
>> use that SNI value to lookup the correct certificate.  Your design could
>> have those servers searching for a certificate that doesn't exist.
>>
>> Anything along these lines would need to be tested for compatibility -
>> extensively - before it could even be trialed.
>>
>> (I never saw the DDR as having deployment problems along these lines.  It
>> isn't THAT hard to know your own IP address for that purpose.)
>>
>> On Wed, Jul 27, 2022, at 14:38, Erik Nygren wrote:
>> > Following discussions in ADD around the DDR draft (as well as in UTA
>> > around Martin Thomson's PR to add IP address SANs to 6125-bis),
>> > I wrote up a draft on how IP addresses might be represented in SNI:
>> >
>> >   https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>> >
>> > There are at least three different ways we could do it, but this draft
>> > proposes what seems to be the least bad while also talking about the
>> > other alternatives.  (I suspect we'd want to move the alternatives
>> > to an appendix or remove entirely from a final version.)
>> >
>> > Is this interesting to the working group?
>> > While IP address SANs have a bunch of corner cases and gaps,
>> > they do seem to be picking up new uses.
>> >
>> > What motivated me to realize we need to solve this is that
>> > draft-ietf-add-ddr uses IP SANs in a new way.  Rather than the
>> > client connecting to an IP address and expecting to see a SAN
>> > (where returning a cert associated with the IP address containing
>> > a SAN that the client connected to is straight-forward),
>> > DDR has clients connecting to a different IP and then
>> > expects to find an original IP also in the SAN list.
>> > This means that for an ISP with a large number of IPs
>> > (or using a services who operates DoH service on-behalf
>> > of many entities), you'd need to quickly/wastefully burn through IPv4
>> > addresses to enable a unique cert per original IP.
>> >
>> > Erik
>> >
>> >
>> > -- Forwarded message -
>> > From: 
>> > Date: Wed, Jul 27, 2022 at 2:20 PM
>> > Subject: New Version Notification for dra

Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Erik Nygren]

The use-case that may increase IP certificates is this from ADD's DDR:

https://datatracker.ietf.org/doc/html/draft-ietf-add-ddr-08#section-4.2

At a high-level, the client talks insecurely to their configured local DNS
resolver with IP address "A"
and queries for "_dns.resolver.arpa."
That returns a SVCB record that points to another DNS resolver that may
have hostname dot.example.com
with IP address "B".
As part of the "Verified Discovery" logic, the client connects to
dot.example.com (IP address "B")
but then has to verify that the presented TLS certificate contains IP
address "A".

If they share an IP address this is straight-forward (and a "normal" IP
address cert).
But if A and B are different IPs then "dot.example.com" in this case may
need
a separate IP address "B" (and hostname) for each IP address "A" that might
be in-use
(with perhaps some efficiencies possible through SAN-packing).

Erik


On Thu, Jul 28, 2022 at 3:04 PM Tim Hollebeek 
wrote:

> I’m worried about the fact that this means a certificate that was issued
> for and intended to be used by a particular IP address is now potentially
> usable on any arbitrary IP address via this behavior.  Though I haven’t
> thought it all the through yet, it seems to me to be likely that there are
> use cases where this has at least mild unexpected security consequences.
> Bonus points if you find a way this makes it easier to collect traffic
> intended for that IP from a different IP.
>
>
>
> On .in-addr.arpa certificates, I’ve been trying to find out why there are
> web servers running on those domains since I was at my previous employer
> over five years ago, and have been periodically asking about them:
>
>
>
>
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg11410.html
>
>
>
> If anyone knows why they exist, I’d love to know.
>
>
>
> Also, if IP certificates are getting more common again, I’d love to hear
> about those use cases as they’re not on my radar at this time.  When I
> wrote the ballot for validation of IP addresses, it was a royal pain and
> took a few years because no one was actually interested in them.  My
> impression was that they were slowly going away with time, but I haven’t
> looked at the numbers recently.
>
>
>
> -Tim
>
>
>
> *From:* TLS  *On Behalf Of * Erik Nygren
> *Sent:* Wednesday, July 27, 2022 4:59 PM
> *To:* David Benjamin 
> *Cc:* TLS@ietf.org
> *Subject:* Re: [TLS] Representing IP addresses in SNI -- proposed draft
>
>
>
> Both of these are very good concerns about the compatibility risk.
>
> I think David's alternative of having a new extension (eg, server_name_ip)
>
> might address a bunch of the issues and be cleaner than any of the other
> hacks.
>
> It would have a higher implementation overhead, but also might be more
> likely to be deployable.
>
>
>
> I checked search.censys.io and there appear to be around 150M certificates
>
> with IP addresses in them that it is aware of, and that is pretty much a
> guarantee
>
> that some of them will break with sending something new in an existing SNI
> extension...
>
>
>
> Erik
>
>
>
>
>
> On Wed, Jul 27, 2022 at 4:16 PM David Benjamin 
> wrote:
>
> I agree this is quite a compatibility risk. In addition to messing with
> SNI lookup, there are servers that try to correlate TLS SNI and HTTP Host.
> Indeed, when we accidentally sent IP literals in SNI, we broke a server
> that tried to do that but got very confused by the colons in an IPv6
> literal. That server would likely also be confused by this draft, less by
> syntax and more by SNI/Host mismatch. I would be surprised if this option
> were viable.
>
>
>
> Another option, which doesn't require redefining existing fields, is to
> simply allocate a new extension. Though I agree with Martin that one would
> expect the server to know its own IP. If you implicitly interpret a missing
> server_name extension as "I want the IP cert for this connection's IP",
> it's already unambiguous. Granted, there may be edge cases because missing
> server_name can also mean "I want the default cert" and perhaps your
> "default" cert and IP cert are different.
>
>
>
> On Wed, Jul 27, 2022 at 12:17 PM Martin Thomson  wrote:
>
> Hi Erik,
>
> As far as it goes, this might work.  However, I'm not sure about the
> effect of this on compatibility.  I'm concerned that maybe this would end
> up causing some servers to choke.  Servers that receive SNI can sometimes
> use that SNI value to lookup the correct certificate.  Your design could
> have those servers searching fo

Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Erik Nygren]

Both of these are very good concerns about the compatibility risk.
I think David's alternative of having a new extension (eg, server_name_ip)
might address a bunch of the issues and be cleaner than any of the other
hacks.
It would have a higher implementation overhead, but also might be more
likely to be deployable.

I checked search.censys.io and there appear to be around 150M certificates
with IP addresses in them that it is aware of, and that is pretty much a
guarantee
that some of them will break with sending something new in an existing SNI
extension...

Erik


On Wed, Jul 27, 2022 at 4:16 PM David Benjamin 
wrote:

> I agree this is quite a compatibility risk. In addition to messing with
> SNI lookup, there are servers that try to correlate TLS SNI and HTTP Host.
> Indeed, when we accidentally sent IP literals in SNI, we broke a server
> that tried to do that but got very confused by the colons in an IPv6
> literal. That server would likely also be confused by this draft, less by
> syntax and more by SNI/Host mismatch. I would be surprised if this option
> were viable.
>
> Another option, which doesn't require redefining existing fields, is to
> simply allocate a new extension. Though I agree with Martin that one would
> expect the server to know its own IP. If you implicitly interpret a missing
> server_name extension as "I want the IP cert for this connection's IP",
> it's already unambiguous. Granted, there may be edge cases because missing
> server_name can also mean "I want the default cert" and perhaps your
> "default" cert and IP cert are different.
>
> On Wed, Jul 27, 2022 at 12:17 PM Martin Thomson  wrote:
>
>> Hi Erik,
>>
>> As far as it goes, this might work.  However, I'm not sure about the
>> effect of this on compatibility.  I'm concerned that maybe this would end
>> up causing some servers to choke.  Servers that receive SNI can sometimes
>> use that SNI value to lookup the correct certificate.  Your design could
>> have those servers searching for a certificate that doesn't exist.
>>
>> Anything along these lines would need to be tested for compatibility -
>> extensively - before it could even be trialed.
>>
>> (I never saw the DDR as having deployment problems along these lines.  It
>> isn't THAT hard to know your own IP address for that purpose.)
>>
>> On Wed, Jul 27, 2022, at 14:38, Erik Nygren wrote:
>> > Following discussions in ADD around the DDR draft (as well as in UTA
>> > around Martin Thomson's PR to add IP address SANs to 6125-bis),
>> > I wrote up a draft on how IP addresses might be represented in SNI:
>> >
>> >   https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>> >
>> > There are at least three different ways we could do it, but this draft
>> > proposes what seems to be the least bad while also talking about the
>> > other alternatives.  (I suspect we'd want to move the alternatives
>> > to an appendix or remove entirely from a final version.)
>> >
>> > Is this interesting to the working group?
>> > While IP address SANs have a bunch of corner cases and gaps,
>> > they do seem to be picking up new uses.
>> >
>> > What motivated me to realize we need to solve this is that
>> > draft-ietf-add-ddr uses IP SANs in a new way.  Rather than the
>> > client connecting to an IP address and expecting to see a SAN
>> > (where returning a cert associated with the IP address containing
>> > a SAN that the client connected to is straight-forward),
>> > DDR has clients connecting to a different IP and then
>> > expects to find an original IP also in the SAN list.
>> > This means that for an ISP with a large number of IPs
>> > (or using a services who operates DoH service on-behalf
>> > of many entities), you'd need to quickly/wastefully burn through IPv4
>> > addresses to enable a unique cert per original IP.
>> >
>> > Erik
>> >
>> >
>> > -- Forwarded message -
>> > From: 
>> > Date: Wed, Jul 27, 2022 at 2:20 PM
>> > Subject: New Version Notification for draft-nygren-tls-ip-in-sni-00.txt
>> > To: Erik Nygren mailto:erik%2bi...@nygren.org>>,
>>
>> > Rich Salz 
>> >
>> >
>> >
>> > A new version of I-D, draft-nygren-tls-ip-in-sni-00.txt
>> > has been successfully submitted by Erik Nygren and posted to the
>> > IETF repository.
>> >
>> > Name:   draft-nygren-tls-ip-in-sni
>> > Revision:   00
>> > Title:  Representing IP addresses in TLS 

[TLS] Representing IP addresses in SNI -- proposed draft

[Erik Nygren]

Following discussions in ADD around the DDR draft (as well as in UTA
around Martin Thomson's PR to add IP address SANs to 6125-bis),
I wrote up a draft on how IP addresses might be represented in SNI:

  https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/

There are at least three different ways we could do it, but this draft
proposes what seems to be the least bad while also talking about the
other alternatives.  (I suspect we'd want to move the alternatives
to an appendix or remove entirely from a final version.)

Is this interesting to the working group?
While IP address SANs have a bunch of corner cases and gaps,
they do seem to be picking up new uses.

What motivated me to realize we need to solve this is that
draft-ietf-add-ddr uses IP SANs in a new way.  Rather than the
client connecting to an IP address and expecting to see a SAN
(where returning a cert associated with the IP address containing
a SAN that the client connected to is straight-forward),
DDR has clients connecting to a different IP and then
expects to find an original IP also in the SAN list.
This means that for an ISP with a large number of IPs
(or using a services who operates DoH service on-behalf
of many entities), you'd need to quickly/wastefully burn through IPv4
addresses to enable a unique cert per original IP.

Erik


-- Forwarded message -
From: 
Date: Wed, Jul 27, 2022 at 2:20 PM
Subject: New Version Notification for draft-nygren-tls-ip-in-sni-00.txt
To: Erik Nygren , Rich Salz 



A new version of I-D, draft-nygren-tls-ip-in-sni-00.txt
has been successfully submitted by Erik Nygren and posted to the
IETF repository.

Name:   draft-nygren-tls-ip-in-sni
Revision:   00
Title:  Representing IP addresses in TLS Server Name Indication
(SNI)
Document date:  2022-07-27
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/archive/id/draft-nygren-tls-ip-in-sni-00.txt
Status: https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-nygren-tls-ip-in-sni


Abstract:
   This specification provides a mechanism for clients to send IP
   addresses in a TLS Server Name Indication (SNI) extension as part of
   TLS handshakes, allowing servers to return a certificate containing
   that subjectAltName.  This is done by converting the IP address to a
   special-use domain name.




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

[TLS] Narrowing allowed characters in ALPN ?

[Erik Nygren]

With draft-ietf-dnsop-svcb-https being in WGLC in DNSOP, one feedback that
has come up is that the escaping and parsing for SvcParamValues is
complicated.
Most of this complication comes from trying to support 8-bit clean ALPN
values.
Ideally in presentation format the ALPN list would be something like
"h2,h3,http/1.1"
but at the same time the current definition of ALPN as being a series of
binary
octets means that we need parsing and escaping rules.
When httpbis defined Alt-Svc, quite a bit of complexity showed up there
as well for supporting an 8-bit-clean ALPN value while allowing for an ascii
representation for most codepoints.  It seems likely that other
specifications
may run into the same challenge.

Would there be support for updating the ALPN registry to
indicate that registered ALPN values need to conform to a subset of token
characters?   There is a separate question for the process of making
this change, but before even exploring that it seems necessary to ask
the TLS WG if there are strong opinions on this one way or the other.

>From a usability perspective, non-token ALPN values will have challenges
in many of the systems that may try and configure them, as well
as for rendering special characters in various systems that may handle
ALPNs.
The codepoint space is also massive so it isn't clear that there's a
compelling
need to support 8-bit ALPN from a code point conservation perspective.

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

[TLS] Hopefully-final draft-ietf-dnsop-svcb-https-04 and nearing WGLC

[Erik Nygren]

We've closed out most of the open issues on draft-ietf-dnsop-svcb-https
and it will be going to WGLC shortly.

Current version at:

  https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-04.txt

Hopefully we're done, but you can open issues against:

https://github.com/MikeBishop/dns-alt-svc

This will likely get batched up while waiting for TLS ECH to publish due
to some cross-dependencies.

Change history for the last few versions:

   o  draft-ietf-dnsop-svcb-https-04

  *  Simplify the IANA instructions (pure First Come First Served)

  *  Recommend against publishing chains of >8 aliases

  *  Clarify requirements for using SVCB with a transport proxy

  *  Adjust guidance for Port Prefix Naming

  *  Minor editorial updates

   o  draft-ietf-dnsop-svcb-https-03

  *  Simplified escaping of comma-separated values

  *  Reorganized client requirements

  *  Added a warning about port filtering for cross-protocol attacks

  *  Clarified self-consistency rules for SvcParams

  *  Added a non-normative mapping summary table for HTTPS

   o  draft-ietf-dnsop-svcb-https-02

  *  Added a Privacy Considerations section

  *  Adjusted resolution fallback description

  *  Clarified status of SvcParams in AliasMode

  *  Improved advice on zone structuring and use with Alt-Svc

  *  Improved examples, including a new Multi-CDN example

  *  Reorganized text on value-list parsing and SvcPriority

  *  Improved phrasing and other editorial improvements throughout

   o  draft-ietf-dnsop-svcb-https-01

  *  Added a "mandatory" SvcParamKey

  *  Added the ability to indicate that a service does not exist

  *  Adjusted resolution and ALPN algorithms

  *  Major terminology revisions for "origin" and CamelCase names

  *  Revised ABNF

  *  Include allocated RR type numbers

  *  Various corrections, explanations, and recommendations

   o  draft-ietf-dnsop-svcb-https-00

  *  Rename HTTPSSVC RR to HTTPS RR

  *  Rename "an SVCB" to "a SVCB"

  *  Removed "design considerations and open issues" section and
 some other "to be removed" text



-- Forwarded message -

A new version of I-D, draft-ietf-dnsop-svcb-https-04.txt
has been successfully submitted by Ben Schwartz and posted to the
IETF repository.

Name:   draft-ietf-dnsop-svcb-https
Revision:   04
Title:  Service binding and parameter specification via the DNS
(DNS SVCB and HTTPS RRs)
Document date:  2021-03-17
Group:  dnsop
Pages:  48
URL:
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-04.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https
Htmlized:   https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-04
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04

Abstract:
   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTPS origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, each with associated parameters (such as transport
   protocol configuration and keys for encrypting the TLS ClientHello).
   They also enable aliasing of apex domains, which is not possible with
   CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
   origins.  By providing more information to the client before it
   attempts to establish a connection, these records offer potential
   benefits to both performance and privacy.

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/MikeBishop/dns-alt-svc [1].  The most recent
   working version of the document, open issues, etc. should all be
   available there.  The authors (gratefully) accept pull requests.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Network Tokens I-D and TLS / ESNI

[Erik Nygren]

One quick comment is that binding tokens to IP addresses is strongly
counter-recommended.
It doesn't survive NATs or proxies, mobility, and it is especially
problematic in IPv6+IPv4 dual-stack environments.
(Even in IPv6-only, privacy addressing causes problems here.)  Even if you
have a way to convert tokens over
for your set of IP addresses (eg, to deal with dual-stack) that still may
not help enough with NAT environments.

  Erik


On Thu, Jun 25, 2020 at 4:29 PM Yiannis Yiakoumis <
yian...@selfienetworks.com> wrote:

> Hi all,
>
> I wanted to briefly introduce network tokens 
> into this list, how they relate with TLS and ESNI, and kindly ask anyone
> that is interested to share feedback and join the discussion.
>
> Network tokens is a method for endpoints to explicitly and securely
> coordinate with networks about how their traffic is treated. They are
> inserted by endpoints in existing protocols, interpreted by trusted
> networks, and may be signed or encrypted to meet security and privacy
> requirements. Network tokens provide a means for network operators to
> expose datapath services (such as a zero-rating service, a user-driven QoS
> service, or a firewall whitelist), and for end users and application
> providers to access such services. Network tokens are inspired and derived
> by existing security tokens (like JWT and CWT), borrowing several of their
> security and privacy properties, and adjusting them for use in a networking
> context.
>
> There are two ways that network tokens relate with TLS:
>
>1. They can support ESNI adoption: in a world where ESNI is widely
>adopted, network tokens can enable use cases where endpoint-network
>coordination is required, without having to go back to plaintext SNI that
>everyone can read.
>2. Network tokens are embedded as TLS handshake extensions (among
>others).
>
> We are shooting for a BoF in November, and are very much interested into
> feedback around the concept, use cases, what we need to do to make network
> tokens adopted as a TLS handshake extension, and folks that are interested
> to get involved in the effort!
>
> Links to an IETF I-D, a mailing list, and initial implementation are
> available at https://networktokens.org  .
>
> Best,
> Yiannis
>
> =
> Yiannis Yiakoumis
> Co-Founder & CEO
> https://selfienetworks.com | +1-650-644-7857
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Bikeshedding ECHO

[Erik Nygren]

Are there any objections to "ECH" or should we just go with that?
(I'd like to update the parameter name in SRVB/HTTPSSVC accordingly based
on what gets decided.)


On Wed, May 20, 2020 at 11:37 PM Tommy Pauly  wrote:

> ECH is good. Go for it!
>
> Tommy
>
> On May 20, 2020, at 11:34 AM, Erik Nygren  wrote:
>
> 
>
> ECH works for me.  (I really don't care between ECH and ETCH and thing
> both are fine.)
>
> Erik
>
>
> On Wed, May 20, 2020 at 2:20 PM Christopher Wood 
> wrote:
>
>> On Tue, May 19, 2020, at 8:18 PM, Filippo Valsorda wrote:
>> > As a data point, I was fairly confused when ECHO came up in
>> > conversation, and had to stop to ask what it was. I think I would have
>> > had a better chance of figuring it out from context or search if it
>> > were called ECH, but don't have a strong preference for any specific
>> > name.
>> >
>> > ECH does have a remarkable short Wikipedia disambiguation list, FWIW.
>> > https://en.wikipedia.org/wiki/ECH
>>
>> ECH also works for me.
>>
>> Best,
>> Chris (no hat)
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Bikeshedding ECHO

[Erik Nygren]

ECH works for me.  (I really don't care between ECH and ETCH and thing both
are fine.)

Erik


On Wed, May 20, 2020 at 2:20 PM Christopher Wood 
wrote:

> On Tue, May 19, 2020, at 8:18 PM, Filippo Valsorda wrote:
> > As a data point, I was fairly confused when ECHO came up in
> > conversation, and had to stop to ask what it was. I think I would have
> > had a better chance of figuring it out from context or search if it
> > were called ECH, but don't have a strong preference for any specific
> > name.
> >
> > ECH does have a remarkable short Wikipedia disambiguation list, FWIW.
> > https://en.wikipedia.org/wiki/ECH
>
> ECH also works for me.
>
> Best,
> Chris (no hat)
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Bikeshedding ECHO

[Erik Nygren]

+1 to "ETCH"

Any objections to that or concerns with that?
(Agreed it would be good to finalize this ASAP.)

On Thu, May 7, 2020 at 7:03 PM Tommy Pauly  wrote:

> ECHO is more fun to say, but I do see how it can be confusing (sounding
> like some sort of ping) when out of the context of TLS.
>
> To that end, I’d have a minor preference for “ETCH”.
>
> Thanks,
> Tommy
>
> > On May 7, 2020, at 3:52 PM, Christopher Wood 
> wrote:
> >
> > Erik raises some compelling reasons to change the name from ECHO to...
> something else less confusing or misleading [1]. Candidates from the PR
> include ETCH (Encrypted TLS Client Hello), ECH, and EHELLO. Since the
> HTTPSSVC draft aims for WGLC before IETF 108, it would be good if we got
> this bikeshedding out of the way now. To that end, if you have an opinion
> on the name and whether or not we should change it, please share it!
> >
> > Thanks,
> > Chris (no hat)
> >
> > [1] https://github.com/tlswg/draft-ietf-tls-esni/issues/232
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

[Erik Nygren]

Following the discussions in Montreal (as well as with some of the ESNI
authors),
we refactored the HTTPSSVC draft to make it more general.  The hope is that
it could be an alternative (or replace the need) for a distinct ESNI record.
The draft generalizes to a protocol-agnostic SVCB record, but also specifies
an HTTPSSVC record for the HTTP(S) use-case.

Based on discussions with various chairs, the plan is to call for adoption
in the DNSOP WG.

Comments/feedback are most welcome.

  Erik


-- Forwarded message -
From: Erik Nygren 
Date: Tue, Sep 24, 2019 at 9:17 AM
Subject: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
To: dnsop WG , Ben Schwartz , Mike
Bishop 


Following discussions around the "HTTPSSVC" record proposal in Montreal
with the DNSOP, HTTP and TLS WGs, we've updated what was previously
"draft-nygren-httpbis-httpssvc-03".  The new version is
"draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the
feedback from the WG discussions, as well as feedback from discussions with
the TLS WG (as we'd like to see this replace the need for a separate ESNI
record).

In particular, it generalizes the record into a new "SVCB" record which
doesn't have any protocol-specific semantics.  It also defines an
"HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and
parameter registry) and which defines the HTTP(S)-specific semantics such
as bindings to Alt-Svc.  Other protocols can either define bindings
directly to SVCB or can define their own RR Type (which should only ever be
needed if there is a need to use the record at a zone apex).

We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs
can go against:  https://github.com/MikeBishop/dns-alt-svc

Major changes from "draft-nygren-httpbis-httpssvc-03" include:

* Separation into the SVCB and HTTPSSVC RR Types  (and separated all of the
HTTPS-specific functionality and text to its own portion of the document).
* Elimination of the SvcRecordType field (and making the SvcRecordType
implicit)
* Changing the wire format of parameters from being in Alt-Svc text format
to a more general binary key/value pair format (with a mapping to Alt-Svc
for HTTPSSVC).
* Adding optional "ipv4hint" and "ipv6hint" parameters.
* Quite a few cleanups and clarifications based on input (and we
undoubtedly have more left to go)

This retains support for all of the use-cases that the previous HTTPSSVC
record had (such as for covering the ANAME / CNAME-at-the-zone-apex
use-case).

Feedback is most welcome.  If the TLS WG is going to use this instead of a
separate ESNI record, there is a desire to make progress on this fairy
quickly.

   Erik

-- Forwarded message -
From: 
Date: Mon, Sep 23, 2019 at 7:01 PM
Subject: New Version Notification for
draft-nygren-dnsop-svcb-httpssvc-00.txt
To: Mike Bishop , Erik Nygren ,
Benjamin Schwartz 



A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:   draft-nygren-dnsop-svcb-httpssvc
Revision:   00
Title:  Service binding and parameter specification via the DNS
(DNS SVCB and HTTPSSVC)
Document date:  2019-09-22
Group:  Individual Submission
Pages:  33
URL:
https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt
Status:
https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/
Htmlized:
https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-svcb-httpssvc


Abstract:
   This document specifies the "SVCB" and "HTTPSSVC" DNS resource record
   types to facilitate the lookup of information needed to make
   connections for origin resources, such as for HTTPS URLs.  SVCB
   records allow an origin to be served from multiple network locations,
   each with associated parameters (such as transport protocol
   configuration and keying material for encrypting TLS SNI).  They also
   enable aliasing of apex domains, which is not possible with CNAME.
   The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP
   origins.  By providing more information to the client before it
   attempts to establish a connection, these records offer potential
   benefits to both performance and privacy.

   TO BE REMOVED: This proposal is inspired by and based on recent DNS
   usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long
   standing desires to have SRV or a functional equivalent implemented
   for HTTP).  These proposals each provide an important function but
   are potentially incompatible with each other, such as when an origin
   is load-balanced across multiple hosting providers (multi-CDN).
   Furthermore, these each add potential cases for adding additional
   record lookups in-addition

Re: [TLS] HTTPSSVC record draft - ESNI alternative for HTTPS

[Erik Nygren]

Hi Stephen,

On Mon, Jul 8, 2019 at 5:39 PM Stephen Farrell 
wrote:

>
> On 08/07/2019 22:27, Erik Nygren wrote:
> >
> > In particular for the TLS WG, we'd be interested in hearing if this would
> > solve enough of the ESNI-key-delivery-via-DNS needs for the HTTPS
> use-case.
>
> I'm not clear if you envisage this entirely replacing the
> new ESNI RR (as defined in ESNI draft-03), or if you envisage
> both being defined, with this one (HTTPSSVC) being used for
> the web and the ESNI RR for non-web uses of TLS, or maybe
> something else?
>
> It'd seem like a bad plan two have multiple ways of doing
> the same thing, but I guess there're trade-offs in various
> directions here.
>

My thinking is that different protocols have different needs
and requirements for key delivery via DNS.  As such, separating
out the ESNI key format from the DNS record for provisioning
makes sense.  EKR had the valid point that it would be valuable
to have a basic way of doing ESNI key provisioning for protocols
lacking complex requirements.

This could end up as "protocols should specify bindings for how
ESNI keys are delivered via DNS", with a HTTPSSVC RR for the HTTPS
use-case, perhaps with other protocol bindings for other things with
specific requirements, and with an ESNI RR (which might be able
to be made simpler if some of the Web requirements can be abstracted)
for generic use-cases.

A downside is that this does add complexity for tools that operate entirely
at the TLS layer such as openssl s_client that would be happier if only
an ESNI record existed.  However, the HTTPS use-case
already has a bunch of other scenarios such as HTTP/3 that break/blur
this abstraction layer such that it may be that this type of HTTPS
connection
management and DNS resolution needs to be done at the HTTP session layer
regardless, with TLS libraries providing an interface to pass in ESNI keys.

Encrypting authoritative DNS from recursives to authorities is in
its early days, but it would not surprise me if similar requirements
show up there and require a new DNS record type.  (eg, an extensible
NS record or an extensible record named by an NS record that includes
information about protocols and ESNI keys and the like.)

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

[TLS] HTTPSSVC record draft - ESNI alternative for HTTPS

[Erik Nygren]

For those not on the HTTP-WG or DNSOP lists, Ben Mike and I have
a draft for an "HTTPSSVC" DNS record.  There's a -03 that incorporates
some feedback from the first version:

https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03

This attempts to address a number of problems (ESNI, QUIC bootstrapping,
HTTP-to-HTTPS redirection via DNS, SRV-equivalent for HTTP, etc) in a
holistic manner through a new extensible DNS record, rather than in a
piecemeal fashion.  It is based on some previous proposals such as "Alt-Svc
in the DNS" and "Service Bindings" but takes into account feedback received
in DNSOP and elsewhere.

In particular for the TLS WG, we'd be interested in hearing if this would
solve enough of the ESNI-key-delivery-via-DNS needs for the HTTPS use-case.

Feedback is most welcome and we're looking forward to discussing with
people in Montreal.

While this is still an individual draft, we have been tracking it here:
https://github.com/MikeBishop/dns-alt-svc
but as always, commentary on the IETF lists is generally preferable.
There is even a preliminary private type implementation in BIND
of the -01 version (with the -02 wire format supported by ifdefs)
from Mark Andrews:
https://gitlab.isc.org/isc-projects/bind9/merge_requests/2135

>From the abstract:

This document specifies an "HTTPSSVC" DNS resource record type to
facilitate the lookup of information needed to make connections for HTTPS
URIs.  The HTTPSSVC DNS RR mechanism allows an HTTPS origin hostname to be
served from multiple network services, each with associated parameters
(such as transport protocol and keying material for encrypting TLS SNI).
It also provides a solution for the inability of the DNS to allow a CNAME
to be placed at the apex of a domain name.  Finally, it provides a way to
indicate that the origin supports HTTPS without having to resort to
redirects, allowing clients to remove HTTP from the bootstrapping process.

By allowing this information to be bootstrapped in the DNS, it allows for
clients to learn of alternative services before their first contact with
the origin.  This arrangement offers potential benefits to both performance
and privacy.

This proposal is inspired by and based on recent DNS usage proposals such
as ALTSVC, ANAME, and ESNIKEYS (as well as long standing desires to have
SRV or a functional equivalent implemented for HTTP).  These proposals each
provide an important function but are potentially incompatible with each
other, such as when an origin is load-balanced across multiple hosting
providers (multi-CDN). Furthermore, these each add potential cases for
adding additional record lookups in-addition to /A lookups.  This
design attempts to provide a unified framework that encompasses the key
functionality of these proposals, as well as providing some extensibility
for addressing similar future challenges.

--

Some likely FAQs (with some others listed in an appendix):

Q: Why this is HTTP-specific?
A: This is because every protocol has different bootstrap requirements.
This draft is concerned with improving the efficiency and security of
bootstrapping HTTPS connections.  This proposal does offer room for
non-HTTPS protocols, but the nature of DNS requires underscore prefixing to
support protocol-keyed answers within a single RRTYPE.  It's also unlikely
that a single RR format would be the ideal bootstrap mechanism for every
protocol, and there's no reason that multiple protocols should have to
share an RRTYPE.

Q: Why is ESNI addressed directly?
A: This helps make a major motivation of this draft more clear.  Splitting
out those sections to a separate-but-associated "alt-svc attribute for ESNI
keys" draft might make sense, but keeping it here helps work through some
of the issues together.

Q: Why does this try to address the HSTS case?
A: This is a unique opportunity to fix HTTPS bootstrap and avoid providing
insecure defaults.  We'd originally proposed a separate Alt-Svc attribute
to indicate hsts-style behavior, but then realized that it would make sense
to push on that as the default here.

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

[TLS] More issues with current ESNIKEYS DNS approach

[Erik Nygren]

Following the discussion this week I realized some other major issues we'll
need to make sure we cover:

1) Handling proxies here is going to be tricky.  The CONNECT generally
needs to specify the hostname which needs to go to the server which has the
ESNI key for what gets sent in the TLS handshake.  IPs don't come into play
here at all.  The only thing I can think of for handling this is to pass
the canonical name to the CONNECT when using a proxy, and making sure that
the canonical name is specific to a CDN.   There may be some related issues
in non-proxy environments.

2) The extension model breaks down if not all CDNs send it as mandatory.
In the hallway, Chris suggested we could require at least one extension be
manditory in any ESNIKey record in DNS.  There could be a bunch of similar
corner cases.  This issue also applies to switching off of using ESNIKeys
(eg, if there had been no extension included).

3) Trusting A and  records from the EDNSKeys is going to break
environments relying on /etc/resolv.conf for spoofing to staging or other
testing environments.  (Services and Support staff will likely be unhappy
as they do this all the time.)

On Sat, Mar 9, 2019 at 9:08 PM Christopher Wood 
wrote:

> >> i'd also like to hear from CDNs about whether their address ranges
> >> are really small enough to not make the list of ranges prohobitive.
>

At least for one CDN, there are tens to hundreds of possible A/ records
that could be used in a given cluster, and then many thousands of
clusters.  Especially on IPv4 this space is not dense as some comes from
local provider space.  (The net result for each is far more IPv4 and IPv6
addresses than can be enumerated reasonably.)

Some additional minor issues we'll want to address or specify, regardless,
if we take this path:

* We'll want to make sure to specify that clients must round-robin or
permute the A and  records included in the address list.  Typically
most recursive and/or stub resolvers handle this, but since it's all in one
RR and not an RRSET it will be on clients to do this properly.

* We may wish to provide guidance on how to handle A vs  (eg, reference
RFC 8305).  One thing that clients may lose out on is support features
provided by the OS, such as those which sort results based on past
knowledge about RTT and the like.

I'm increasingly thinking that while we may wish to define a
general-purpose ESNIKEY record for use by generic applications, we may wish
to define application-protocol specific use-cases and bindings for some of
the most persnickety applications.  For example, an HTTP-specific "HTTPS"
record that combined ALTSVC, ESNIKEY, and "ANAME" style information may
solve a bunch of these issues together.  I've been talking to some folks
and am tempted to try writing up a draft on this.  (Mail might be another
case that will just want its own binding...)

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

Re: [TLS] Multi-CDN and ESNI

[Erik Nygren]

Another important scenario that is closely related to multi-cdn is how to
safely enable and disable ESNI, as well as how to handle cases where not
all CDNs in a multi-CDN setup have ESNI turned on.  As some examples:

* A site is using a CDN that has ESNI enabled.  As part of switching off of
that CDN to their own hosting provider or another CDN (which either has no
ESNI or has a different ESNI key) there is the same sort of inconsistency
in the records, or a missing record.

* A site is on a multi-CDN setup.  There is no way to get all CDNs to turn
on ESNI at the same time (or likely even within a reasonable time window,
and there may be cases where only some support it).

For example, with #3 one way to handle it would be to treat an NXDOMAIN for
the _esni ESNI record as a "disable sending ESNI in this case".

Some general commentary on some of the proposed options:

On #1) Experience with coordinating keys across providers suggests this
likely won't work.  (Plus will open up lots of security issues.)   The ESNI
DNS record, ESNI key, and ESNI server-side config likely need to be managed
by the same entity for any given case in order for this to be operationally
maintainable.

On #2) Given the number of addresses involved in some of these cases this
may not work or scale well.  In some cases the number of address candidates
may be more than possible in an rrset.  For CDNs that change their DNS
results frequently and have low TTLs, this is also likely to have a very
high rate of mismatches.

On #3) As Nick mentions this won't help with the address collapsing case.
It also needs a way to handle the offboarding situation described above.

I think there's also an option #4 that has a slightly higher integration
overhead for
sites but solves other problems as well.  If we take a step back, the issue
here is that
DNS is a database but any two given responses lack some sort of primary key
tying them
together.  One approach would be to introduce an intermediate record/object
that explicitly
does tie them together.  Two examples of this are the ALTSVC-in-DNS
proposal as well as
something like a "Service Binding" record (which I wrote up when we were
talking
about this back in 2014 following a brainstorm, in which case the"tlshp"
parameter
in that draft is effectively the ESNI key):
  https://www.ietf.org/archive/id/draft-nygren-service-bindings-00.txt

More recently with the ALTSVC DNS record, we'd add an ALTSVC attribute
that contains either the ESNI key or the name of the record containing the
ESNI key:
 https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02

One big advantage of using an ALTSVC record is that it also addresses the
"http-srv" problem.
(See a discussion thread titled "Alternative to SRV?" on the http-srv list
from back in August.)

Another big advantage of using an ALTSVC record approach here is that it
means
that ESNI could be generally configured by Alt-Svc as well.  For example,
this means that the ESNI key could also just be included when doing an
Alt-Svc to QUIC.

What this ends up looking like is something like is an rrset along the
lines of:

  _443._https.example.com. IN TYPE???  {priority1}
{transportprotocol1} {servername1} {port1} {extension_fieldset_1}

  _443._https.example.com. IN TYPE???  {priority2}
{transportprotocol2} {servername2} {port2} {extension_fieldset_2}

  _443._https.example.com. IN TYPE???  {priority3}
{transportprotocol3} {servername3} {port3} {extension_fieldset_3}


For example:

  _443._https.example.com. IN ALTSVC  10 quic2
example.com.examplecdn.net 443 ( esni=key124._esni.examplecdn.net )

  _443._https.example.com. IN ALTSVC  20 h2 example.com.examplecdn.net
443 ( esni=key124._esni.examplecdn.net; ipv6-only=true )

  _443._https.example.com. IN ALTSVC  40 http/1.1
legacy.example.com.examplecdn.net 443 (
esni=key124._esni.examplecdn.net )


I suspect that some CDNs would then have customers CNAME over "_443._
https.example.com."
to some name on the CDN.  For example in the example above it might be that
it actually
CNAMEs to _443._https.example.com.examplecdn.net which then means that the
A and  records for "example.com.examplecdn.net" can be returned as
additionals from the same examplecdn.net authority
along with the ALTSVC record.

So in the multi-CDN case, the multi-CDN switcher is switching on the CNAME
to the ALTSVC record,
allowing each CDN or hosting provider target to provide their own ALTSVC
record.
Tying this back up to the above the ALTSVC record then becomes this
intermediate object
that explicitly ties the server (A/ records) and ESNI key together.

One downside is that ALTSVC is primarily defined for HTTPS today,
but nothing prevents it from being more broadly used as an extensible
SRV alternative.

(Side-note: no matter what we'll also want to think and document
how ESNI and cross-hostname Alt-Svc interact.)

Erik



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

> Definitely agree this is something 

Re: [TLS] Closing on 0-RTT

[Erik Nygren]

On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla <e...@rtfm.com> wrote:

>
> On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <bka...@akamai.com> wrote:
>
>> On 06/29/2017 03:53 PM, Eric Rescorla wrote:
>>
>> I have updated the PR to match people's comments. I would like to merge
>> this soon, so please get any final comments in.
>>
>>
>> I made a couple comments on the PR that are more appropriate for the
>> list, so I'll repeat them here and hopefully get replies from the broader
>> audience.
>>
>>
>> First off, I think we should MUST-level require servers to implement a
>> hard limit on the number of replays accepted.  However, it doesn't quite
>> seem realistic to require "MUST use either [single-use tickets] or
>> [ClientHello recording]".  My preference would be "MUST use either
>> [single-use tickets], [ClientHello recording], or equivalently strong
>> protection", but I don't know what level of support we have for such a
>> strong requirement.  As an alternative, I will also put out "MUST limit
>> replays to at most the number of endpoints capable of accepting connections
>> for a given identity, and SHOULD provide even stronger replay protections,
>> such as [single-use tickets] or [ClientHello recording]."  I think we have
>> general agreement that strong anti-replay as described in the document is
>> feasible for a single-server deployment, and this last formulation is
>> achievable in multi-server environments by just giving each server its own
>> local per-server protection.  (My main reason for wanting a MUST-level hard
>> cap is that I worry that millions/billions of replays will have really
>> nasty consequences in terms of DoS and side channel issues.)
>>
>> But, this has been quite a long thread spread out over multiple
>> forums/email subjects, so I've also probably forgotten some of the
>> arguments presented against having MUST-level strong anti-replay
>> requirements; I'd greatly appreciate if someone could repeat them here for
>> everyone's consideration.
>>
>>
>> The pull request also has some text:
>>
>> +If the expected arrival time is in the window, then the server
>> +checks to see if it has recorded a matching ClientHello. It
>> +either aborts the handshake with an "illegal_parameter" alert
>> +or accepts the PSK but reject 0-RTT. If no matching ClientHello
>> +is found, then it accepts 0-RTT and then stores the ClientHello for
>> +as long as the expected_arrival_time is inside the window.
>> +Servers MAY also implement data stores with false positives, such as
>> +Bloom filters, in which case they MUST respond to apparent replay by
>> +rejecting 0-RTT but MUST NOT abort the handshake.
>>
>> I am not sure why we are giving servers a choice between aborting and
>> accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found),
>> especially not without giving guidance as to why they might choose one or
>> the other.  My natural inclination would be to have the expected behavior
>> be to abort and only fall back to the other behavior if using a scheme with
>> false positives, but Ekr thinks Erik Nygren was in support of just
>> continuing on with 1-RTT.  It looks like this was
>> https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 ,
>> where I ... took the opposite position from what I just said my "natural
>> inclination" was, amusingly enough.  But still, why does this need to be a
>> choice?  Rejecting 0-RTT and continuing on to 1-RTT seems like it would be
>> reasonable in all the cases mentioned so far.
>>
>
> Well, my reason for not wanting to do that is that it's a clear replay and
> so should
> be a hard failure. So, I'd be happy to mandate abort the handshake, but if
> we can't
> agree on that, I'd rather have a choice.
>

Are there scenarios where the duplication might be accidental rather than a
malicious attack?
For example, one might see cases where combining 0RTT with TFO and network
packet
duplication could result in two initial 0RTT flights.  One could also see
"TCP accelerator"
middleboxes doing similar things where the first flight gets replayed.

In both of these cases, only one will actually successfully establish a TLS
connection
and move forwards, but if the successful one is the one that is aborted
then
the connection will fail.  If 0RTT is rejected and both are allowed to
proceed,
then the bogus accidental replay will be dropped and the legit connection
will succeed.

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

Re: [TLS] Idempotency and the application developer

[Erik Nygren]

On Thu, May 4, 2017 at 8:18 PM, Watson Ladd  wrote:

> >
> > It should be up to servers whether a request is allowed with 0-rtt.
>
> Which server?  It's possible that the backhauls from the server the
> TLS connection is made to to the server actually responding to the
> request do not distinguish 0-RTT from other data. Opportunity for
> administrative bloopers is immense: even if the responding server
> rejects 0-RTT, the server proxying requests won't necessarily know
> that inline as it is reusing the connection.
>

+1

By the time the client has sent 0-RTT data the complexity mess
has already and it may be too late to avoid some of the potential
vulnerabilities.

Just as an example of a type of attack:  attacker replays 0-RTT messages.
If the server accepts some (sends larger responses) and rejects others
(sends smaller
responses) than that tells you something about the messages
and the attacker you can tell which client requests might have been
replay-safe
and which ones were not.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Erik Nygren]

On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla  wrote:

>
>
>
> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz  wrote:
>
>> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>> both session-cache and strike register styles and the merits of each.
>>
>>
>>
>> First, a point of clarification, I think two issues have been conflated
>> in this long thread:
>>
>> 1) Servers rejecting replayed 0-RTT data (using a single use session
>> cache/strike register/replay cache/some other method)
>>
>>
>>
>> There are definitely cases (i.e. application profiles) where this should
>> be done. I think a general case HTTPS server is one. But I don’t think this
>> is strictly necessary across the board (for every application using 0-RTT
>> at all). DNS was brought up earlier in this thread as an example of a
>> protocol that is likely quite workable without extra measures to prevent
>> replay.
>>
>>
>>
>> We already state “Protocols MUST NOT use 0-RTT data without a profile
>> that defines its use.”. We could also describe methods that may be used to
>> provide further replay protection. But I don’t think it’s appropriate to
>> make a blanket requirement that *all* application protocols should require
>> it.
>>
>>
>>
>> I also consider it quite misleading to say TLS 1.3 is insecure without
>> such a recommendation. Uses of TLS can be insecure, that does not mean the
>> protocol itself is. It’s insecure to use TLS without properly
>> authenticating the server. Some users of TLS do not do this correctly. I’d
>> actually argue that it is easier to mess this up than it is to mess up a
>> 0-RTT deployment (and it can result in worse consequences). That doesn’t
>> mean we should require a particular method of authentication, for all uses
>> of TLS.
>>
>
> I think this is basically right. In the PR I just posted, I spent most of
> my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
> I think there's a bunch of room to wordsmith the requirement. Perhaps we
> say:
>
> - You can't do 0-RTT without an application profile
> - Absent the application profile saying otherwise you SHOULD/MUST do one
> of these mitigations?
>

I generally agree with Kyle here (and also added a few minor comments to
the PR).
I think we should be clear where the responsibilities generally lie as
well, for example:

"The onus is on clients not to send messages in 0-RTT data which are not
safe to have replayed and which they would not be willing to retry across
multiple 1-RTT connections. The onus is on servers to protect themselves
against attacks employing 0-RTT data replication."

The server responsibility is a general property TLS can maintain while the
client responsibility requires an application profile to define.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Erik Nygren]

On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:

>
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> both session-cache and strike register styles and the merits of each.
>

I don't believe this is technically viable for the large-scale server
operators most interested in 0-RTT.  Having session ticket reuse across
clusters is a requirement for performance, especially in cases such as
moving load between clusters.  In the cross-cluster case, neither session
caches nor strike registers are possible in the time-frames that are
interesting and relevant to 0-RTT (as strong consistency between clusters
has inherent latency that isn't possible in the 0-RTT time-frames).

I fear having a "SHOULD" requirement here is one that will be widely
ignored.

Anything stateful here defeats the purpose of session tickets and is also
far too vulnerable to DDoS attacks to be useful, especially when trying to
scale up
to large clusters.

Many of the discussions I've been in seem to have concluded that we should
always be assuming that 0-RTT data can and will be replayed, and
applications
and application protocols need to design and use it carefully, accordingly.

Some of these mechanisms (timestamps, strike registers, etc)
are useful for servers protecting themselves from DDoS attacks
but aren't useful against an adversary trying to actively exploit replays.


4. I would add to this that we recommend that proxy/CDN implementations
> signal which data is 0-RTT and which is 1-RTT to the back-end (this was in
> Colm's original message).
>

I'm not entirely sure what back-ends are going to do here.  By the time
they gain visibility into this it is too late.

As some of us have been saying for awhile, we need to assume that 0-RTT
data is replayable and require application protocols and clients
implementing those protocols to define when and when it is not safe to
use.  For example, if exporters from 0RTT are not safe to use, we should
make that super-clear that this is not a safe use of 0RTT.

In the HTTP case, Patrick McManus has pointed out that many
application-layer clients will retry/replay non-idempotent POST operations
regardless even over 1RTT (and if the app doesn't, the user will just click
reload).  The best defense against these classes of issues is for
end-to-end application semantics rather than trying to provide properties
at the session  layer.

Erik




> On Tue, May 2, 2017 at 7:44 AM, Colm MacCárthaigh 
> wrote:
>
>> On Sunday at the TLS:DIV workshop I presented a summary of findings of a
>> security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n.
>> Thanks to feedback in the room I've now tightened up the findings from the
>> review and posted them as an issue on the draft GitHub repo:
>>
>> https://github.com/tlswg/tls13-spec/issues/1001
>>
>> I'll summarize the summary: Naturally the focus was on forward secrecy
>> and replay. On forward secrecy the main finding was that it's not necessary
>> to trade off Forward Secrecy and 0-RTT. A single-use session cache can
>> provide it, and with the modification that ekr has created in
>> https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for
>> both pre-auth and post-auth tickets, and it allows clients to build up
>> pools of meaningfully distinct tickets.
>>
>> There's also an observation there that it should really be that clients
>> "MUST" use tickets only once. Any re-use likely discloses the obfuscated
>> ticket age, which is intended to be secret. Right now it's a "SHOULD".
>>
>> On replay, the main finding is that what's in the draft is not workably
>> secure, and the review includes 5 different attacks against 0-RTT data to
>> illustrate that. Attacks 1 and 2 show that the kind of replay permitted by
>> the draft is very different from the kind of replay permitted by dkg's
>> existing downgrade-and-retry attack. I also go over why it very very
>> difficult to many applications to achieve that idempotency, and why one
>> idempotency pattern actually relies on non-replayable messages.
>>
>> Attack 3 shows that idempotency is not sufficient, applications must also
>> be free of measurable side-effects, which is not practical.  Attack 4 shows
>> that 0-RTT breaks a common security mechanism: spoofing-resistant
>> throttles. Attack 5 shows that 0-RTT replay-ability enables an additional
>> form of traffic analysis.
>>
>> The recommendation in the review is that implementations "MUST" prevent
>> replays of 0-RTT section, with some additional discussion about why the
>> existing advice is unlikely to be followed, and why consistent
>> interoperability matters here.
>>
>> Unfortunately, I wasn't aware until Friday that this review would be
>> coming so late in the TLD1.3 draft process, and my apologies for that. I am
>> now planning to attend the future WG in-person meetings and look forward to
>> seeing many of you there.
>>
>> --
>> Colm
>>
>> 

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

[Erik Nygren]

I also prefer TLS 4 but am fine with TLS 1.3

- Erik



On Nov 17, 2016 9:41 PM, "Yoav Nir"  wrote:

> Bleh. Can’t we get AOL to release the SSL trademark so that we can call it
> SSLv4?
>
> I hummed for TLS 4, so I’ll stay consistent: TLS 4.
>
> Yoav
>
> > On 18 Nov 2016, at 11:12, Sean Turner  wrote:
> >
> > At IETF 97, the chairs lead a discussion to resolve whether the WG
> should rebrand TLS1.3 to something else.  Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-
> 97-tls-rebranding-aka-pr612-01.pdf.
> >
> > The consensus in the room was to leave it as is, i.e., TLS1.3, and to
> not rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this
> decision on the list so please let the list know your top choice between:
> >
> > - Leave it TLS 1.3
> > - Rebrand TLS 2.0
> > - Rebrand TLS 2
> > - Rebrand TLS 4
> >
> > by 2 December 2016.
> >
> > Thanks,
> > J
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 -> TLS 2.0?

[Erik Nygren]

Is it worth having a poll (hate it, neutral, love it) on options to judge
preference
It seems like options are (I may have missed some):

- TLS 1.3  (ie, the default if we do nothing)
- TLS 2.0
- TLS 2
- TLS/2
- TLS 4.0
- TLS/4
- TLS 4
- TLS 34

On the topic of "what does this re-open", I'm not convinced it does.
The concept of doing a rename shortly before the last call goes way back
and has been correctly deferred as bike-shedding until now.
What color do we want our bike shed?

  Erik



On Wed, Aug 31, 2016 at 6:35 PM, Nick Sullivan 
wrote:

> I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a
> few immediate issues with the proposal:
> - it causes confusion with SSL 2.0
> - it implies wire incompatibility with TLS 1.2
> - it suggests there will be a forthcoming TLS 2.1 with only minor changes
>
> If we're dead set on bumping the major version for a mostly backwards
> compatible protocol change, we should just drop the minor version and go
> with TLS/2.
>
> Nick
>
> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz 
> wrote:
>
>> We could call it TLS 3.4 which would match the internal ID. :-)
>>
>> BTW, I think using something other than 1.3 is a good idea.
>>
>> Cheers - Bill
>>
>> -
>> Bill Frantz| When it comes to the world | Periwinkle
>> (408)356-8506  | around us, is there any choice | 16345 Englewood Ave
>> www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 -> TLS 2.0?

[Erik Nygren]

I'm also very supportive for the reasons you outline.

However, I think we should consider calling it TLS 4 or TLS 4.0 or TLS 5.

In particular, much of the non-technical audience still calls it "SSL" (pet
peeve of many of us, I suspect) and having a version number clearly greater
than SSLv3 and not confusing with SSLv2 would be quite valuable.  "TLS 2"
may have risk for unfortunate confusions with SSLv2 and SSLv3.

Another reason to avoid 1.3 is Western culture negative connotations around
"tls13" which TLS 1.3 will get abbreviated as.

- Erik

 [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]

On Aug 30, 2016 3:35 PM, "Dave Garrett"  wrote:

> On Tuesday, August 30, 2016 02:36:51 pm Xiaoyin Liu wrote:
> > I support this change as long as there is no technical change (version
> ID remains 0x0304).
>
> To reiterate, I am also against changing the version ID. However, I do
> think it's worth updating the context string version number, otherwise it'd
> be a little unnecessarily confusing there. (trivial change to key
> derivation, but not wire format) I've also made a point to tweak references
> to the on-the-wire version value to refer to it as a "version ID" rather
> than just version, to make it very clear that this is really just an
> arbitrary codepoint and shouldn't be read as 3.4.
>
> I've made the changes for a WIP branch, here (not a PR, as of yet):
> https://github.com/tlswg/tls13-spec/compare/master...
> davegarrett:tls2rebranding
>
> Going through the motions of doing the renaming now is useful to see if
> there's anything that is more affected than initially expected, such as the
> context strings having the version in there directly as a string (they're
> designed to be updated as-needed, so this shouldn't be a problem).
>
>
> Dave
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS client puzzles

[Erik Nygren]

This is also what is still proposed in the -01 version at the top of this
thread:

https://tools.ietf.org/html/draft-nygren-tls-client-puzzles-01

By leveraging the HelloRetryRequest in TLS 1.3, it provides client puzzles
as an extension mechanism to TLS without requiring changes to the state
machine
or protocol itself.  (Clients indicate support via an extension, and then
puzzles
are challenged with a HelloRetryRequest extension, and then the ClientHello
retry
contains the updated extension.)

Note that the -01 version still needs some updates to match up to more
recent TLS 1.3 drafts.  (Some of the specifics may be a little out-of-date
and will be updated in the next revision.)

  Erik



On Thu, Jul 7, 2016 at 5:36 PM, Kyle Rose <kr...@krose.org> wrote:

>
> I agree, and I think it is clear that client puzzles can be a useful
>> addition to the DDoS defense toolbox.  However, most of this can be handled
>> at the higher levels above TLS, or possibly as a custom extension that does
>> not complicate TLS.
>>
>
> A custom extension is a promising approach: this is what Erik Nygren
> proposed in nygren-tls-client-puzzles-00 following discussions with some
> IETF folks and Akamai colleagues. That draft has expired and doesn't
> reference any of the recent work on memory-hard puzzles, but it might be a
> good starting point.
>
> Except at the pre-TLS stage for applications that use STARTTLS-style
> mechanisms, I'm not sure how this could work at levels above TLS: the
> primary attack targeted by client puzzles would be a client doing almost no
> work in order to force the server to do expensive crypto, which means it
> must be engaged prior to the handshake.
>
> Kyle
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Simpler backward compatibility rules for 0-RTT

[Erik Nygren]

There are also very common cases of using multiple CDNs or server farms
with different capabilities but with the same host name, or of switching a
live site between platforms. As others have mentioned, the behaviors need
to be well defined and result in extra rtt rather than hard failure to
allow 0rtt to be safely deployable.

- Erik
On Jun 22, 2016 5:58 AM, "Martin Thomson"  wrote:

On 22 June 2016 at 12:01, Watson Ladd  wrote:
> Why isn't 0-RTT an extension in the Client Hello to deal with this?

You can't stream extensions, which unfortunately is required given how
most software interacts with their TLS stack.

Let's be clear, the actual risk we're talking about is pretty-much
confined to screw-ups.  The deployment screwup where you left one
server speaking TLS 1.2 somewhere before turning 0-RTT on; and TLS
MitM, which calling a screw-up might be too positive a statement.

Of course, David is right that screw-ups like this are too common for
us to do nothing about them.

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

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Erik Nygren]

On Sun, Mar 13, 2016 at 12:21 PM, Eric Rescorla  wrote:

>
> On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir  wrote:
>
>>
>> > On 13 Mar 2016, at 4:45 PM, Salz, Rich  wrote:
>> >
>> >> I also think it is prudent to assume that implementers will turn on
>> replayable
>> >> data even if nobody has figured out the consequences.
>> >
>> > I very much agree.  Customers, particularly those in the mobile field,
>> will look at this and say "I can avoid an extra RTT?  *TURN IT ON*" without
>> fully understanding, or perhaps even really caring about, the security
>> implications.
>>
>> Perhaps, and I think IoT devices are likely to do so as well.
>>
>> Is OpenSSL going to implement this? Are all the browsers?
>>
>
> There are already patches in preparation for this for NSS and I expect
> Firefox to
> implement it, as long as we have any indication that a reasonable numbers
> of
> servers will accept it.
>

I share some of the concerns expressed in this thread that 0RTT has the
risk of becoming an attractive nuisance.  Once browsers start supporting
it, server operators will feel competitive pressure to support it.  And
this will then put additional pressure onto more browsers to support it,
possibly pushing the edges where it is safe.

For example, when is HTTP GET safe vs not safe and who makes this call?
Especially if you have a browser that assumes that GET should be idempotent
and can be sent via 0RTT early data, a web developer whose never heard of
the word "idempotent" and builds an app with GET with side-effects but
assumes its safe since it's over TLS, and a server operator who is just
turning on a vendor provided feature which their users requested, not to
mention perhaps having a CDN or load-balancing-tls-terminating-proxy that
doesn't have a good way to convey the risks across two connections.  One
idea for HTTP that I'm increasingly in-favor of might be to define a new
method ("GET0"?)  and require that browsers use one of these new methods in
the early data request to expose this as high in the stack as possible.

It seems like there is a level of diminishing returns here if we compare
some of the options (not meant to be strictly ordered below):

1) We have old-school cleartext over TCP which has 1RTT before client data
(due to SYN/SYNACK)
2) We have TCP + TLS 1.[012] which has both the SYN/SYNACK plus the 2RTT
behavior means 3RTT before client data.
3) We have TCP TFO + TLS 1.3 1RTT which yields 1RTT before client data  (or
back to the same as #1 for resumption)
4) We have TCP (no TFO) + TLS 1.3 0RTT which also yields 1RTT before client
data for resumption
5) Then there's TCP TFO + TLS 1.3 0RTT which yields 0RTT before client data
for resumption
6) And finally there's old-school cleartext TCP TFO which has 0RTT before
client data, but which people are very hesitant to use for HTTP due to
replay issues.

Of these, #3 and #4 yield similar performance (with some limitations around
#3, such as requiring the same server IP or server IP prefix in some newer
drafts).

>From this, a few thoughts jump to mind from this:

* We get many of the same benefits 0RTT with using TCP TFO (TCP FastOpen)
and TLS 1.3 1RTT mode together as we get when using TLS 1.3 0RTT and stock
TCP.  TFO seems much safer here since its replay risks are at a lower level
that should be safe for TLS outside of the 0RTT context.  Note that there
are some issues with middleboxes sometimes breaking badly (blocking all
connections from a client IP for 30 seconds) when it tries to use TFO as
discussed recently in TCPM, but we may all want to focus some effort on
getting those fixed.
* We'll almost certainly want to make sure that any UDP-based protocol
(DTLS 1.3 or QUIC-over-TLS-1.3) can do a true 1RTT handshake safely in a
common case.  (ie, in a way that mirrors TCP TFO + TLS 1.3 1RTT.)  I
suspect this will be the bare minimum for getting QUIC to switch to use TLS
1.3.
* It seems like the risks around TLS 1.3 0RTT and TFO are similar (with TCP
being a protocol not trying to provide security properties).  If people
have been very wary to enable TFO for cleartext HTTP due to risks from
duplicated packets, shouldn't we be even more worried about TLS 1.3 0RTT
since the next-layer-up semantic issues and risks are similar, but TLS 1.3
0RTT potentially even has fewer mitigators?  (eg, we don't bind the server
IP in cryptographically to the request the client is making --- although
that might be an interesting addition to help make TLS 1.3 0RTT safer?)


There may also be some hacks that make TLS 1.3 0RTT marginally safer,
although I'm sure there are situations where they don't work and they may
just provide a false sense of security:
* Have the client include a time-delta-relative-to-PSK-issuance, as Martin
suggested.  (To allow the server to bound the duration of replay attacks.)
* Include the server IP in the client_hello for 0RTT  (to prevent replays
against different clusters).  There are a bunch 

Re: [TLS] Limiting replay time frame of 0-RTT data

[Erik Nygren]

That does seem like a good idea to include a client time stamp in the 0RTT
flow to let the server force 1RTT in the case where this is too far off as
this bounds the duration of the replay window.  (I suspect we'll find a
whole range of other similar attacks using 0RTT.)  An encrypted client
timestamp could presumably be probed by the server.  (ie, if the server
response is a different size for timestamp-expired vs timestamp-not-expired
an attacker could keep probing until they change?)  That does seem like
more effort, however.

   Erik


On Sat, Mar 12, 2016 at 7:56 AM, Eric Rescorla  wrote:

> Hi Kyle,
>
> Clever attack. I don't think it would be unreasonable to put a low
> granularity time stamp in the
> ClientHello (and as you observe, if we just define it it can be done
> backward compatibly)
> or as you suggest, in an encrypted block. With that said, though couldn't
> you
> also just include the information in the HTTP header for HTTP? Do you
> think this is a sufficiently
> general issue that it merits a change to TLS.
>
> -Ekr
>
>
> On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz  wrote:
>
>> Similar to the earlier discussion on 0.5-RTT data, I’m concerned with the
>> long term ability to replay captured 0-RTT early data, and the attack
>> vectors that it opens up. For example, take a GET request for an image to a
>> CDN. This is a request that seems completely idempotent, and that
>> applications will surely want to send as 0-RTT data. However, this request
>> can result in a few things happening:
>> 1) Resource unavailable
>> 2) Resource cached locally at edge cluster
>> 3) Cache miss, resource must be fetched from origin data center
>> #1 can easily be differentiated by the length of the 0.5-RTT response
>> data, allowing an attacker to determine when a resource has been
>> deleted/modified. #2 and #3 can also be easily differentiated by the timing
>> of the response. This opens up the following attack: if an attacker knows a
>> client has requested a resource X_i in the attacker-known set {X_1, X_2,
>> ..., X_n}, an attacker can do the following:
>> 1) wait for the CDN cache to be evicted
>> 2) request {X_1, X_2, …, X_(n/2)} to warm the cache
>> 3) replay the captured client early data (the request for X_i)
>> 4) determine, based on the timing of the response, whether it
>> resulted in a cache hit or miss
>> 5) repeat with set {X_1, X_2, …, X_(n/2)} or {X_(n/2 + 1), X_(n/2 +
>> 2), …, X_n} depending on the result
>> This particular binary search example is a little contrived and requires
>> that no-one else is requesting any resource in the set, however I think it
>> is representative of a significant new attack vector that allowing
>> long-term replay of captured early data will open up, even if 0-RTT is only
>> used for seemingly simple requests without TLS client authentication. This
>> is a much different threat than very short-term replay, which is already
>> somewhat possible on any TLS protocol if clients retry failed requests.
>>
>> Given this, I think it is worth attempting to limit the time frame that
>> captured early data is useful to an attacker. This obviously doesn’t
>> prevent replay, but it can mitigate a lot of attacks that long-term replay
>> would open up. This can be done by including a client time stamp along with
>> early data, so that servers can choose to either ignore the early data, or
>> to delay the 0.5-RTT response to 1.5-RTT if the time stamp is far off. This
>> cuts down the time from days (until the server config/session ticket key is
>> rotated) to minutes or seconds.
>>
>> Including the client time also makes a client random strike register
>> possible without requiring an unreasonably large amount of server-side
>> state.
>>
>> I am aware that client time had previously been removed from the client
>> random, primarily due to fingerprinting concerns, however these concerns
>> can be mitigated by
>> 1) clients can choose to not include their time (or to include a random
>> time), with only the risk of their .5-RTT data being delayed
>> 2) placing the time stamp in an encrypted extension, so that it is not
>> visible to eavesdroppers
>>
>>
>> Note: it’s also useful for the server to know which edge cluster the
>> early data was intended for, however this is already possible in the
>> current draft. In ECDHE 0-RTT server configs can be segmented by cluster,
>> and with tickets, the server can store cluster information in the opaque
>> ticket.
>>
>> ___
>> 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