[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 to /A lookups.  This design attempts
   to provide a unified framework that encompasses the key function

Re: [TLS] Selfie attack was Re: Distinguishing between external/resumption PSKs

[Hao, Feng]

On 23/09/2019, 18:50, "TLS on behalf of Mohit Sethi M"  wrote:

Hi all,

On the topic of external PSKs in TLS 1.3, I found a publication on the 
Selfie attack: https://eprint.iacr.org/2019/347

Perhaps this was already discussed on the list. I thought that sharing 
it again wouldn't hurt while we discuss how servers distinguish between 
external and resumption PSKs.

I just read the paper with interest. It occurs to me that the selfie attack is 
consistent with the "impersonation attack" that we reported on SPEKE in 2014; 
see Sec 4.1 [1] and the updated version with details on how SPEKE is revised in 
ISO/IEC 11770-4 [2]. The same attack can be traced back to 2010 in [3] where a 
"worm-hole attack" (Fig. 5, [3]) is reported on the self-communication mode of 
HMQV. The essence of these attacks is the same: Bob tricks Alice into thinking 
that she is talking to authenticated Bob, but she is actually talking to 
herself. In [3], we explained that the attack was missed from the "security 
proofs" as the proofs didn't consider multiple sessions. 

The countermeasure we proposed in [1-3] was to ensure the user identity is 
unique in key exchange processes: in case of multiple sessions that may cause 
confusion in the user identity, an extension should be added to the user 
identity to distinguish the instances. The underlying intuition is that one 
should know "unambiguously" whom they are communicating with, and perform 
authentication based on that. The discovery of this type of attacks and the 
proposed solution are inspired by the "explicitness principle" (Ross Anderson 
and Roger Needham, Crypto'95), which states the importance of being explicit on 
user identities and other attributes in a public key protocol; also see [3]. I 
hope it might be useful to people who work on TLS PSK.

[1] https://eprint.iacr.org/2014/585.pdf
[2] https://arxiv.org/abs/1802.04900
[3] https://eprint.iacr.org/2010/136.pdf 


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

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

[Salz, Rich]

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

I am strongly opposed to two ways of doing the same thing.  I will be taking a 
close look at this, but I hope that the folks heavily involved with ESNI see 
what changes, if any, need to be made to use this.


  *   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

  *   URL:
https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt

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

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

[Stephen Farrell]

Hi Erik,

FWIW, if browsers preferred this to an ESNI RR and
we could forget the ESNI RR then I'd be ok with that.
I'm not clear if they do or not though. In the meantime,
assuming this went ahead instead of or in addition
to an ESNI RR, I've a few questions below...

On 24/09/2019 14:21, Erik Nygren wrote:
> Following the discussions in Montreal (as well as with some of the ESNI
> authors),
> we refactored the HTTPSSVC draft to make it more general.  The hope is that
> it could be an alternative (or replace the need) for a distinct ESNI record.

So I think the basic ESNI case where there's no
name changes nor alt-svc etc would be as below in
presentation syntax, am I reading that right?

   example.com. 7200  IN HTTPSSVC 0 . ( esnikeys="/wHrAh..." )

I'm also not clear if that's the exact same as:

   example.com. 7200  IN SVCB 0 . ( esnikeys="/wHrAh..." )

...is it? If so, which'd be preferred or would
clients be expected to be able to handle both?
And I don't get why two ways to say the same thing
are useful.

Secondly, ESNIKeys currently supports versions,
multiple keys, cipher_suites, extensions and even
dns_extensions. And we could have >1 rrdata for
ESNI or for SCVB/HTTPSSVC.

Would you envisage adoption of SVCB/HTTPSSVC meaning
that we could drop some of the generality that's
present in ESNIKeys? If so, what?

I'd like if ESNIKeys were made simpler FWIW, so if
this had that effect, then I'd be more for it. If,
OTOH, this just added complexity (for a library
implementing ESNI), which currently seems to be the
case, then it'd be less attractive, to me at least.
(I guess I'm agreeing with Rich there:-)

Thanks,
S.


> The draft generalizes to a protocol-agnostic SVCB record, but also specifies
> an HTTPSSVC record for the HTTP(S) use-case.
> 
> Based on discussions with various chairs, the plan is to call for adoption
> in the DNSOP WG.
> 
> Comments/feedback are most welcome.
> 
>   Erik
> 
> 
> -- Forwarded message -
> From: Erik Nygren 
> Date: Tue, Sep 24, 2019 at 9:17 AM
> Subject: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
> To: dnsop WG , Ben Schwartz , Mike
> Bishop 
> 
> 
> Following discussions around the "HTTPSSVC" record proposal in Montreal
> with the DNSOP, HTTP and TLS WGs, we've updated what was previously
> "draft-nygren-httpbis-httpssvc-03".  The new version is
> "draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the
> feedback from the WG discussions, as well as feedback from discussions with
> the TLS WG (as we'd like to see this replace the need for a separate ESNI
> record).
> 
> In particular, it generalizes the record into a new "SVCB" record which
> doesn't have any protocol-specific semantics.  It also defines an
> "HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and
> parameter registry) and which defines the HTTP(S)-specific semantics such
> as bindings to Alt-Svc.  Other protocols can either define bindings
> directly to SVCB or can define their own RR Type (which should only ever be
> needed if there is a need to use the record at a zone apex).
> 
> We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs
> can go against:  https://github.com/MikeBishop/dns-alt-svc
> 
> Major changes from "draft-nygren-httpbis-httpssvc-03" include:
> 
> * Separation into the SVCB and HTTPSSVC RR Types  (and separated all of the
> HTTPS-specific functionality and text to its own portion of the document).
> * Elimination of the SvcRecordType field (and making the SvcRecordType
> implicit)
> * Changing the wire format of parameters from being in Alt-Svc text format
> to a more general binary key/value pair format (with a mapping to Alt-Svc
> for HTTPSSVC).
> * Adding optional "ipv4hint" and "ipv6hint" parameters.
> * Quite a few cleanups and clarifications based on input (and we
> undoubtedly have more left to go)
> 
> This retains support for all of the use-cases that the previous HTTPSSVC
> record had (such as for covering the ANAME / CNAME-at-the-zone-apex
> use-case).
> 
> Feedback is most welcome.  If the TLS WG is going to use this instead of a
> separate ESNI 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:/

Re: [TLS] Selfie attack was Re: Distinguishing between external/resumption PSKs

[John Mattsson]

Hi,

I think these reflection attacks are much older than this. I quick search for 
reflection attack security protocol gives a lot of old results, The description 
of reflection attack in the following lecture material from 2009 looks just 
like the "selfie attack" on TLS 1.3
http://www.cs.bham.ac.uk/~tpc/cwi/Teaching/Files/Lecture4_6up.pdf

With multiple sections there are other things that change as well. If two nodes 
unintentionally initiate simultaneous ClientHello to each other, even if they 
only want a single secure connection (I have seen live systems where this 
happens in practice), an attacker can select which ClientHello to block (e.g. 
the one with the strongest cryptographic parameters). The following security 
property would then no longer hold :

  "Downgrade protection:  The cryptographic parameters should be the
  same on both sides and should be the same as if the peers had been
  communicating in the absence of an attack"

(I have not looked at what the definitions in [BBFGKZ16] say).

Cheers,
John

-Original Message-
From: TLS  on behalf of "Hao, Feng" 

Date: Tuesday, 24 September 2019 at 16:09
To: Mohit Sethi M , "Owen Friel 
(ofriel)" , Jonathan Hoyland 
Cc: "TLS@ietf.org" 
Subject: Re: [TLS] Selfie attack was Re: Distinguishing between 
external/resumption PSKs


On 23/09/2019, 18:50, "TLS on behalf of Mohit Sethi M" 
 
wrote:

Hi all,

On the topic of external PSKs in TLS 1.3, I found a publication on the 
Selfie attack: 
https://protect2.fireeye.com/url?k=dd432f13-81c9e5ad-dd436f88-869a17b5b21b-dc6c6f0a5dd21faf&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2019%2F347

Perhaps this was already discussed on the list. I thought that sharing 
it again wouldn't hurt while we discuss how servers distinguish between 
external and resumption PSKs.

I just read the paper with interest. It occurs to me that the selfie attack 
is consistent with the "impersonation attack" that we reported on SPEKE in 
2014; see Sec 4.1 [1] and the updated version with details on how SPEKE is 
revised in ISO/IEC 11770-4 [2]. The same attack can be traced back to 2010 in 
[3] where a "worm-hole attack" (Fig. 5, [3]) is reported on the 
self-communication mode of HMQV. The essence of these attacks is the same: Bob 
tricks Alice into thinking that she is talking to authenticated Bob, but she is 
actually talking to herself. In [3], we explained that the attack was missed 
from the "security proofs" as the proofs didn't consider multiple sessions. 

The countermeasure we proposed in [1-3] was to ensure the user identity is 
unique in key exchange processes: in case of multiple sessions that may cause 
confusion in the user identity, an extension should be added to the user 
identity to distinguish the instances. The underlying intuition is that one 
should know "unambiguously" whom they are communicating with, and perform 
authentication based on that. The discovery of this type of attacks and the 
proposed solution are inspired by the "explicitness principle" (Ross Anderson 
and Roger Needham, Crypto'95), which states the importance of being explicit on 
user identities and other attributes in a public key protocol; also see [3]. I 
hope it might be useful to people who work on TLS PSK.

[1] 
https://protect2.fireeye.com/url?k=5a822513-0608efad-5a826588-869a17b5b21b-eb260151f78b0718&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2014%2F585.pdf
[2] https://arxiv.org/abs/1802.04900
[3] 
https://protect2.fireeye.com/url?k=d5bf88ff-89354241-d5bfc864-869a17b5b21b-0e9b3bf58e104f32&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2010%2F136.pdf
 


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


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

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

[Ilari Liusvaara]

On Tue, Sep 24, 2019 at 09:21:25AM -0400, Erik Nygren wrote:
> Following the discussions in Montreal (as well as with some of the ESNI
> authors),
> we refactored the HTTPSSVC draft to make it more general.  The hope is that
> it could be an alternative (or replace the need) for a distinct ESNI record.
> 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.
> 
> 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 
> 
> Name:   draft-nygren-dnsop-svcb-httpssvc
> Revision:   00
> Title:  Service binding and parameter specification via the DNS
> (DNS SVCB and HTTPSSVC)

Couple comments:

- Is there need for two resource records? It seems like the two uses
  could be distinguished by starting point.
- What about starting point of protocols that have defined name for
  SRV records? That thing is of form _foo._tcp.domain.example
  (or _foo.udp.domain.example).
- One possible use for AliasForm with '.' would be to signal that
  this service does not exist (IIRC, some other rrtype had special
  "this does not exist" value).
- It seems like ALPN and port are fundamential and would be better
  being their own fields, instead of attributes.
- This could be defined to carry out TLS upgrade for any protocol
  that uses it. However, one would need to allow ALPN to override the
  behavior (e.g., HTTP/3 needs to change transport from TCP to UDP).
- To me, ipv4hint/ipv6hint seem very bad ideas, as they break
  normalization and ownership, drastically increasing odds for errors.
- I would not speculate about records for DNS authorities looking
  anything like this. That RRtype will be very special snowflake.


-Ilari

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

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

[Tommy Pauly]

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

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

Thanks,
Tommy

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

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

[Stephen Farrell]

Thanks Ben, bit more below...

On 24/09/2019 16:15, Ben Schwartz wrote:
>> So I think the basic ESNI case where there's no
>> name changes nor alt-svc etc would be as below in
>> presentation syntax, am I reading that right?
>>
>>example.com. 7200  IN HTTPSSVC 0 . ( esnikeys="/wHrAh..." )
>>
> 
> For HTTPSSVC, the "alpn" parameter is mandatory (Section 7.2), so the
> minimal record is
> 
> example.com. 7200  IN HTTPSSVC 0 . alpn=h2 esnikeys="/wHrAh..."
> 
> I'm also not clear if that's the exact same as:
>>
>>example.com. 7200  IN SVCB 0 . ( esnikeys="/wHrAh..." )
>>
>> ...is it? If so, which'd be preferred or would
>> clients be expected to be able to handle both?
>> And I don't get why two ways to say the same thing
>> are useful.
>>
> 
> SVCB records are always on underscore-prefixed names, and are prohibited
> for HTTP or HTTPS. 

Thanks. I must've missed that in reading. Might be
worth saying that more explicitly and maybe giving
such examples.


> Secondly, ESNIKeys currently supports versions,
>> multiple keys, cipher_suites, extensions and even
>> dns_extensions. And we could have >1 rrdata for
>> ESNI or for SCVB/HTTPSSVC.
>>
>> Would you envisage adoption of SVCB/HTTPSSVC meaning
>> that we could drop some of the generality that's
>> present in ESNIKeys? If so, what?
>>
> 
> The dns_extensions field is in ESNIRecord, not ESNIKeys, 

Sorry, you're right.

> so that is
> excluded.  I wasn't expecting to remove any of the other fields.

Pity;-) In any case, that means that there could still
be scenarios where we have something like:

 example.com. 7200  IN HTTPSSVC 0 . alpn=h2 esnikeys="/wHrAh..."
 example.com. 7200  IN HTTPSSVC 0 . alpn=h2 esnikeys="/wHEdf..."

That could be because of variations within the ESNIKeys
structure (e.g. version, or extensions, or differing
groups or whatever). I'm not sure that randomly picking
one of those is going to work, e.g. if a library doesn't
support all the versions a server supports then the
https client would have to cycle through 'em or something
which seems a bit ickky.

> 
> I'd like if ESNIKeys were made simpler FWIW, so if
>> this had that effect, then I'd be more for it. If,
>> OTOH, this just added complexity (for a library
>> implementing ESNI), which currently seems to be the
>> case, then it'd be less attractive, to me at least.
>> (I guess I'm agreeing with Rich there:-)
>>
> 
> I imagine a TLS library implementation of ESNI taking an IP address, an
> SNI, and an ESNIKeys struct, as input to connection initiation.  In that
> model, the choice of DNS representation has no effect on the library.

Not quite though. If there's anything inside ESNIKeys that
the application may need to know about, or if the API needs
to support >1 input ESNIKeys, I'd say it gets messier.

If we didn't end up needing the ESNI RR at all, I wonder if
it'd be better to move the versioning out of ESNIKeys entirely
(i.e. have the SvcParamKey be something like "esnikeys05" for
the next ESNI draft and finalise that when ESNI is done) and
maybe also radically simplify ESNIKeys as much as can be done.

> 
> An HTTP client [library] that is using such a TLS library would be
> responsible for performing the requisite DNS resolution.  This is indeed
> more complex than the proposed ESNI RR type, but I believe it's a more
> logically sound match for the HTTP origin model, and offers several
> concrete benefits (such as triggering HTTP->HTTPS upgrade).

Possibly so. I'll be interested when folks who implement
browsers and HTTP libraries say what they think.

Cheers,
S.


> 
> 
>> Thanks,
>> S.
>>
>>
>>> The draft generalizes to a protocol-agnostic SVCB record, but also
>> specifies
>>> an HTTPSSVC record for the HTTP(S) use-case.
>>>
>>> Based on discussions with various chairs, the plan is to call for
>> adoption
>>> in the DNSOP WG.
>>>
>>> Comments/feedback are most welcome.
>>>
>>>   Erik
>>>
>>>
>>> -- Forwarded message -
>>> From: Erik Nygren 
>>> Date: Tue, Sep 24, 2019 at 9:17 AM
>>> Subject: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
>>> To: dnsop WG , Ben Schwartz , Mike
>>> Bishop 
>>>
>>>
>>> Following discussions around the "HTTPSSVC" record proposal in Montreal
>>> with the DNSOP, HTTP and TLS WGs, we've updated what was previously
>>> "draft-nygren-httpbis-httpssvc-03".  The new version is
>>> "draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the
>>> feedback from the WG discussions, as well as feedback from discussions
>> with
>>> the TLS WG (as we'd like to see this replace the need for a separate ESNI
>>> record).
>>>
>>> In particular, it generalizes the record into a new "SVCB" record which
>>> doesn't have any protocol-specific semantics.  It also defines an
>>> "HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and
>>> parameter registry) and which defines the HTTP(S)-specific semantics such
>>> as bindings to Alt-Svc.  Other protocols can either define bindings
>>> directly to SV

Re: [TLS] Selfie attack was Re: Distinguishing between external/resumption PSKs

[Viktor Dukhovni]

> On Sep 23, 2019, at 1:49 PM, Mohit Sethi M 
>  wrote:
> 
> Hi all,
> 
> On the topic of external PSKs in TLS 1.3, I found a publication on the 
> Selfie attack: https://eprint.iacr.org/2019/347

If I not missing something, eeels like simple misconfiguration.
How is this different from, say, using the same wildcard certificate
on both nodes?

-- 
Viktor.

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

Re: [TLS] Selfie attack was Re: Distinguishing between external/resumption PSKs

[Hao, Feng]

Hi John,

Reflection attacks are indeed older, but the selfie attack is a bit different. 
It's actually a variant of the unknown key share attack. A typical example of 
the UKS attack is the one reported on MQV by Kaliski in 2001 (see "An unknown 
key-share attack on the MQV key agreement protocol" in ACM TISSEC 2001). In 
that example, the adversary plays message between two users to cause confusion 
in the identity, but in Selfie, the adversary plays message with only one user 
and uses another instance of the user to cause confusion in the identity. When 
we reported this variant of UKS in [3], we were not aware of anything like that 
in the literature.

Cheers,
Feng

On 24/09/2019, 16:17, "John Mattsson"  wrote:

Hi,

I think these reflection attacks are much older than this. I quick search 
for reflection attack security protocol gives a lot of old results, The 
description of reflection attack in the following lecture material from 2009 
looks just like the "selfie attack" on TLS 1.3
http://www.cs.bham.ac.uk/~tpc/cwi/Teaching/Files/Lecture4_6up.pdf

With multiple sections there are other things that change as well. If two 
nodes unintentionally initiate simultaneous ClientHello to each other, even if 
they only want a single secure connection (I have seen live systems where this 
happens in practice), an attacker can select which ClientHello to block (e.g. 
the one with the strongest cryptographic parameters). The following security 
property would then no longer hold :

  "Downgrade protection:  The cryptographic parameters should be the
  same on both sides and should be the same as if the peers had been
  communicating in the absence of an attack"

(I have not looked at what the definitions in [BBFGKZ16] say).

Cheers,
John

-Original Message-
From: TLS  on behalf of "Hao, Feng" 

Date: Tuesday, 24 September 2019 at 16:09
To: Mohit Sethi M , "Owen 
Friel (ofriel)" , Jonathan Hoyland 

Cc: "TLS@ietf.org" 
Subject: Re: [TLS] Selfie attack was Re: Distinguishing between 
external/resumption PSKs


On 23/09/2019, 18:50, "TLS on behalf of Mohit Sethi M" 
 
wrote:

Hi all,

On the topic of external PSKs in TLS 1.3, I found a publication on 
the 
Selfie attack: 
https://protect2.fireeye.com/url?k=dd432f13-81c9e5ad-dd436f88-869a17b5b21b-dc6c6f0a5dd21faf&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2019%2F347

Perhaps this was already discussed on the list. I thought that 
sharing 
it again wouldn't hurt while we discuss how servers distinguish 
between 
external and resumption PSKs.

I just read the paper with interest. It occurs to me that the selfie 
attack is consistent with the "impersonation attack" that we reported on SPEKE 
in 2014; see Sec 4.1 [1] and the updated version with details on how SPEKE is 
revised in ISO/IEC 11770-4 [2]. The same attack can be traced back to 2010 in 
[3] where a "worm-hole attack" (Fig. 5, [3]) is reported on the 
self-communication mode of HMQV. The essence of these attacks is the same: Bob 
tricks Alice into thinking that she is talking to authenticated Bob, but she is 
actually talking to herself. In [3], we explained that the attack was missed 
from the "security proofs" as the proofs didn't consider multiple sessions. 

The countermeasure we proposed in [1-3] was to ensure the user identity 
is unique in key exchange processes: in case of multiple sessions that may 
cause confusion in the user identity, an extension should be added to the user 
identity to distinguish the instances. The underlying intuition is that one 
should know "unambiguously" whom they are communicating with, and perform 
authentication based on that. The discovery of this type of attacks and the 
proposed solution are inspired by the "explicitness principle" (Ross Anderson 
and Roger Needham, Crypto'95), which states the importance of being explicit on 
user identities and other attributes in a public key protocol; also see [3]. I 
hope it might be useful to people who work on TLS PSK.

[1] 
https://protect2.fireeye.com/url?k=5a822513-0608efad-5a826588-869a17b5b21b-eb260151f78b0718&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2014%2F585.pdf
[2] https://arxiv.org/abs/1802.04900
[3] 
https://protect2.fireeye.com/url?k=d5bf88ff-89354241-d5bfc864-869a17b5b21b-0e9b3bf58e104f32&q=1&u=https%3A%2F%2Feprint.iacr.org%2F2010%2F136.pdf
 


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




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

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

[Ilari Liusvaara]

On Tue, Sep 24, 2019 at 12:24:15PM -0400, Ben Schwartz wrote:
> On Tue, Sep 24, 2019 at 11:31 AM Ilari Liusvaara 
> wrote:
> 
> > On Tue, Sep 24, 2019 at 09:21:25AM -0400, Erik Nygren wrote:
> > > Following the discussions in Montreal (as well as with some of the ESNI
> > > authors),
> > > we refactored the HTTPSSVC draft to make it more general.  The hope is
> > that
> > > it could be an alternative (or replace the need) for a distinct ESNI
> > record.
> > > 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.
> > >
> > > 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 <
> > erik+i...@nygren.org>,
> > > Benjamin Schwartz 
> > >
> > > Name:   draft-nygren-dnsop-svcb-httpssvc
> > > Revision:   00
> > > Title:  Service binding and parameter specification via the DNS
> > > (DNS SVCB and HTTPSSVC)
> >
> > Couple comments:
> >
> - What about starting point of protocols that have defined name for
> >   SRV records? That thing is of form _foo._tcp.domain.example
> >   (or _foo.udp.domain.example).
> >
> 
> Do you mean to ask about how this would coexist with SRV?  Broadly, I view
> this as a successor to SRV, but I think the details of how they interact
> would have to be defined by the protocol mapping document for a specific
> protocol that currently uses SRV.  The correct logic might be different for
> different protocols; I'm not sure.

I mean more of the starting point to use for protocols that already use
SRV.

> If you think there's a universal rule, that would be good to know.
> 
> 
> > - One possible use for AliasForm with '.' would be to signal that
> >   this service does not exist (IIRC, some other rrtype had special
> >   "this does not exist" value).
> >
> 
> Currently, that's effectively indicated by NXDOMAIN/NODATA.  Do you see a
> need for a specific flag?

Well, NODATA could work (except for http(s)://foo.example).

> 
> > - It seems like ALPN and port are fundamential and would be better
> >   being their own fields, instead of attributes.
> >
> 
> ALPN only applies to TLS-based protocols, and even many TLS-based protocols
> don't use it.  For example, a hypothetical mapping of SVCB for SSH would
> have no use for ALPN.

Some sketch-on-napkin stuff I did actually had subprotocol in place of
ALPN, with subtly different meaning (but most of the time it goes
directly to ALPN).

And I have dealt with hacky SSH over TLS (or worse, TELNET over TLS),
and both did use ALPN.
 
One major issue nowadays is that SSH does not have any equivalent of
SNI (I have seen setups where that would have been very useful).

> I agree that ports are nearly universal, but they're often redundant.  For
> example, in HTTPSSVC, the port can be omitted if it is the default port.
> Since the port doesn't apply in the AliasForm, making it a parameter seemed
> like the most convenient representation.

Some sketch-on-napkin stuff I did had port 0 mean "default/as-specified"
(because it is not like you can use port 0 with APIs as they are).
 
> 
> > - This could be defined to carry out TLS upgrade for any protocol
> >   that uses it. However, one would need to allow ALPN to override the
> >   behavior (e.g., HTTP/3 needs to change transport from TCP to UDP).
> >
> 
> Yes, SVCB is well-suited for pre-connection "upgrades" of all sorts, and
> hopefully it will be useful for TLS upgrades beyond HTTP.  As you note,
> this can be nontrivial, as in the case of HTTP, where the ALPN can signal a
> transport change!  For that reason, the details of client behavior are left
> to the protocol mappings.

Obviously if the ALPN is something unknown, one can not connect, as the
semantics are unknown.

And yes, most protocols could not deal with transport change.

> > - To me, ipv4hint/ipv6hint seem very bad ideas, as they break
> >   normalization and ownership, drastically increasing odds for errors.
> 
> I admit that these hints are fragile, but they have been a very strong
> request from some browser vendors, and similar hints are also present in
> the ESNI RR proposal.  The concern is that, when the origin is using
> HTTPSSVC delegation, and the client's recursive is not HTTPSSVC-aware, the
> client will have to perform a followup A+ query before it can start
> connecting.  The IP hints allow connection start right away.
> 
> The draft contains a number of mitigations against fragility.  For example,
> the client is still required to perform the A+ queries, and switch to
> one of those "official" IP addresses as soon as they are available.
> Hopefully this limits the amount of mischief that can be made by bad IP
> hints.

I do not regard ESNI spec as e

[TLS] I-D Action: draft-ietf-tls-sni-encryption-07.txt

[internet-drafts]

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

Title   : Issues and Requirements for SNI Encryption in TLS
Authors : Christian Huitema
  Eric Rescorla
Filename: draft-ietf-tls-sni-encryption-07.txt
Pages   : 14
Date: 2019-09-24

Abstract:
   This draft describes the general problem of encrypting the Server
   Name Identification (SNI) TLS parameter.  The proposed solutions hide
   a Hidden Service behind a fronting service, only disclosing the SNI
   of the fronting service to external observers.  The draft lists known
   attacks against SNI encryption, discusses the current "co-tenancy
   fronting" solution, and presents requirements for future TLS layer
   solutions.

   In practice, it may well be that no solution can meet every
   requirement, and that practical solutions will have to make some
   compromises.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-07
https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-07


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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