Re: [TLS] DNS-based Encrypted SNI

[Sniffen, Brian]

Looks neat. 

1) TFO DOS vector: is the idea servers will disable TFO under strain but not be 
able to disable ESNI?

2) “clients might opt to attempt captive portal detection to see if they are in 
the presence of a MITM proxy, and if so disable ESNI.”

If I’m operating a great firewall, I can use this to discover dissidents, 
right?  Either they send me dangerous SNI values or they are configured to not 
disable ESNI, and taking the fifth is fatal. To protect them, I think nobody 
can have this mode. 

3) How many bits does this offer? Hiding in a set of a million uniform hosts is 
20 bits, and the nonuniformity will accrue to the adversary’s benefit. Active 
probing will unmask visitors to dissident sites.

I worry that this tool is so weak against a GFW-style adversary for the purpose 
of allowing dissident access to restricted web sites that it will be dangerous 
if released. But maybe I misunderstand the purpose. If this is just to keep 
Western ISPs from monkeying with traffic, sure, ship it.  Labelling the 
encryption with its strength as applied, or showing CDNs and ISPs how to work 
out some bounds, seems one way to help users understand whether this can help 
them or put them more at risk. 

-- 
Brian Sniffen

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Allison Mankin]

I haven't chimed in on the mailing list on this draft, but I'm one of the
people who had discussions with browserfolk in hallways, in the corners of
interim meetings for HTTP2, and other such places, in order to see what it
would take to get a start on TLSA use by browsers.  Due to the floods of
traffic that occurred in this and other chains, I almost missed Joe's call
for answers to consensus questions, but I've responded inline.

Looking forward to discussion in Montreal.

On 26 June 2018 at 00:20, Joseph Salowey  wrote:

> Hi Folks,
>
> There has been some discussion with a small group of folks on github -
> https://github.com/tlswg/dnssec-chain-extension/pull/19.   I want to make
> sure there is consensus in the working group to take on the pinning work
> and see if there is consensus for modifications in the revision.  Please
> respond to the following questions on the list by July 10, 2018.
>
> 1.  Do you support the working group taking on future work on a pinning
> mechanism (based on the modifications or another approach)?
>
​I support future work if there is extensive engagement and involvement by
members of the browser community who have expressed concerns about pinning.


>
> 2.  Do you support the reserved bytes in the revision for a future pinning
> mechanism?
>
​Reserving the bytes without a mechanism is not a good idea, so no.  I
think the method for modifications or another approach is something to be
worked on in future too.


> 3.  Do you support the proof of denial of existence text in the revision?
>
​Yes, this text is good.​


>
> 4.  Do you support the new and improved security considerations?
>
​This text is a good addition - but there are a few things that might be
discussed.
Generally support them.


> Thanks,
>
> Joe
>
>
>
> On Tue, Jun 5, 2018 at 6:51 AM, Paul Wouters  wrote:
>
>> On Mon, 4 Jun 2018, Benjamin Kaduk wrote:
>>
>> Hi Ben,
>>
>> I've taken a stab at putting together some security considerations text
>>> for
>>> draft-ietf-tls-dnssec-chain-extension that reflects my understanding of
>>> the
>>> current state of affairs.  It's in a pull request at
>>> https://github.com/tlswg/dnssec-chain-extension/pull/19 , along with
>>> Viktor's
>>> commit to update the text about the actual DNS records involved (which as
>>> far as I can tell seems to improve the technical accuracy of the text),
>>> and
>>> also inserting a variable-length array that's reserved for future
>>> attempts
>>> to mitigate the (now-)documented security considerations.
>>>
>>
>> Thanks for writing the proposed text. The new opaque Reserved field
>> along with the denial of existence changes you propose addresses all
>> my concerns.
>>
>> One corner case that might be worth mentioning with the proposed DoE text
>> is the odd corner case of hitting a server with a Host header for which
>> it is not configured. You will hit the "default vhost" but you have no
>> appropriate extension data to populate for that hostname. So either the
>> server will return the (cached) TLSA/DoA data of the 'wrong' hostname,
>> or it could just omit the extension. I'd mostly like to say something to
>> prevent an implementation of forgetting this corner case and causing
>> some vulnerability in their code later on by pointing to bogus memory or
>> crashing on dereferencing a NULL.
>>
>> Some nits:
>>
>> If the server supports this extension it performs the appropriate
>> DNS queries,
>>
>> In my PR I had changed this into "obtains the appropriate DNS RRsets",
>> because I envision that TLS servers might not do DNS lookups themselves,
>> but just read this via a file or other method. Eg a cron job that
>> regenerates these hourly for all the hosted domains. It also reduces
>> some fear that all TLS servers suddenly could need to link against
>> a DNSSEC library. They don't if they can just reload a blob from disk
>> regularly to serve up.
>>
>> Similarly:
>>
>> it will need to rebuild
>>
>> is better written as "it will need rebuilt data"
>>
>>
>> "authenticates the chain"
>>
>> That should probably be "validate the chain", but the document has more
>> mixups of validate vs authenticate. In my PR request I had not corrected
>> them in an effort to keep the diff as small as possible.
>>
>> I had modified the examples slightly, so the NSEC example would show a
>> simpler NSEC chain (from www to zzz) instead of the one wrapping around
>> from www to the zone apex. The example quoted is the wrong NSEC record
>> (the one from apex to www.example.com does not show that the
>> _443._tcp.www.example.com does not exist, you need the one from
>> www..example.com  to the apex at the end of the
>> zone)
>>
>>
>> I'm not sure what you mean with:
>>
>> validated negative TTL
>>
>> I guess you mean to say the shortest TTL of any data in the chain? But
>> sometimes the negative cache time is larger then the TTL (eg if TTL = 0)
>> Since this is just generic DNS handling, I would probably j

Re: [TLS] DNS-based Encrypted SNI

[Patrick McManus]

On Tue, Jul 3, 2018 at 11:20 AM, Ben Schwartz <
bemasc=40google@dmarc.ietf.org> wrote:

>
> One concern I've heard many times is that we can't add non-A/ queries
> to a browser's critical path because there are middleboxes and buggy
> recursives that will just drop them, leading to a DNS timeout delay on
> every new socket.  However, for encrypted SNI I think we can ignore this by
> focusing on clients with DPRIVE or DOH enabled, which should avoid these
> kinds of problems.
>
>
yes, and of course encrypting sni is a lot more valuable when the dns query
is also encrypted.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DNS-based Encrypted SNI

[Paul Wouters]

On Mon, 2 Jul 2018, Eric Rescorla wrote:


  It is strongly recommended not to use TXT records. Why not use a new
  RRTYPE? Everything these days knows how to serve unknown record types
  (see RFC 3597). The only possibly exception is provisioning tools of
  small players, but this document starts of saying you basically need
  to be on a bulk hosting provider anyway. They can properly provision.

See:
https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906


[Can we keep the discussion within the IETF and the Note Well please. We
 also don't know what happens in 10 years with these links.]

quoting from that link:

These facts lead to the conclusion that if we choose RRtype as the
method, there would often be cases where the DNS record of the ESNIKey
and the TLS server would be required to be operated by different
entities.

That seems to have confused two things with each other. I did not say
anything about the location of the DNS record, only of the RRTYPE.
Clearly, with the same location, it would be under control of the same
entity, so I don't understand why you bring this up as a reason against
using a dedicated RRTYPE.

Here is another argument against it, besides the generic IETF policy of
trying to not overload things or create kitchen sinks. If you used, or
were forced to use, a DNS under control of someone who can block things,
they might be instructed to block anything related to encrypted SNI,
and they might decide to just block all TXT records, even unrelated
ones, resulting in collateral damage.

Paul

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Paul Wouters]

On Tue, 3 Jul 2018, Allison Mankin wrote:


2.  Do you support the reserved bytes in the revision for a future pinning 
mechanism?

​Reserving the bytes without a mechanism is not a good idea, so no.  I think 
the method for modifications or another approach is
something to be worked on in future too.


Reserved bytes are always under specified, that is why they are reserved.

For instance, yesterdy ekr filed a draft for encrypted SNI with this:

 struct {
   uint8 checksum[4];
   KeyShareEntry keys<4..2^16-1>;
   CipherSuite cipher_suites<2..2^16-2>;
   uint16 padded_length;
   uint64 not_before;
   uint64 not_after;
   Extension extensions<0..2^16-1>;
   } ESNIKeys;

 extensions  A list of extensions that the client can take into
  consideration when generating a Client Hello message.  The format
  is defined in [I-D.ietf-tls-tls13]; Section 4.2.  The purpose of
  the field is to provide room for additional features in the
  future; this document does not define any extension.

So there is a whole extension block with no specification and no idea
even if it would ever be needed. That is much weaker then the need for
TLS extension pinning.

Additionally, let me remind you of the direction that the solution
would take if this is punted completely to a new document:

https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00

The smithee draft is a terrible idea. We can do better.

Paul

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

Re: [TLS] DNS-based Encrypted SNI

[Eric Rescorla]

On Tue, Jul 3, 2018 at 8:40 AM, Paul Wouters  wrote:

> On Mon, 2 Jul 2018, Eric Rescorla wrote:
>
>   It is strongly recommended not to use TXT records. Why not use a new
>>   RRTYPE? Everything these days knows how to serve unknown record
>> types
>>   (see RFC 3597). The only possibly exception is provisioning tools of
>>   small players, but this document starts of saying you basically need
>>   to be on a bulk hosting provider anyway. They can properly
>> provision.
>>
>> See:
>> https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issu
>> ecomment-388531906
>>
>
> [Can we keep the discussion within the IETF and the Note Well please. We
>  also don't know what happens in 10 years with these links.]
>

If you look carefully, you'll see that this discussion happened weeks ago.
I was
just pointing you at it because you asked why we did it the way we did.

With that said,IETF policy does not prohibit having discussions on Github.
We do it
regularly in TLS and it's the standard policy in QUIC.



> quoting from that link:
>
> These facts lead to the conclusion that if we choose RRtype as the
> method, there would often be cases where the DNS record of the
> ESNIKey
> and the TLS server would be required to be operated by different
> entities.
>
> That seems to have confused two things with each other. I did not say
> anything about the location of the DNS record, only of the RRTYPE.
> Clearly, with the same location, it would be under control of the same
> entity, so I don't understand why you bring this up as a reason against
> using a dedicated RRTYPE.
>

I'm just quoting Kazuho here, so I'll let him respond to himself.

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

[TLS] tls - Requested sessions have been scheduled for IETF 102

["IETF Secretariat"]

Dear Sean Turner,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


tls Session 1 (2:00 requested)
Monday, 16 July 2018, Afternoon Session I 1330-1530
Room Name: Place du Canada size: 300
-
tls Session 2 (1:00 requested)
Thursday, 19 July 2018, Afternoon Session III 1810-1910
Room Name: Laurier size: 250
-


iCalendar: https://datatracker.ietf.org/meeting/102/sessions/tls.ics

Request Information:


-
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Sean Turner

Number of Sessions: 2
Length of Session(s):  2 Hours, 1 Hour
Number of Attendees: 120
Conflicts to Avoid: 
 First Priority: acme cfrg curdle dispatch httpbis mls perc quic rtcweb stir 
saag secdispatch suit teep tokbind uta
 Second Priority: dprive ace
 Third Priority: tcpinc lamps sidr sidrops


People who must be present:
  Eric Rescorla
  Rich Salz
  Sean Turner
  Joseph A. Salowey
  Hannes Tschofenig
  Yoav Nir
  Martin Thomson
  Daniel Kahn Gillmor
  Benjamin Kaduk
  Nick Sullivan
  Subodh Iyengar
  David Benjamin
  Kyle Nekritz

Resources Requested:

Special Requests:
  
-

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

[TLS] Encrypted SNI

[Bret Jordan]

From a discussion on the PATIENT list found here: 
https://www.ietf.org/mail-archive/web/patient/current/msg00078.html 



From my personal perspective, we need to be careful with all of these efforts. 
It feels like the pendulum has swung so far to one side, the side of 
privacy-at-any-cost, that we are unknowingly increasing the risk to individuals 
and organizations by enabling threat actors and intrusions sets to attack 
networks and clients without any level of protection from the network. 

It also feels like a lot of these initiatives are being done without adequately 
involving and ensuring that enterprise networks and critical infrastructure can 
work with these changes. Question, do we know how these ideas and changes are 
going to impact an organizations ability to fulfill their requirements for 
regulatory compliance? 

If we continue down these paths, then I fear networks will be required to wrap 
all traffic in some other less secure protocol, outright deny some of these 
protocols, or be forced to fully proxy all traffic or take an approach that 
Google has done with their BeyondCorp design.  

The IETF work needs to do more outreach with enterprise networks and critical 
infrastructure and be fundamentally more inclusive. Privacy-at-any-cost is not 
a holistic design. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not 
be unscrambled is an egg."



### Copied content from the PATIENT discussion 


On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty mailto:kathleen.moriarty.ietf%20at%20gmail.com>> wrote:
On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla mailto:ekr%20at%20rtfm.com>> wrote:
>
>
> On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski 
> wrote:
>>
>> Your point is one that deserves further discussion, Eric - which seems
>> likely to scale rapidly going forward.  It is key.
>>
>> So how does draft-ietf-tls-sni-encryption it into the argument?
>
>
> As you suggest, SNI encryption is intended to conceal the SNI, which of
> course would make SNI inspection difficult.
>
> My evaluation of the current state of SNI encryption is that given the
> current technical state, it will not see particularly wide deployment, with
> the primary scenario being "at-risk" sites who are subject to censorship who
> either hide behind or co-tenant with sites which are not subject to
> censorship. That probably isn't going to be incredibly common right now. Of
> course, this is regrettable from the perspective of people designing these
> protocols, but I think that's the situation.

EKR posted a draft to encrypt SNI, see:
https://www.ietf.org/mail-archive/web/tls/current/msg26468.html 


It targets the CDNs who host most of the web traffic in the US at
least.  The right place to comment on this would be the TLS list of
course, but since proposals are being posted, this is a reality and
needs to be discussed.  Those using SNI need to make sure their use
cases are clear and understood and argue the pros and cons.

Kathleen,

Thanks for pointing out this draft.

As they say, predictions are hard, especially about the future. In March, the 
ESNI problem looked pretty intractable and then subsequently we had this idea 
about why it might be workable.

-Ekr

Best regards,
Kathleen

>
> -Ekr
>
>> On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>>
>> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > >
>> wrote:
>>>
>>> Hi Diego,
>>>
>>> It is also worth referencing a relatively recent Lawfare article on the
>>> scaling litigation in the U.S. against those supporting e2e encryption
>>> services or capabilities.
>>>
>>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis
>>>  
>>> 
>>>
>>> This litigation trend is also likely to increase the insurance costs of
>>> providers.  Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, may not
>>> even be able to get insurance.  It may be fun and games to play crypto rebel
>>> in venues like the IETF where the risk exposure is minimal, but when it
>>> comes to real world consequences and costs, the equations for providers are
>>> rather different.
>>
>>
>> I think this rather overestimates the degree to which both TLS 1.3 and
>> QUIC change the equation about what a provider is able to determine from
>> traffic inspection. As a practical matter, the primary change from TLS 1.2
>> is that the provider does not get to see the server's certificate, but it
>> does see the SNI. Given that the SNI contains the identity of the server
>> that the client is connected to and that the other identities in the
>> certificate are often whatever the provider decided to co-locate on the 

Re: [TLS] Encrypted SNI

[Ackermann, Michael]

+1

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Bret Jordan
Sent: Tuesday, July 3, 2018 1:08 PM
To: tls@ietf.org
Subject: [TLS] Encrypted SNI

From a discussion on the PATIENT list found here: 
https://www.ietf.org/mail-archive/web/patient/current/msg00078.html


From my personal perspective, we need to be careful with all of these efforts. 
It feels like the pendulum has swung so far to one side, the side of 
privacy-at-any-cost, that we are unknowingly increasing the risk to individuals 
and organizations by enabling threat actors and intrusions sets to attack 
networks and clients without any level of protection from the network.

It also feels like a lot of these initiatives are being done without adequately 
involving and ensuring that enterprise networks and critical infrastructure can 
work with these changes. Question, do we know how these ideas and changes are 
going to impact an organizations ability to fulfill their requirements for 
regulatory compliance?

If we continue down these paths, then I fear networks will be required to wrap 
all traffic in some other less secure protocol, outright deny some of these 
protocols, or be forced to fully proxy all traffic or take an approach that 
Google has done with their BeyondCorp design.

The IETF work needs to do more outreach with enterprise networks and critical 
infrastructure and be fundamentally more inclusive. Privacy-at-any-cost is not 
a holistic design.

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not 
be unscrambled is an egg."



### Copied content from the PATIENT discussion 


On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty mailto:kathleen.moriarty.ietf%20at%20gmail.com>> wrote:

On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla mailto:ekr%20at%20rtfm.com>> wrote:
>
>
> On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski  yaanatech.co..uk>
> wrote:
>>
>> Your point is one that deserves further discussion, Eric - which seems
>> likely to scale rapidly going forward.  It is key.
>>
>> So how does draft-ietf-tls-sni-encryption it into the argument?
>
>
> As you suggest, SNI encryption is intended to conceal the SNI, which of
> course would make SNI inspection difficult.
>
> My evaluation of the current state of SNI encryption is that given the
> current technical state, it will not see particularly wide deployment, with
> the primary scenario being "at-risk" sites who are subject to censorship who
> either hide behind or co-tenant with sites which are not subject to
> censorship. That probably isn't going to be incredibly common right now. Of
> course, this is regrettable from the perspective of people designing these
> protocols, but I think that's the situation.

EKR posted a draft to encrypt SNI, see:
https://www.ietf.org/mail-archive/web/tls/current/msg26468.html

It targets the CDNs who host most of the web traffic in the US at
least.  The right place to comment on this would be the TLS list of
course, but since proposals are being posted, this is a reality and
needs to be discussed.  Those using SNI need to make sure their use
cases are clear and understood and argue the pros and cons.

Kathleen,

Thanks for pointing out this draft.

As they say, predictions are hard, especially about the future. In March, the 
ESNI problem looked pretty intractable and then subsequently we had this idea 
about why it might be workable.

-Ekr

Best regards,
Kathleen

>
> -Ekr
>
>> On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>>
>> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > yaanatech.co.uk>
>> wrote:
>>>
>>> Hi Diego,
>>>
>>> It is also worth referencing a relatively recent Lawfare article on the
>>> scaling litigation in the U.S. against those supporting e2e encryption
>>> services or capabilities.
>>>
>>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis
>>>
>>> This litigation trend is also likely to increase the insurance costs of
>>> providers.  Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, may not
>>> even be able to get insurance.  It may be fun and games to play crypto rebel
>>> in venues like the IETF where the risk exposure is minimal, but when it
>>> comes to real world consequences and costs, the equations for providers are
>>> rather different.
>>
>>
>> I think this rather overestimates the degree to which both TLS 1.3 and
>> QUIC change the equation about what a provider is able to determine from
>> traffic inspection. As a practical matter, the primary change from TLS 1.2
>> is that the provider does not get to see the server's certificate, but it
>> does see the SNI. Given that the SNI contains the identity of the server
>> that the client is connected to and that the other identities in the
>> certificate are often whatever the provider decided to co-locate on the same
>> machine, I'm not sure how much 

Re: [TLS] Encrypted SNI

[Benjamin Kaduk]

On Tue, Jul 03, 2018 at 11:08:21AM -0600, Bret Jordan wrote:
> From a discussion on the PATIENT list found here: 
> https://www.ietf.org/mail-archive/web/patient/current/msg00078.html 
> 
> 
> 
> From my personal perspective, we need to be careful with all of these 
> efforts. It feels like the pendulum has swung so far to one side, the side of 
> privacy-at-any-cost, that we are unknowingly increasing the risk to 
> individuals and organizations by enabling threat actors and intrusions sets 
> to attack networks and clients without any level of protection from the 
> network. 

BCP 61 leads us to not expect any protection from the network, does it not?

> It also feels like a lot of these initiatives are being done without 
> adequately involving and ensuring that enterprise networks and critical 
> infrastructure can work with these changes. Question, do we know how these 
> ideas and changes are going to impact an organizations ability to fulfill 
> their requirements for regulatory compliance? 
> 
> If we continue down these paths, then I fear networks will be required to 
> wrap all traffic in some other less secure protocol, outright deny some of 
> these protocols, or be forced to fully proxy all traffic or take an approach 
> that Google has done with their BeyondCorp design.  

I suspect you will find that many proponents of the proposals you find
worrisome would also be enthusiastic proponents of "an approach similar to what
Google has done with BeyondCorp".  Such a discussion would be off-topic for
the TLS list, but you would probably be well-served to have some supporting text
for why this sort of approach should be considered bad, if you want to gain
sympathy for your perspective.

-Ben

> The IETF work needs to do more outreach with enterprise networks and critical 
> infrastructure and be fundamentally more inclusive. Privacy-at-any-cost is 
> not a holistic design. 
> 
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can 
> not be unscrambled is an egg."
> 
> 
> 
> ### Copied content from the PATIENT discussion 
> 
> 
> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty  gmail.com > wrote:
> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla  > wrote:
> >
> >
> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski 
> > wrote:
> >>
> >> Your point is one that deserves further discussion, Eric - which seems
> >> likely to scale rapidly going forward.  It is key.
> >>
> >> So how does draft-ietf-tls-sni-encryption it into the argument?
> >
> >
> > As you suggest, SNI encryption is intended to conceal the SNI, which of
> > course would make SNI inspection difficult.
> >
> > My evaluation of the current state of SNI encryption is that given the
> > current technical state, it will not see particularly wide deployment, with
> > the primary scenario being "at-risk" sites who are subject to censorship who
> > either hide behind or co-tenant with sites which are not subject to
> > censorship. That probably isn't going to be incredibly common right now. Of
> > course, this is regrettable from the perspective of people designing these
> > protocols, but I think that's the situation.
> 
> EKR posted a draft to encrypt SNI, see:
> https://www.ietf.org/mail-archive/web/tls/current/msg26468.html 
> 
> 
> It targets the CDNs who host most of the web traffic in the US at
> least.  The right place to comment on this would be the TLS list of
> course, but since proposals are being posted, this is a reality and
> needs to be discussed.  Those using SNI need to make sure their use
> cases are clear and understood and argue the pros and cons.
> 
> Kathleen,
> 
> Thanks for pointing out this draft.
> 
> As they say, predictions are hard, especially about the future. In March, the 
> ESNI problem looked pretty intractable and then subsequently we had this idea 
> about why it might be workable.
> 
> -Ekr
> 
> Best regards,
> Kathleen
> 
> >
> > -Ekr
> >
> >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
> >>
> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski  >> >
> >> wrote:
> >>>
> >>> Hi Diego,
> >>>
> >>> It is also worth referencing a relatively recent Lawfare article on the
> >>> scaling litigation in the U.S. against those supporting e2e encryption
> >>> services or capabilities.
> >>>
> >>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis
> >>>  
> >>> 
> >>>
> >>> This litigation trend is also likely to increase the insurance costs of
> >>> providers.  Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, may 
> >>> not
> >

Re: [TLS] DNS-based Encrypted SNI

[Tim Hollebeek]

One of the things we found out with CAA is that this extremely optimistic view
of the support for unknown RR types by large hosting providers is not 
accurate.

-Tim

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Paul Wouters
> Sent: Monday, July 2, 2018 11:53 PM
> To: tls@ietf.org
> Subject: Re: [TLS] DNS-based Encrypted SNI
>
> On Mon, 2 Jul 2018, Eric Rescorla wrote:
>
> >   https://tools.ietf.org/html/draft-rescorla-tls-esni-00
>
> > This is at a pretty early stage, so comments, questions, defect
> > reports welcome.
>
>
>   This structure is placed in the RRData section of a TXT record as a
>   base64-encoded string.  If this encoding exceeds the 255 octet limit
>   of TXT strings, it must be split across multiple concatenated strings
>   as per Section 3.1.3 of [RFC4408].
>
> It is strongly recommended not to use TXT records. Why not use a new
> RRTYPE? Everything these days knows how to serve unknown record types (see
> RFC 3597). The only possibly exception is provisioning tools of small 
> players,
> but this document starts of saying you basically need to be on a bulk 
> hosting
> provider anyway. They can properly provision.
>
> I need to think more about the document to see if there is really not 
> something
> simpler or better possible.
>
> Paul
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Darin Pettis]

+1



On Tue, Jul 3, 2018 at 12:08 PM Bret Jordan  wrote:

> From a discussion on the PATIENT list found here:
> https://www.ietf.org/mail-archive/web/patient/current/msg00078.html
>
>
> From my personal perspective, we need to be careful with all of these
> efforts. It feels like the pendulum has swung so far to one side, the side
> of privacy-at-any-cost, that we are unknowingly increasing the risk to
> individuals and organizations by enabling threat actors and intrusions sets
> to attack networks and clients without any level of protection from the
> network.
>
> It also feels like a lot of these initiatives are being done without
> adequately involving and ensuring that enterprise networks and critical
> infrastructure can work with these changes. Question, do we know how these
> ideas and changes are going to impact an organizations ability to fulfill
> their requirements for regulatory compliance?
>
> If we continue down these paths, then I fear networks will be required to
> wrap all traffic in some other less secure protocol, outright deny some of
> these protocols, or be forced to fully proxy all traffic or take an
> approach that Google has done with their BeyondCorp design.
>
> The IETF work needs to do more outreach with enterprise networks and
> critical infrastructure and be fundamentally more inclusive.
> Privacy-at-any-cost is not a holistic design.
>
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
> can not be unscrambled is an egg."
>
>
>
> ### Copied content from the PATIENT discussion 
>
>
> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty  at gmail.com> wrote:
>
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla  wrote:
>> >
>> >
>> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski > ..uk>
>> > wrote:
>> >>
>> >> Your point is one that deserves further discussion, Eric - which seems
>> >> likely to scale rapidly going forward.  It is key.
>> >>
>> >> So how does draft-ietf-tls-sni-encryption it into the argument?
>> >
>> >
>> > As you suggest, SNI encryption is intended to conceal the SNI, which of
>> > course would make SNI inspection difficult.
>> >
>> > My evaluation of the current state of SNI encryption is that given the
>> > current technical state, it will not see particularly wide deployment,
>> with
>> > the primary scenario being "at-risk" sites who are subject to
>> censorship who
>> > either hide behind or co-tenant with sites which are not subject to
>> > censorship. That probably isn't going to be incredibly common right
>> now. Of
>> > course, this is regrettable from the perspective of people designing
>> these
>> > protocols, but I think that's the situation.
>>
>> EKR posted a draft to encrypt SNI, see:
>> https://www.ietf.org/mail-archive/web/tls/current/msg26468.html
>>
>> It targets the CDNs who host most of the web traffic in the US at
>> least.  The right place to comment on this would be the TLS list of
>> course, but since proposals are being posted, this is a reality and
>> needs to be discussed.  Those using SNI need to make sure their use
>> cases are clear and understood and argue the pros and cons.
>>
>
> Kathleen,
>
> Thanks for pointing out this draft.
>
> As they say, predictions are hard, especially about the future. In March,
> the ESNI problem looked pretty intractable and then subsequently we had
> this idea about why it might be workable.
>
> -Ekr
>
> Best regards,
>> Kathleen
>>
>> >
>> > -Ekr
>> >
>> >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>> >>
>> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > yaanatech.co.uk>
>> >> wrote:
>> >>>
>> >>> Hi Diego,
>> >>>
>> >>> It is also worth referencing a relatively recent Lawfare article on
>> the
>> >>> scaling litigation in the U.S. against those supporting e2e encryption
>> >>> services or capabilities.
>> >>>
>> >>>
>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis
>> >>>
>> >>> This litigation trend is also likely to increase the insurance costs
>> of
>> >>> providers.  Indeed, a provider that supports TLS1.3, QUIC, SNI, etc,
>> may not
>> >>> even be able to get insurance.  It may be fun and games to play
>> crypto rebel
>> >>> in venues like the IETF where the risk exposure is minimal, but when
>> it
>> >>> comes to real world consequences and costs, the equations for
>> providers are
>> >>> rather different.
>> >>
>> >>
>> >> I think this rather overestimates the degree to which both TLS 1.3 and
>> >> QUIC change the equation about what a provider is able to determine
>> from
>> >> traffic inspection. As a practical matter, the primary change from TLS
>> 1.2
>> >> is that the provider does not get to see the server's certificate, but
>> it
>> >> does see the SNI. Given that the SNI contains the identity of the
>> server
>> >> that the client is connected to and that the other identities in the
>> >> certificate are often whateve

Re: [TLS] Encrypted SNI

[Kathleen Moriarty]

On Tue, Jul 3, 2018 at 3:49 PM, Benjamin Kaduk
 wrote:
> On Tue, Jul 03, 2018 at 11:08:21AM -0600, Bret Jordan wrote:
>> From a discussion on the PATIENT list found here: 
>> https://www.ietf.org/mail-archive/web/patient/current/msg00078.html 
>> 
>>
>>
>> From my personal perspective, we need to be careful with all of these 
>> efforts. It feels like the pendulum has swung so far to one side, the side 
>> of privacy-at-any-cost, that we are unknowingly increasing the risk to 
>> individuals and organizations by enabling threat actors and intrusions sets 
>> to attack networks and clients without any level of protection from the 
>> network.
>
> BCP 61 leads us to not expect any protection from the network, does it not?
>
>> It also feels like a lot of these initiatives are being done without 
>> adequately involving and ensuring that enterprise networks and critical 
>> infrastructure can work with these changes. Question, do we know how these 
>> ideas and changes are going to impact an organizations ability to fulfill 
>> their requirements for regulatory compliance?
>>
>> If we continue down these paths, then I fear networks will be required to 
>> wrap all traffic in some other less secure protocol, outright deny some of 
>> these protocols, or be forced to fully proxy all traffic or take an approach 
>> that Google has done with their BeyondCorp design.
>
> I suspect you will find that many proponents of the proposals you find
> worrisome would also be enthusiastic proponents of "an approach similar to 
> what
> Google has done with BeyondCorp".  Such a discussion would be off-topic for
> the TLS list, but you would probably be well-served to have some supporting 
> text
> for why this sort of approach should be considered bad, if you want to gain
> sympathy for your perspective.

The proposal came from an AD who just a few moths ago told them not to
worry about these possible changes (see referenced thread on PATIENT
list) that impact their work, so in other words, don't prepare for it,
don't worry about alternate solutions or figuring out ways to better
articulate your use cases.  Then that AD submits the proposal.
Challenging comments are posted and I would expect that there be
sensitivities as to the origin of the draft and making it even more
fair for list participants to comment and understand that this draft
should be treated as any other.

While I agree that additional text and supporting use case information
is needed, there also needs to be an openness to listen to all views
on a proposal.  If there are use cases that are critical for SNI, they
need to surface and be considered.

Best regards,
Kathleen

>
> -Ben
>
>> The IETF work needs to do more outreach with enterprise networks and 
>> critical infrastructure and be fundamentally more inclusive. 
>> Privacy-at-any-cost is not a holistic design.
>>
>> Thanks,
>> Bret
>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
>> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can 
>> not be unscrambled is an egg."
>>
>>
>>
>> ### Copied content from the PATIENT discussion 
>>
>>
>> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty > gmail.com > wrote:
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla > > wrote:
>> >
>> >
>> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski 
>> > wrote:
>> >>
>> >> Your point is one that deserves further discussion, Eric - which seems
>> >> likely to scale rapidly going forward.  It is key.
>> >>
>> >> So how does draft-ietf-tls-sni-encryption it into the argument?
>> >
>> >
>> > As you suggest, SNI encryption is intended to conceal the SNI, which of
>> > course would make SNI inspection difficult.
>> >
>> > My evaluation of the current state of SNI encryption is that given the
>> > current technical state, it will not see particularly wide deployment, with
>> > the primary scenario being "at-risk" sites who are subject to censorship 
>> > who
>> > either hide behind or co-tenant with sites which are not subject to
>> > censorship. That probably isn't going to be incredibly common right now. Of
>> > course, this is regrettable from the perspective of people designing these
>> > protocols, but I think that's the situation.
>>
>> EKR posted a draft to encrypt SNI, see:
>> https://www.ietf.org/mail-archive/web/tls/current/msg26468.html 
>> 
>>
>> It targets the CDNs who host most of the web traffic in the US at
>> least.  The right place to comment on this would be the TLS list of
>> course, but since proposals are being posted, this is a reality and
>> needs to be discussed.  Those using SNI need to make sure their use
>> cases are clear and understood and argue the pros and cons.
>>
>> Kathleen,
>>
>> Thanks for pointing out this draft.
>>
>> As they say, predic

Re: [TLS] Encrypted SNI

[Hanno Böck]

So-called "Enterprise" infrastructure has delayed the work of this group
for at least a year. Noone of the people creating that mess has reached
out to this group to explain why they constantly break TLS - let alone
apologize for it.

I believe there's a large overlap of the actors breaking TLS with the
actors who are worried about things like SNI encryption. I'm not sure I
see any reason not to consider these actors as anything but opposed to
the work of this group.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

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

Re: [TLS] Encrypted SNI

[Eric Rescorla]

On Tue, Jul 3, 2018 at 10:08 AM, Bret Jordan  wrote:

> From a discussion on the PATIENT list found here: https://www.ietf.org/mai
> l-archive/web/patient/current/msg00078.html
>
>
> From my personal perspective, we need to be careful with all of these
> efforts. It feels like the pendulum has swung so far to one side, the side
> of privacy-at-any-cost, that we are unknowingly increasing the risk to
> individuals and organizations by enabling threat actors and intrusions sets
> to attack networks and clients without any level of protection from the
> network.
>
> It also feels like a lot of these initiatives are being done without
> adequately involving and ensuring that enterprise networks and critical
> infrastructure can work with these changes. Question, do we know how these
> ideas and changes are going to impact an organizations ability to fulfill
> their requirements for regulatory compliance?
>

Well "these changes" covers a lot of ground, but in this particular case,
can't enterprise just strip ESNI records from DNS?

-Ekr



> The IETF work needs to do more outreach with enterprise networks and
> critical infrastructure and be fundamentally more inclusive.
>



Privacy-at-any-cost is not a holistic design.
>
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
> can not be unscrambled is an egg."
>
>
>
> ### Copied content from the PATIENT discussion 
>
>
> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty  at gmail.com> wrote:
>
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla  wrote:
>> >
>> >
>> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski > ..uk>
>> > wrote:
>> >>
>> >> Your point is one that deserves further discussion, Eric - which seems
>> >> likely to scale rapidly going forward.  It is key.
>> >>
>> >> So how does draft-ietf-tls-sni-encryption it into the argument?
>> >
>> >
>> > As you suggest, SNI encryption is intended to conceal the SNI, which of
>> > course would make SNI inspection difficult.
>> >
>> > My evaluation of the current state of SNI encryption is that given the
>> > current technical state, it will not see particularly wide deployment,
>> with
>> > the primary scenario being "at-risk" sites who are subject to
>> censorship who
>> > either hide behind or co-tenant with sites which are not subject to
>> > censorship. That probably isn't going to be incredibly common right
>> now. Of
>> > course, this is regrettable from the perspective of people designing
>> these
>> > protocols, but I think that's the situation.
>>
>> EKR posted a draft to encrypt SNI, see:
>> https://www.ietf.org/mail-archive/web/tls/current/msg26468.html
>>
>> It targets the CDNs who host most of the web traffic in the US at
>> least.  The right place to comment on this would be the TLS list of
>> course, but since proposals are being posted, this is a reality and
>> needs to be discussed.  Those using SNI need to make sure their use
>> cases are clear and understood and argue the pros and cons.
>>
>
> Kathleen,
>
> Thanks for pointing out this draft.
>
> As they say, predictions are hard, especially about the future. In March,
> the ESNI problem looked pretty intractable and then subsequently we had
> this idea about why it might be workable.
>
> -Ekr
>
> Best regards,
>> Kathleen
>>
>> >
>> > -Ekr
>> >
>> >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>> >>
>> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > yaanatech.co.uk>
>> >> wrote:
>> >>>
>> >>> Hi Diego,
>> >>>
>> >>> It is also worth referencing a relatively recent Lawfare article on
>> the
>> >>> scaling litigation in the U.S. against those supporting e2e encryption
>> >>> services or capabilities.
>> >>>
>> >>> https://www.lawfareblog.com/did-congress-immunize-twitte
>> r-against-lawsuits-supporting-isis
>> >>>
>> >>> This litigation trend is also likely to increase the insurance costs
>> of
>> >>> providers.  Indeed, a provider that supports TLS1.3, QUIC, SNI, etc,
>> may not
>> >>> even be able to get insurance.  It may be fun and games to play
>> crypto rebel
>> >>> in venues like the IETF where the risk exposure is minimal, but when
>> it
>> >>> comes to real world consequences and costs, the equations for
>> providers are
>> >>> rather different.
>> >>
>> >>
>> >> I think this rather overestimates the degree to which both TLS 1.3 and
>> >> QUIC change the equation about what a provider is able to determine
>> from
>> >> traffic inspection. As a practical matter, the primary change from TLS
>> 1.2
>> >> is that the provider does not get to see the server's certificate, but
>> it
>> >> does see the SNI. Given that the SNI contains the identity of the
>> server
>> >> that the client is connected to and that the other identities in the
>> >> certificate are often whatever the provider decided to co-locate on
>> the same
>> >> machine, I'm not sure how much information you are really losing.
>> >>
>> >> -Ekr
>> >>
>> >>>

Re: [TLS] Encrypted SNI

[Brian Sniffen]

Hanno Böck  writes:

> So-called "Enterprise" infrastructure has delayed the work of this group
> for at least a year. Noone of the people creating that mess has reached
> out to this group to explain why they constantly break TLS - let alone
> apologize for it.
>
> I believe there's a large overlap of the actors breaking TLS with the
> actors who are worried about things like SNI encryption. I'm not sure I
> see any reason not to consider these actors as anything but opposed to
> the work of this group.

Whoah!  I've been involved for years specifically to ask for care about
encrypted SNI.  I don't know whether I break TLS; maybe opinions vary.
But my concerns have been specific:

First, at the engineering level, a requirement that servers do expensive
cryptographic work in response to a first packet *and* an inability to
charge that work to a user or application is a big problem.  It makes it
too hard for users or applications to share a server, or leads to levels
of address waste expensive even with IPv6.

If we're going to have 0RTT and 1RTT and TCP Fast Open and ECDHE... then
Encrypted SNI is a hard engineering problem! 

Second, at the architectural level, a serious question about whether
this actually helps anybody, and if so whom?  I think the case of the
Amnesty International worker in an oppressive dictatorship is almost
certainly *not* helped by this work---see my questions about how many
bits of security this provides against an adaptive adversary from this
morning---and would like some clarity that this is about inhibiting the
ISPs, from cafes through enterprises up to Comcast-TWC, from monkeying
with user sessions.  


My concerns at the engineering level have been welcomed, recognized,
validated, and addressed.  Not always exactly the way I'd like, but
absolutely addressed in a way that's appropriate and sincere.  I saw the
same with requests to re-insert RSA Kx late last year.  The PATIENT
folks have gotten a fair hearing.

My architectural concerns have been heard, somewhat less eagerly.  Some
participants, including our colleagues who are vendors to enterprises
and folks like Ben Schwartz, have been clear that they will not bring
all their motivations and evidence to the table.  I significantly
discount their arguments and expect others to do the same---but not to
zero.  It means we need to check their work as we go, or actually trust
them as people, but it *can't* be harder than keeping NSA/IA people on
CFRG!

Anyway, I think the PATIENT folks concerns about the engineering of TLS
1.3 have been heard, have been taken seriously, and have been
addressed---same as mine or yours.  What I've seen of the architectural
concerns leading to network-centric management and "tap" devices come
down to claims about changes in architecture being too expensive,
middleboxes being too expensive, changes to applications being too
expensive, and general citation of an architecture only a few years old
as immutable tradition.  Those claims have also been heard, plenty of
folks have respectfully and diligently combed through them for evidence,
and we've moved on.

I bet that's frustrating and frightening for the folks writing from a
world where those claims aren't faith-based---they're obvious.  They
don't need citation any more than "China is a country"[1] needs
citation.  Nonetheless, engineering conversations based on
data-supported arguments continue to be welcome.

-Brian


Footnotes: 
[1]  https://www.cia.gov/library/publications/the-world-factbook/geos/ch.html
 but see also 
https://www.cia.gov/library/publications/the-world-factbook/geos/tw.html

-- 
Brian Sniffen

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

Re: [TLS] DNS-based Encrypted SNI

[Eric Rescorla]

On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian  wrote:

> Looks neat.
>
> 1) TFO DOS vector: is the idea servers will disable TFO under strain but
> not be able to disable ESNI?
>

I hadn't thought about it, but that seems right. I'm not really seeing why
this is a DOS vector? At present, if you're able to pass a routability
test, you can force a server to do a DH exchange and a signature, so
forcing them to do ESNI decryption doesn't seem like it's that much of an
amplification.




> 2) “clients might opt to attempt captive portal detection to see if they
> are in the presence of a MITM proxy, and if so disable ESNI.”
>
> If I’m operating a great firewall, I can use this to discover dissidents,
> right?  Either they send me dangerous SNI values or they are configured to
> not disable ESNI, and taking the fifth is fatal. To protect them, I think
> nobody can have this mode.
>

This doesn't sound right to me. The idea here is that you only disable ESNI
if the attacker is able to generate a valid TLS connection to a
*non-default* root, which means that they are MITM-capable, which nation
state firewall operators typically are not. And of course if they are, then
you have real problems. Can you walk me through the flow you have in mind.



> 3) How many bits does this offer? Hiding in a set of a million uniform
> hosts is 20 bits,


Well, I would say it's got an anonymity set of 2^{20}. It's not 20 bits
strong in the sense that the attacker can do a computation of cost 2^{20}.n


and the nonuniformity will accrue to the adversary’s benefit. Active
> probing will unmask visitors to dissident sites.
>

I don't really follow this. Can you explain?

-Ekr



I worry that this tool is so weak against a GFW-style adversary for the
> purpose of allowing dissident access to restricted web sites that it will
> be dangerous if released. But maybe I misunderstand the purpose. If this is
> just to keep Western ISPs from monkeying with traffic, sure, ship it.
> Labelling the encryption with its strength as applied, or showing CDNs and
> ISPs how to work out some bounds, seems one way to help users understand
> whether this can help them or put them more at risk.
>
> --
> Brian Sniffen
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DNS-based Encrypted SNI

[Kazuho Oku]

2018-07-04 0:55 GMT+09:00 Eric Rescorla :
>
>
> On Tue, Jul 3, 2018 at 8:40 AM, Paul Wouters  wrote:
>>
>> On Mon, 2 Jul 2018, Eric Rescorla wrote:
>>
>>>   It is strongly recommended not to use TXT records. Why not use a
>>> new
>>>   RRTYPE? Everything these days knows how to serve unknown record
>>> types
>>>   (see RFC 3597). The only possibly exception is provisioning tools
>>> of
>>>   small players, but this document starts of saying you basically
>>> need
>>>   to be on a bulk hosting provider anyway. They can properly
>>> provision.
>>>
>>> See:
>>>
>>> https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906
>>
>>
>> [Can we keep the discussion within the IETF and the Note Well please. We
>>  also don't know what happens in 10 years with these links.]
>
>
> If you look carefully, you'll see that this discussion happened weeks ago. I
> was
> just pointing you at it because you asked why we did it the way we did.
>
> With that said,IETF policy does not prohibit having discussions on Github..
> We do it
> regularly in TLS and it's the standard policy in QUIC.
>
>
>>
>> quoting from that link:
>>
>> These facts lead to the conclusion that if we choose RRtype as the
>> method, there would often be cases where the DNS record of the
>> ESNIKey
>> and the TLS server would be required to be operated by different
>> entities.
>>
>> That seems to have confused two things with each other. I did not say
>> anything about the location of the DNS record, only of the RRTYPE.
>> Clearly, with the same location, it would be under control of the same
>> entity, so I don't understand why you bring this up as a reason against
>> using a dedicated RRTYPE.
>
>
> I'm just quoting Kazuho here, so I'll let him respond to himself.

The discussion was about comparing two approaches: a) use a new record
type without suffix, b) use TXT record type with suffix.

My argument was that we should select b because a has the
deployability issue in regard to APEX names.

It is true that the deployability issue is a concern related to the
non-use of prefix. It is _not_ related to the selection of the record
type.

OTOH, I think that the reliability issue related to using a new record
type exists, as others have pointed out.

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



-- 
Kazuho Oku

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Viktor Dukhovni]

On Tue, Jul 03, 2018 at 10:41:18AM -0400, Allison Mankin wrote:

> I haven't chimed in on the mailing list on this draft, but I'm one of the
> people who had discussions with browserfolk in hallways, in the corners of
> interim meetings for HTTP2, and other such places, in order to see what it
> would take to get a start on TLSA use by browsers.

The present dilemma for this draft is how to ensure that it has
enough security benefit to warrant deployment and sufficient scope
to cover would-be applications.  The draft as originally approved
had two major defects:

* Required not only extension support, but also DNSSEC and DANE
  TLSA records in order to support "greefield" applications that
  mandate the extension from the get-go.

* No plausible path to incremental adoption by existing WebPKI
  applications, that can't mandate the extension (let alone
  DNSSEC and DANE), but might employ DANE when present, but
  otherwise continue with WebPKI alone.

The first defect is addressed by incorporating denial of existence.
This allows a server to present an extension that proves lack of
DNSSEC for a containing DNS zone or just absence of the associated
TLSA records.  In this way "greenfield" applications that mandate
the extension can interoperate with servers that have not yet
deployment DNSSEC or DANE.

The second defect requires at least the ability to mandate the
extension, when a server commits to continue to present it for some
time.  Since pinning is potentially fragile, we should be pinning
as little as possible.  Hence once again only support for the
extension, rather than a continued expectation of DNSSEC, DANE,
particular certificate details, ...  This is NOT HPKP.  This requires
denial of existence support, adding which fortunately seems to have
broad consensus.

> Looking forward to discussion in Montreal.

I'd like to see as much of the discussion as possible on list, where
we can get responsive comments from informed participants, and not
just "humming".

> > 1.  Do you support the working group taking on future work on a pinning
> > mechanism (based on the modifications or another approach)?
>
> I support future work if there is extensive engagement and involvement by
> members of the browser community who have expressed concerns about pinning.

* TLS is not exclusively for HTTPS.

* This extension is NOT just about browsers. It should support
  IMAP, SUBMIT, POP, XMPP, NNTP, ...

* The "concerns about pinning" are often related to the
  unsurprising failure of HPKP.  It is unfortunate that HPKP
  has tainted "pinning".  And yet the IETF has just approved
  MTA-STS, which pins a commitment to WebPKI authentication along
  with a list of the domain's MX hosts.

  It is easy to taint the proposed downgrade protection mechanism
  by associating it (incorrectly) with HPKP.  The proposal DOES
  NOT pin the peer certificates or keys.  This is an STS-lite
  proposal, that pins only a capability: support for the extension
  for a particular TLS service endpoint.  And in this case no
  "testing" mode is applicable, and sub-domain pinning is
  impactical.  Looking at the existing STS-like protocols, it is
  easy to see that only their TTL applies here.

> Reserving the bytes without a mechanism is not a good idea, so no.

I don't see a rationale for this.  The mechanism is a TTL to be
carried in those bytes.  We're willing to accept a variable-length
field in order to accommodate objections that a TTL *might* not be
enough, and a compelling case for additional attributes might be
made in the future.  I'm confident that no such case will hold up
to scrutiny.

-- 
Viktor.

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

Re: [TLS] Encrypted SNI

[Paul Wouters]

On Tue, 3 Jul 2018, Eric Rescorla wrote:


but in this particular case, can't enterprise just strip ESNI records from DNS?


Not if endnodes within the enterprise also use DNSSEC. Unless you want
the enterprise to run authoritative fake DNSSEC for the entire world.

It also requires installing internal trust anchors, which is something
you pushed back hard on with draft-ietf-ipsecme-split-dns

One way this could be done is if draft-ietf-dnsop-dns-rpz finally goes
RFC, so IETF gains change control of a bis document, where we define the
filtering to move the filtered record from the additional to the authority
section, so the filtering can be detected yet DNSSEC verified.  But it
seems draft-ietf-dnsop-dns-rpz is being kept in draft state forever,
which basically prevents us from fixing this.

Paul
ps. also note stripping a ESNI RRTYPE is easier than stripping _some_
TXT records :)

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

Re: [TLS] Encrypted SNI

[nalini elkins]

 >So-called "Enterprise" infrastructure has delayed the work of this group
>for at least a year. Noone of the people creating that mess has reached
>out to this group to explain why they constantly break TLS - let alone
>apologize for it.

>I believe there's a large overlap of the actors breaking TLS with the
>actors who are worried about things like SNI encryption. I'm not sure I
>see any reason not to consider these actors as anything but opposed to
>the work of this group.

I believe that enterprise people have tried over and over again to
explain.
You may wish to take a serious look at:

https://datatracker.ietf.org/doc/draft-fenter-tls-decryption/

I, personally, have tremendous respect for the people in the TLS group.
The level of cryptographic expertise as well as the passion /
commitment is unparalleled.

I think both "sides" are acting with good intentions - while looking at the
world through their own lenses.   Enterprises need to be able to do Business
As Usual (BAU) while integrating innovation into their networks.

I suspect that no one likes middleboxes or "breaking" TLS but it is at least
temporarily necessary.   You cannot hide your head in the sand and pretend
it does not exist.  Markets exist for a reason.

People do not spend time and money to make presentations (at the TLS group)
without having a very good reason to do so.

IMHO,  having everything at the end points (or the end-to-end principle)
has led
to an unsustainable trajectory to expensive and complex network functions
and
end-points.   I have done a rudimentary survey of some of the enterprises I
know and they say that much (if not most) of their time is spent in patching
applications and end points.  This is one reason they cannot look ahead to
bigger tasks like migrating to IPv6.

I completely agree that enterprises have not presented the statistics and a
carefully reasoned study to substantiate the above claims.  I am in the
process of taking a step back to see what we need to do - what drafts we
need to write and what numbers we need to present - to have a full
picture of how Internet protocols are used.

Enterprises are a very large group of users of the Internet protocols and
need to be considered as such.

Nalini


On Wed, Jul 4, 2018 at 1:54 AM, Hanno Böck  wrote:

> So-called "Enterprise" infrastructure has delayed the work of this group
> for at least a year. Noone of the people creating that mess has reached
> out to this group to explain why they constantly break TLS - let alone
> apologize for it.
>
> I believe there's a large overlap of the actors breaking TLS with the
> actors who are worried about things like SNI encryption. I'm not sure I
> see any reason not to consider these actors as anything but opposed to
> the work of this group.
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DNS-based Encrypted SNI

[Ilari Liusvaara]

On Tue, Jul 03, 2018 at 07:50:00PM +, Tim Hollebeek wrote:
> One of the things we found out with CAA is that this extremely optimistic view
> of the support for unknown RR types by large hosting providers is not 
> accurate.

As context, problems with CAA were not limited to various DNS hosters
not supporting it or DNS recursives choking on it, but also things like:

1) Broken replies from _authoritative_ nameservers for CAA queries.
2) Timeouts from _authoritative_ nameservers for CAA queries.
3) Broken DNSSEC proofs for empty record sets.

The most worrisome here is the 2). Even with good DNS recursive, you
would still take timeouts.


There are quite a bit of CAA-related problem reports on Let's Encrypt
forums. Those are almost never of incorrect CAA records and rarely
questions on how to add CAA, but generally problems caused by some
authoritative nameserver being broken and causing CAA lookups to
fail or return bogus answers.


-Ilari

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

Re: [TLS] DNS-based Encrypted SNI

[Ilari Liusvaara]

On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:
> 
> I just submitted:
> 
>   https://tools.ietf.org/html/draft-rescorla-tls-esni-00
> 
> This draft describes a DNS-based approach to doing encrypted SNI.
> 
> Previously, we had thought this wouldn't work because only sites that
> were particularly vulnerable would do it, and so the use of ESNI marks
> you out. The idea behind this draft is that there are a lot of sites
> which are hosted by -- and whose DNS is run by -- a large provider,
> and that provider can shift many if not all of its sites to ESNI at
> once, thus removing the "standing out" issue and making a DNS-based
> approach practical.

The recent Russia versus Telegram episode is kinda worrisome in this
regard. Basically, it looked like the actions that created massive
collaterial damage got at least two very large cloud provoders to
disable one technique of hiding the name of the target server.

> I am working on an implementation for NSS/Firefox and I know some
> others are working on their own implementations, so hopefully we can
> do some interop in Montreal.
> 
> This is at a pretty early stage, so comments, questions, defect
> reports welcome.

One thing I noticed: First there is this in evaluation:

7.2.4.  Do not stick out

   By sending SNI and ESNI values (with illegitimate digests), or by
   sending legitimate ESNI values for and "fake" SNI values, clients do
   not display clear signals of ESNI intent to passive eavesdroppers.

Is that suggesting to send fake ESNI values? If so, there is this in
endpoint behavior:

5.2.  Client-Facing Server Behavior

   o  If the EncryptedSNI.record_digest value does not match the
  cryptographic hash of any known ENSIKeys structure, it MUST abort
  the connection with an "illegal_parameter" alert.  This is
  necessary to prevent downgrade attacks.

So sending out fake ESNI values seems unsafe. My reading of that is
that if server supports ESNI, but is not configured, then it MUST
terminate (illegal_parameter) any handshake where ESNI extension
was offered in. But that behaviour would cause any split mode
handshakes to fail if backend supports ESNI.



-Ilari

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

[TLS] Seeking reviews for draft-ietf-mmusic-sdp-uks

[Martin Thomson]

TLS People,

The use of DTLS for real-time media doesn't get a whole lot of
attention here, but there's some work in MMUSIC on fixing a problem
with the interaction between an external signaling protocol and
(D)TLS.  This came out of some of the 1.3 analysis we were doing a
while back.  It's not a huge problem in a practical sense, but it's a
hole we believe is worth patching.

The MMUSIC chairs would like to move things along and feel like they
need more eyes on this.  As an author, I'd appreciate the same,
especially from a group that is more likely to understand the problem
space.

Cheers,
Martin

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

[TLS] Broken browser behaviour with SCADA TLS

[Peter Gutmann]

The following is an attempt to condense some off-list discussions with SCADA
folks about the broken behaviour of some browsers when it comes to interaction
with SCADA devices running TLS.  tl;dr: Chrome is practically unusable, at the
other end of the scale Firefox is fine, and there's something weird happening
with IE, possibly due to the use of non-CA-bought certificates.

A disclaimer for the following: This involved a lot of fiddling with server
configs to exercise all the different options and recreate what people were
reporting, so there may be some anomalies arising from getting a particular
combination of browser+server config wrong.  I can post a full trace of cipher
suites offered and accepted if anyone's interested.

Browser versions

IE = 11.0.9600.18538
Chrome = 67.0.3396.87
Firefox = last version before they broke all the extensions

DHE + RSA, ECDHE + ECDSA, ECDHE + RSA, RSA only:
Chrome:
[Connects correctly]
Firefox:
[Connects correctly]
IE:
[Does some weird fallback dance where it reconnects using TLS 1.0 several
 times when the cert is unrecognised and you click OK to accept it, then
 closes the connection after negotiating DHE at the point where the server has
 sent its Server Hello Done]

DHE + RSA, ECDHE + ECDSA, RSA only (using RSA server key, so in effect no 
ECDSA):
Chrome:
[Client negotiates non-PFS pure-RSA and ignores PFS DHE, then disconnects
 after sending/receiving Finished, then reconnects and repeats]
Firefox:
[Connects correctly]
IE:
[Does some weird fallback dance where it reconnects using TLS 1.0 several
 times when the cert is unrecognised and you click OK to accept it, then
 closes the connection after negotiating DHE at the point where the server has
 sent its Server Hello Done]

DHE + RSA, RSA only:

Chrome:
[Client negotiates non-PFS pure-RSA and ignores PFS DHE]
Firefox:
[Connects correctly]
IE:
[Does some weird fallback dance where it reconnects using TLS 1.0 several
 times when the cert is unrecognised and you click OK to accept it, then
 closes the connection after negotiating DHE at the point where the server has
 sent its Server Hello Done]

DHE + RSA only:

Chrome:
[Unable to connect, "The client and server don't support a common SSL protocol
 version or cipher suite"]
Firefox:
[Connects correctly]
IE:
[Does some weird fallback dance where it reconnects using TLS 1.0 several
 times when the cert is unrecognised and you click OK to accept it, then
 closes the connection after negotiating DHE at the point where the server has
 sent its Server Hello Done]

Summary:

Most broken browser unless exactly the right cipher suite is available: Chrome
Least broken browser: Firefox (at least for the last proper version they 
released)

Peter.

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