Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Nick Sullivan]

Sean,

We've had some additional discussions in person here at IETF 99 with folks
who were in the proxy certificates and short-lived certs camp, and we think
there is now more agreement that the mechanism described in this draft is
superior to the alternatives. I've included a summary of some of the pros
and cons of the approaches:


*Proxy certificates vs. Delegated Credentials*
*Pro proxy certificates*:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
*Con proxy certificates*:
- Proxy certificates adds additional complexity to the delegation other
than limiting the time period (full X.509, additional constraints  such as
hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as
part of TLS:
-- There have been problems and inconsistencies around pathlen and
constraints enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated
creds (which can easily be implemented in TLS as demonstrated by the 3
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE
cert. This is a binding weaker than delegated credentials which includes a
signature over the EE certificate.

*Short-lived certs vs. Delegated Credentials*
*Pro short-lived certs*:
- Short lived certs work with existing libraries, no new code changes.
*Con short-lived certs*:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be
logged in CT, which may bloat them).
- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must
provide proof of domain possession to CA vs. internally managed credential
minter for delegated credentials).
-- There is no fallback if the CA has outage. With delegated credentials
you can fall back to a LURK-style protocol with the long-lived certificate
key.

Given these comparisons, we think the proposed draft is the superior option
and would like to continue the discussion about adopting it.

Nick

On Fri, May 19, 2017 at 12:58 AM Sean Turner  wrote:

> All,
>
> During the WG call for adoption, a couple of questions were raised about
> comparison/analysis of sub-certs versus proxy and/or short-lived
> certificates.  There is some discussion currently in the draft, but the
> chairs feel that these issues need further discussion (and elaboration in
> the draft) prior to WG adoption.  So let’s keep the conversation going.
>
> J&S
>
> > On Apr 12, 2017, at 15:31, Sean Turner  wrote:
> >
> > All,
> >
> > At our IETF 98 session, there was support in the room to adopt
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on the
> list so please let the list know whether you support adoption of the draft
> and are willing to review/comment on the draft before 20170429.  If you
> object to its adoption, please let us know why.
> >
> > Clearly, the WG is going to need to work through the trade-offs between
> short-lived certificates and sub-certs because both seem, to some, to be
> addressing the same problem.
> >
> > Cheers,
> >
> > J&S
> >
> > [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts
>
> ___
> 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] WG Call for adoption of draft-rescorla-tls-subcerts

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Nick,

I am not against delegated credentials, in fact I think it’s a good thing per 
se.

I had expressed a couple of concerns at the time the call for adoption was 
first issued [1], which I think are still valid.

Could you please comment on / add them to your pro-cons analysis?

Cheers, thanks,
t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html

On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" 
mailto:tls-boun...@ietf.org> on behalf of 
nicholas.sulli...@gmail.com> wrote:

Sean,
We've had some additional discussions in person here at IETF 99 with folks who 
were in the proxy certificates and short-lived certs camp, and we think there 
is now more agreement that the mechanism described in this draft is superior to 
the alternatives. I've included a summary of some of the pros and cons of the 
approaches:
Proxy certificates vs. Delegated Credentials
Pro proxy certificates:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
Con proxy certificates:
- Proxy certificates adds additional complexity to the delegation other than 
limiting the time period (full X.509, additional constraints  such as hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as 
part of TLS:
-- There have been problems and inconsistencies around pathlen and constraints 
enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated 
creds (which can easily be implemented in TLS as demonstrated by the 3 
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE 
cert. This is a binding weaker than delegated credentials which includes a 
signature over the EE certificate.

Short-lived certs vs. Delegated Credentials
Pro short-lived certs:
- Short lived certs work with existing libraries, no new code changes.
Con short-lived certs:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be logged 
in CT, which may bloat them).
- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must 
provide proof of domain possession to CA vs. internally managed credential 
minter for delegated credentials).
-- There is no fallback if the CA has outage. With delegated credentials you 
can fall back to a LURK-style protocol with the long-lived certificate key.

Given these comparisons, we think the proposed draft is the superior option and 
would like to continue the discussion about adopting it.

Nick

On Fri, May 19, 2017 at 12:58 AM Sean Turner 
mailto:s...@sn3rd.com>> wrote:
All,

During the WG call for adoption, a couple of questions were raised about 
comparison/analysis of sub-certs versus proxy and/or short-lived certificates.  
There is some discussion currently in the draft, but the chairs feel that these 
issues need further discussion (and elaboration in the draft) prior to WG 
adoption.  So let’s keep the conversation going.

J&S

> On Apr 12, 2017, at 15:31, Sean Turner 
> mailto:s...@sn3rd.com>> wrote:
>
> All,
>
> At our IETF 98 session, there was support in the room to adopt 
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on the list 
> so please let the list know whether you support adoption of the draft and are 
> willing to review/comment on the draft before 20170429.  If you object to its 
> adoption, please let us know why.
>
> Clearly, the WG is going to need to work through the trade-offs between 
> short-lived certificates and sub-certs because both seem, to some, to be 
> addressing the same problem.
>
> Cheers,
>
> J&S
>
> [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts

___
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] WG Call for adoption of draft-rescorla-tls-subcerts

[Salz, Rich]

> Con short-lived certs:
> - Potentially problematic to the CT ecosystem (all certificates must be 
> logged in CT, which may bloat them).

That's a browser policy, not an IETF requirement, right?

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

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Salz, Rich]

> > Con short-lived certs:
> > - Potentially problematic to the CT ecosystem (all certificates must be
> logged in CT, which may bloat them).
> 
> That's a browser policy, not an IETF requirement, right?

And to be even more pedantic, it's the possible-future policy of Chrome, but 
not yet required nor implemented

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

Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13

[Eric Rescorla]

On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk  wrote:

> On 07/11/2017 03:50 PM, Eric Rescorla wrote:
>
>
>
> On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk 
> wrote:
>>
>>
>> Another question I also relates to 0-RTT, specifically with the freshness
>> checks and the case where the computed expected_arrival_time is in outside
>> "the window" by virtue of being in the future. (See the Note: at the end of
>> section 8.2.) (The case where the expected_arrival_time is in the past can
>> clearly be treated as "this is a stale request" and the current text about
>> aborting with "illegal_parameter" or rejecting 0-RTT but accepting the PSK
>> is acceptable, even if it doesn't give guidance as to what might cause
>> someone to pick one behavior or the other.)  I am wondering whether we
>> should consider this to be a potential attack and abort the connection.  I
>> concede that there are likely to be cases where this
>> situation occurs incidentally, for clients with extremely fast-running
>> clocks, and potential timezone/suspend-resume weirdness.  But there is also
>> the potential for a client that deliberately lies about its ticket age and
>> intends to replay the wire messages when the age becomes in window, or an
>> attacker that records the messages and knows that the client's clock is too
>> fast, or other cases.  (A client that deliberately does this could of
>> course just send the same application data later as well.)  If the time is
>> only a few seconds out of the window, then delaying a response until it is
>> in the window and only then entering it into the single-use cache might be
>> reasonable, but if the time is very far in the future, do we really want to
>> try to succeed in that case?
>>
>
> If the time is very far in the future, the text is supposed to tell you to
> fall back
> to 1-RTT...
>
>
> I agree that that is what the text currently says.  I'm questioning
> whether that's actually the behavior we want.
>
> That is, in this case, the CH+0RTT data can be replayed by an observer
> once enough time has elapsed that the expected_arrival_time is within the
> window, similar to one of the reordering attacks mentioned elsewhere.  We
> could add the CH to the strike register in this case, which would bloat its
> storage somewhat and have entries that take longer than the window to
> expire out.
>
> I don't have a good sense for how often we expect postdated CHs to occur
> and whether the ensuing breakage would be manageable, but I'm not sure that
> we've thought very hard as a group about this question.
>

I think post-dated are going to happen pretty often based on what I
understand from
Kyle and others. I wouldn't be comfortable with hard fail, especially given
that this
just seems like the dual of the other case. Adding the CH to the list seems
like
a problem because it might stay forever.

-Ekr


>
>
>
>
>
> It looks like we no longer do anything to obsolete/reserve/similar the
>> HashAlgorithm and SignatureAlgorithm registries; was that just an editorial
>> mixup or an intended change?
>>
>
> https://tlswg.github.io/draft-ietf-tls-iana-registry-
> updates/#orphaned-registries
> 
>
>
> Oh right, I forgot about that -- thanks.
>
>
> We removed the API guidance for separate APIs for read/writing early data
>> versus regular data, which I believe had consensus.  But I thought we were
>> going to say something carefully worded about having an API to determine
>> whether the handshake has completed (or client Finished has been validated,
>> or ...), and it looks like this is buried at the end of E.5(.0), with the
>> string "API" not appearing.  It might be useful to make this a little more
>> prominent/discoverable, whether by subsection heading or otherwise.
>>
>
> Suggestions welcome for where this would be better
>
>
> I'll see if I have time to think about it some more.
>
> -Ben
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Nick Sullivan]

It's a reality of the current CT system. If a crawler sees a short-lived
certificate, it will submit it to a CT log and it will be accepted.

On Tue, Jul 18, 2017 at 2:45 PM Salz, Rich  wrote:

> > Con short-lived certs:
> > - Potentially problematic to the CT ecosystem (all certificates must be
> logged in CT, which may bloat them).
>
> That's a browser policy, not an IETF requirement, right?
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Nick Sullivan]

Thomas,

Thanks for your comments. Let me see if I can summarize them:

- A disadvantage of delegated credentials vs short-lived certs is that it
requires client opt-in. This is also a disadvantage of proxy certificates.
If client support is below 100%, a LURK-type system may be required to keep
long-term private keys off TLS termination endpoints.
- A disadvantage of delegated credentials is that it requires software
updates on both client and server. This is also a disadvantage of proxy
certificates. I think this is covered by my point below: "Short lived certs
work with existing libraries, no new code changes."
- An advantage of short-lived certificates is that there is an audit log by
a third party (either the CA's internal logs and optionally Certificate
Transparency logs).

I should state that short-lived certificates are possible right now and
it's supported by some CAs, though not necessarily at the scale needed to
provide, say, a unique 7-day certificate for each server of a large
Internet company. This draft's advantages apply most strongly to
organizations who don't want to tie their ability to have functional TLS on
the ability for CAs to maintain high-availability issuance services.  How
much Delegated Credentials can be rotated and diversified inside an
organization is only limited by the operational ability of the organization
that has control of the EE private key.

Nick

On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) <
thomas.foss...@nokia.com> wrote:

> Hi Nick,
>
>
>
> I am not against delegated credentials, in fact I think it’s a good thing
> per se.
>
>
>
> I had expressed a couple of concerns at the time the call for adoption was
> first issued [1], which I think are still valid.
>
>
>
> Could you please comment on / add them to your pro-cons analysis?
>
>
>
> Cheers, thanks,
>
> t
>
>
>
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html
>
>
>
> On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" <
> tls-boun...@ietf.org on behalf of nicholas.sulli...@gmail.com> wrote:
>
>
>
> Sean,
>
> We've had some additional discussions in person here at IETF 99 with folks
> who were in the proxy certificates and short-lived certs camp, and we think
> there is now more agreement that the mechanism described in this draft is
> superior to the alternatives. I've included a summary of some of the pros
> and cons of the approaches:
>
> *Proxy certificates vs. Delegated Credentials*
>
> *Pro proxy certificates*:
>
> - Already deployed in some industries, though not on the Web.
>
> - Fits the conceptual model that public key == certificate.
>
> *Con proxy certificates*:
>
> - Proxy certificates adds additional complexity to the delegation other
> than limiting the time period (full X.509, additional constraints  such as
> hostname).
>
> - Encourages implementers to reuse PKIX libraries rather than build code
> as part of TLS:
> -- There have been problems and inconsistencies around pathlen and
> constraints enforcement in existing PKIX libraries.
> -- Modifying these libraries is more complex and risk prone than delegated
> creds (which can easily be implemented in TLS as demonstrated by the 3
> interoperable implementations at the IETF 98 hackathon).
>
> - In proxy certificates, pathing is SKI dependent, not directly tied to EE
> cert. This is a binding weaker than delegated credentials which includes a
> signature over the EE certificate.
>
>
>
> *Short-lived certs vs. Delegated Credentials*
>
> *Pro short-lived certs*:
>
> - Short lived certs work with existing libraries, no new code changes.
>
> *Con short-lived certs*:
>
> - Not widely available from CAs, especially for EV.
>
> - Potentially problematic to the CT ecosystem (all certificates must be
> logged in CT, which may bloat them).
>
> - Introduces a high-risk operational dependency on external party:
> -- Requires frequent exchanges with an external Certificate Authority
> (must provide proof of domain possession to CA vs. internally managed
> credential minter for delegated credentials).
>
> -- There is no fallback if the CA has outage. With delegated credentials
> you can fall back to a LURK-style protocol with the long-lived certificate
> key.
>
>
>
> Given these comparisons, we think the proposed draft is the superior
> option and would like to continue the discussion about adopting it.
>
>
>
> Nick
>
>
>
> On Fri, May 19, 2017 at 12:58 AM Sean Turner  wrote:
>
> All,
>
> During the WG call for adoption, a couple of questions were raised about
> comparison/analysis of sub-certs versus proxy and/or short-lived
> certificates.  There is some discussion currently in the draft, but the
> chairs feel that these issues need further discussion (and elaboration in
> the draft) prior to WG adoption.  So let’s keep the conversation going.
>
> J&S
>
> > On Apr 12, 2017, at 15:31, Sean Turner  wrote:
> >
> > All,
> >
> > At our IETF 98 session, there was support in the room to adopt
> draft-rescorla-t

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Salz, Rich]

Okay, you said “potentially” a problem.  I guess so.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] possible new work item: not breaking TLS

[Stephen Farrell]

Hiya,

Thanks to the chairs for allocating some agenda time for
discussion of this topic at tomorrow's session. I plan to
more or less present [1] instead of using slides, so if
folks have a chance to read it over before we get to that
agenda item tomorrow that should help speed things up a
bit.

I'm still happy to take corrections, comments and suggestions
however folks would like to provide those but plan to be at
the social event tonight so likely won't do more updates to
the text before tomorrow morning (semi-inebriated additions
being a bad plan, even if nowhere near as bad a plan as
draft-green:-)

Cheers,
S.

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

On 13/07/17 13:00, Stephen Farrell wrote:
> 
> Hi again TLS WG chairs,
> 
> I've done a bit more work on the collection of arguments
> against the latest break-TLS proposal. [1] I plan to keep
> working on that so more input is welcome. (Corrections
> where I've gotten stuff wrong are even more welcome.)
> 
> I'd like to again request some time on the agenda to
> allow discussion of those points in a more structured
> manner than will be possible during the mic-line scrum
> that'll likely follow a sales-pitch for draft-green.
> 
> I'd also like to ask the WG if we think it'd be useful
> to document the arguments against that and other "let's
> break-tls" proposals we've seen in the past in an RFC.
> If people think it would be useful, I'd be willing to
> do work to edit such a draft, or help edit that.
> 
> Thanks,
> S.
> 
> [1] https://github.com/sftcd/tinfoil
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



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

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Nick,

Your write-up is spot on, thanks.

Let me comment on a few points:

“How much Delegated Credentials can be rotated and diversified inside an 
organization is only limited by the operational ability of the organization 
that has control of the EE private key.”

The self-service/agile nature of D-C is great. With that, though, comes a cost 
of ownership that maybe not all players can afford.

- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must 
provide proof of domain possession to CA vs. internally managed credential 
minter for delegated credentials).

There should be ways to mitigate this, say allowing the next S-T in line to be 
available “long enough” before it becomes active.

-- There is no fallback if the CA has outage. With delegated credentials you 
can fall back to a LURK-style protocol with the long-lived certificate key.

I understand the logics but, since LURK boxes don’t scale, the cost to cover 
your entire footprint for the sporadic cases when the CA is down might be a bit 
prohibitive.

Cheers, t


On 18/07/2017, 14:35, "Nick Sullivan" 
mailto:nicholas.sulli...@gmail.com>> wrote:

Thomas,
Thanks for your comments. Let me see if I can summarize them:
- A disadvantage of delegated credentials vs short-lived certs is that it 
requires client opt-in. This is also a disadvantage of proxy certificates. If 
client support is below 100%, a LURK-type system may be required to keep 
long-term private keys off TLS termination endpoints.
- A disadvantage of delegated credentials is that it requires software updates 
on both client and server. This is also a disadvantage of proxy certificates. I 
think this is covered by my point below: "Short lived certs work with existing 
libraries, no new code changes."
- An advantage of short-lived certificates is that there is an audit log by a 
third party (either the CA's internal logs and optionally Certificate 
Transparency logs).
I should state that short-lived certificates are possible right now and it's 
supported by some CAs, though not necessarily at the scale needed to provide, 
say, a unique 7-day certificate for each server of a large Internet company. 
This draft's advantages apply most strongly to organizations who don't want to 
tie their ability to have functional TLS on the ability for CAs to maintain 
high-availability issuance services.  How much Delegated Credentials can be 
rotated and diversified inside an organization is only limited by the 
operational ability of the organization that has control of the EE private key.

Nick

On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) 
mailto:thomas.foss...@nokia.com>> wrote:
Hi Nick,

I am not against delegated credentials, in fact I think it’s a good thing per 
se.

I had expressed a couple of concerns at the time the call for adoption was 
first issued [1], which I think are still valid.

Could you please comment on / add them to your pro-cons analysis?

Cheers, thanks,
t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html

On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" 
mailto:tls-boun...@ietf.org> on behalf of 
nicholas.sulli...@gmail.com> wrote:

Sean,
We've had some additional discussions in person here at IETF 99 with folks who 
were in the proxy certificates and short-lived certs camp, and we think there 
is now more agreement that the mechanism described in this draft is superior to 
the alternatives. I've included a summary of some of the pros and cons of the 
approaches:
Proxy certificates vs. Delegated Credentials
Pro proxy certificates:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
Con proxy certificates:
- Proxy certificates adds additional complexity to the delegation other than 
limiting the time period (full X.509, additional constraints  such as hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as 
part of TLS:
-- There have been problems and inconsistencies around pathlen and constraints 
enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated 
creds (which can easily be implemented in TLS as demonstrated by the 3 
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE 
cert. This is a binding weaker than delegated credentials which includes a 
signature over the EE certificate.

Short-lived certs vs. Delegated Credentials
Pro short-lived certs:
- Short lived certs work with existing libraries, no new code changes.
Con short-lived certs:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be logged 
in CT, which may bloat them).
- Introduces a high-risk operational dependency on external 

Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

[Dan Wing]

> On Jul 16, 2017, at 8:39 PM, yinxinxing  wrote:
> 
> Hi Wing,
> 
> I noticed that Helloverifyrequest is optional by the server and used when DOS 
> is to be mitigated. 
> 
> But from practical use cases, the IOT server may not have dedicated anti-DOS 
> mechanism. 
> 
> If there is a more power-saving solution with the function of DOS mitigation 
> retained, and don't need to bother the server(customer) to deploy anti-DOS 
> devices, why not have a try?  

Sure.  You might work with the authors of draft-mavrogiannopoulos-tls-cid to 
add more considerations around denial of service, perhaps also a longer cid as 
you suggested earlier.

-d


> Regards,
> Yin Xinxing
> 
> -邮件原件-
> 发件人: yinxinxing 
> 发送时间: 2017年7月13日 16:56
> 收件人: 'Dan Wing'
> 抄送: tls@ietf.org; Sean Turner
> 主题: 答复: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
> with high power consumption in DTLS1.2
> 
> Hi Wing,
> 
> Please see the comments inline
> 
> Regards,
> Yin Xinxing
> 
> -邮件原件-
> 发件人: Dan Wing [mailto:danw...@gmail.com] 
> 发送时间: 2017年7月13日 12:35
> 收件人: yinxinxing
> 抄送: tls@ietf.org; Sean Turner
> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
> with high power consumption in DTLS1.2
> 
> 
>> On Jul 12, 2017, at 7:11 PM, yinxinxing  wrote:
>> 
>> Thanks Wing,
>> 
>> Please see my comments inline.
>> 
>> Regards,
>> Yin Xinxing
>> 
>> -邮件原件-
>> 发件人: Dan Wing [mailto:danw...@gmail.com] 
>> 发送时间: 2017年7月13日 8:52
>> 收件人: yinxinxing
>> 抄送: tls@ietf.org; Sean Turner
>> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
>> with high power consumption in DTLS1.2
>> 
>> 
>>> On Jul 12, 2017, at 5:21 PM, yinxinxing  wrote:
>>> 
>>> Hi Dan Wing,
>>> 
>>> Thanks for your comments.
>>> 
>>> Please see my comments inline.
>>> 
>>> Regards,
>>> Yin Xinxing
>>> 
>>> -邮件原件-
>>> 发件人: Dan Wing [mailto:danw...@gmail.com] 
>>> 发送时间: 2017年7月13日 1:09
>>> 收件人: yinxinxing
>>> 抄送: tls@ietf.org; Sean Turner
>>> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
>>> with high power consumption in DTLS1.2
>>> 
>>> 
 On Jul 12, 2017, at 7:56 AM, Sean Turner  wrote:
 
 
> On Jul 6, 2017, at 23:04, yinxinxing  wrote:
> 
> Hi all,
> 
> The NAT table expiring problem mentioned in the  following email should 
> also be considered in DTLS1.2 as an extension.
> 
> The value and necessity are as follows.
> 
> 1. Essentially, NAT expiring problem causing DTLS renegotiation with high 
> power consumption is existing in DTLS 1.2. Even if we solve this in 
> DTLS1.3, this problem still exist for products using DTLS1.2.
> Currently, many IOT products using DTLS 1.2 are going to be deployed 
> commercially, such as intelligent water/gas meter. These meters usually 
> have limited battery and low cost. To be more accurate, the battery of 
> the chip module of the intelligent water/gas meter are required to last 
> for 10 years. These lead to an exercise strict control over the power 
> consumption of the chip module. NAT expiring problem causing DTLS 
> renegotiation with high power consumption is a bottleneck of these IOT 
> devices. According to our experimental data, under the worst coverage 
> level (ECL2), power consumption of the chip module when DTLS is embedded 
> increases by nearly 60%. Therefore, there should be a solution to solve 
> the urgent problem to match the low-cost and low-battery feature of the 
> IOT devices in DTLS 1.2.
 
 I have to ask whether these IoT devices are updatable?
 
> 2. DTLS 1.3 will be standardized in 2018, but the corresponding open 
> source code will be available about one year later after the 
> standardization. At present, large-scale commercial IOT industry 
> deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope 
> that the above problem could be solved in DTLS 1.2 as soon as possible.
 
 On this point, I’m hoping that you’ll be wrong ;). From the list of TLS 
 implementations found here:
 https://github.com/tlswg/tls13-spec/wiki/Implementations
 and assuming there is as much enthusiasm to implement DTLS1.3 as there was 
 for TLS1.3 then I’m hoping that the DTLS implementations will be ready 
 much sooner than a year after publication (they might be ready before the 
 RFC is published).
>>> 
>>> 
 Yin Xinxing,
>>> 
 While waiting for cid, perhaps today do session resumption (RFC5077), 
 anytime the client has reason to suspect their UDP port or IP address 
 might have changed -- such as it's been longer than, say, 30 seconds since 
 last UDP transmission.  (The problem isn't solely NAT; there are several 
 ISPs that change subscriber's IP address, >also forcing re-negotiation of 
 DTLS security association.  Less frequent than NATs timing out UDP, of 
 course.)
>>> 
 -d
>>> [Yin] 

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Watson Ladd]

On Jul 18, 2017 9:26 AM, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <
thomas.foss...@nokia.com> wrote:

Hi Nick,



Your write-up is spot on, thanks.



Let me comment on a few points:



“How much Delegated Credentials can be rotated and diversified inside an
organization is only limited by the operational ability of the organization
that has control of the EE private key.”



The self-service/agile nature of D-C is great. With that, though, comes a
cost of ownership that maybe not all players can afford.


Outsourcing to get to something like short lived certs is possible here. If
you can put a cert on a webserver I'm sure you can put it on a delegated
credential creator and point your server at it.



- Introduces a high-risk operational dependency on external party:

-- Requires frequent exchanges with an external Certificate Authority (must
provide proof of domain possession to CA vs. internally managed credential
minter for delegated credentials).



There should be ways to mitigate this, say allowing the next S-T in line to
be available “long enough” before it becomes active.



-- There is no fallback if the CA has outage. With delegated credentials
you can fall back to a LURK-style protocol with the long-lived certificate
key.



I understand the logics but, since LURK boxes don’t scale, the cost to
cover your entire footprint for the sporadic cases when the CA is down
might be a bit prohibitive.


CA reliability is not good.



Cheers, t





On 18/07/2017, 14:35, "Nick Sullivan"  wrote:



Thomas,

Thanks for your comments. Let me see if I can summarize them:

- A disadvantage of delegated credentials vs short-lived certs is that it
requires client opt-in. This is also a disadvantage of proxy certificates.
If client support is below 100%, a LURK-type system may be required to keep
long-term private keys off TLS termination endpoints.
- A disadvantage of delegated credentials is that it requires software
updates on both client and server. This is also a disadvantage of proxy
certificates. I think this is covered by my point below: "Short lived certs
work with existing libraries, no new code changes."

- An advantage of short-lived certificates is that there is an audit log by
a third party (either the CA's internal logs and optionally Certificate
Transparency logs).

I should state that short-lived certificates are possible right now and
it's supported by some CAs, though not necessarily at the scale needed to
provide, say, a unique 7-day certificate for each server of a large
Internet company. This draft's advantages apply most strongly to
organizations who don't want to tie their ability to have functional TLS on
the ability for CAs to maintain high-availability issuance services.  How
much Delegated Credentials can be rotated and diversified inside an
organization is only limited by the operational ability of the organization
that has control of the EE private key.



Nick



On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) <
thomas.foss...@nokia.com> wrote:

Hi Nick,



I am not against delegated credentials, in fact I think it’s a good thing
per se.



I had expressed a couple of concerns at the time the call for adoption was
first issued [1], which I think are still valid.



Could you please comment on / add them to your pro-cons analysis?



Cheers, thanks,

t



[1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html



On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan"  wrote:



Sean,

We've had some additional discussions in person here at IETF 99 with folks
who were in the proxy certificates and short-lived certs camp, and we think
there is now more agreement that the mechanism described in this draft is
superior to the alternatives. I've included a summary of some of the pros
and cons of the approaches:

*Proxy certificates vs. Delegated Credentials*

*Pro proxy certificates*:

- Already deployed in some industries, though not on the Web.

- Fits the conceptual model that public key == certificate.

*Con proxy certificates*:

- Proxy certificates adds additional complexity to the delegation other
than limiting the time period (full X.509, additional constraints  such as
hostname).

- Encourages implementers to reuse PKIX libraries rather than build code as
part of TLS:
-- There have been problems and inconsistencies around pathlen and
constraints enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated
creds (which can easily be implemented in TLS as demonstrated by the 3
interoperable implementations at the IETF 98 hackathon).

- In proxy certificates, pathing is SKI dependent, not directly tied to EE
cert. This is a binding weaker than delegated credentials which includes a
signature over the EE certificate.



*Short-lived certs vs. Delegated Credentials*

*Pro short-lived certs*:

- Short lived certs work with existing libraries, no new code changes.

*Con short-lived certs*:

-

Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13

[Benjamin Kaduk]

On 07/18/2017 08:07 AM, Eric Rescorla wrote:
>
>
> On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk  > wrote:
>
>
> That is, in this case, the CH+0RTT data can be replayed by an
> observer once enough time has elapsed that the
> expected_arrival_time is within the window, similar to one of the
> reordering attacks mentioned elsewhere.  We could add the CH to
> the strike register in this case, which would bloat its storage
> somewhat and have entries that take longer than the window to
> expire out.
>
> I don't have a good sense for how often we expect postdated CHs to
> occur and whether the ensuing breakage would be manageable, but
> I'm not sure that we've thought very hard as a group about this
> question.
>
>
> I think post-dated are going to happen pretty often based on what I
> understand from
> Kyle and others. I wouldn't be comfortable with hard fail, especially
> given that this
> just seems like the dual of the other case. Adding the CH to the list
> seems like
> a problem because it might stay forever.
>

The "stay forever" part is awkward, yes.  It would be great if Kyle/etc.
could say a bit about why post-dated seems likely on the list, but I
guess for the purposes of WGLC we can consider this comment resolved.

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

Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13

[Kyle Nekritz]

Timestamps outside the expected window can happen due to variances in RTT, 
client clock skew, etc. (we see around .1% of clients outside of a 30s window 
for example). Not likely to happen on a given connection, but it certainly 
happens enough that you don’t want to abort the connection (rather than 
allowing 1-RTT) without reason. I’m not sure I understand the desire to abort 
these connections. What value does it provide? The timestamp mechanism does not 
provide protection against a malicious client that has possession of the PSK 
key.

If the server is 100% sure that a CH is replayed it is more reasonable to abort 
the connection, but I think it should be explicit to the client that that is 
the reason for the error (ie using a new alert type rather than 
illegal_parameter) so the client can know to retry without 0-RTT. I’m also 
slightly concerned that it allows a passive attacker to cause connection 
failures if it can front-run a copy of the CH to the server, and I still don’t 
think it is providing much value.

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Benjamin Kaduk
Sent: Tuesday, July 18, 2017 2:11 PM
To: Eric Rescorla 
Cc:  
Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13

On 07/18/2017 08:07 AM, Eric Rescorla wrote:



On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk 
mailto:bka...@akamai.com>> wrote:

That is, in this case, the CH+0RTT data can be replayed by an observer once 
enough time has elapsed that the expected_arrival_time is within the window, 
similar to one of the reordering attacks mentioned elsewhere.  We could add the 
CH to the strike register in this case, which would bloat its storage somewhat 
and have entries that take longer than the window to expire out.

I don't have a good sense for how often we expect postdated CHs to occur and 
whether the ensuing breakage would be manageable, but I'm not sure that we've 
thought very hard as a group about this question.

I think post-dated are going to happen pretty often based on what I understand 
from
Kyle and others. I wouldn't be comfortable with hard fail, especially given 
that this
just seems like the dual of the other case. Adding the CH to the list seems like
a problem because it might stay forever.


The "stay forever" part is awkward, yes.  It would be great if Kyle/etc. could 
say a bit about why post-dated seems likely on the list, but I guess for the 
purposes of WGLC we can consider this comment resolved.

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

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Yaron Sheffer]

On 18/07/17 18:34, Watson Ladd wrote:


I understand the logics but, since LURK boxes don’t scale, the
cost to cover your entire footprint for the sporadic cases when
the CA is down might be a bit prohibitive.


CA reliability is not good.


From my own experience, I agree that CA reliability is "not good". 
However if I'm using short-term certs with say, a 7 day validity, and 
(per draft-ietf-acme-star) the next certificate is issued halfway 
through this period, it means that the CA has to to be unavailable for 
all of 3.5 days for the failure to affect the delegated site. That's a 
lot, even for a CA.


On the other hand the LURK signing box (though managed by the same 
organization, which is a clear benefit) needs to be available at the 
same level of the delegated site - 99.99% of the time or whatever your 
standard is.


Thanks,
Yaron

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

[TLS] 答复: Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

[yinxinxing]

Thanks Wing.

I am glad to discuss the technical details of CID draft with Hannes, Thomas and 
Nikos. 

Regards,
Yin Xinxing

-邮件原件-
发件人: Dan Wing [mailto:danw...@gmail.com] 
发送时间: 2017年7月19日 0:34
收件人: yinxinxing
抄送: tls@ietf.org; Sean Turner
主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with 
high power consumption in DTLS1.2


> On Jul 16, 2017, at 8:39 PM, yinxinxing  wrote:
> 
> Hi Wing,
> 
> I noticed that Helloverifyrequest is optional by the server and used when DOS 
> is to be mitigated. 
> 
> But from practical use cases, the IOT server may not have dedicated anti-DOS 
> mechanism. 
> 
> If there is a more power-saving solution with the function of DOS mitigation 
> retained, and don't need to bother the server(customer) to deploy anti-DOS 
> devices, why not have a try?  

Sure.  You might work with the authors of draft-mavrogiannopoulos-tls-cid to 
add more considerations around denial of service, perhaps also a longer cid as 
you suggested earlier.

-d


> Regards,
> Yin Xinxing
> 
> -邮件原件-
> 发件人: yinxinxing
> 发送时间: 2017年7月13日 16:56
> 收件人: 'Dan Wing'
> 抄送: tls@ietf.org; Sean Turner
> 主题: 答复: [TLS] Solving the NAT expiring problem causing DTLS 
> renegotiation with high power consumption in DTLS1.2
> 
> Hi Wing,
> 
> Please see the comments inline
> 
> Regards,
> Yin Xinxing
> 
> -邮件原件-
> 发件人: Dan Wing [mailto:danw...@gmail.com]
> 发送时间: 2017年7月13日 12:35
> 收件人: yinxinxing
> 抄送: tls@ietf.org; Sean Turner
> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS 
> renegotiation with high power consumption in DTLS1.2
> 
> 
>> On Jul 12, 2017, at 7:11 PM, yinxinxing  wrote:
>> 
>> Thanks Wing,
>> 
>> Please see my comments inline.
>> 
>> Regards,
>> Yin Xinxing
>> 
>> -邮件原件-
>> 发件人: Dan Wing [mailto:danw...@gmail.com]
>> 发送时间: 2017年7月13日 8:52
>> 收件人: yinxinxing
>> 抄送: tls@ietf.org; Sean Turner
>> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS 
>> renegotiation with high power consumption in DTLS1.2
>> 
>> 
>>> On Jul 12, 2017, at 5:21 PM, yinxinxing  wrote:
>>> 
>>> Hi Dan Wing,
>>> 
>>> Thanks for your comments.
>>> 
>>> Please see my comments inline.
>>> 
>>> Regards,
>>> Yin Xinxing
>>> 
>>> -邮件原件-
>>> 发件人: Dan Wing [mailto:danw...@gmail.com]
>>> 发送时间: 2017年7月13日 1:09
>>> 收件人: yinxinxing
>>> 抄送: tls@ietf.org; Sean Turner
>>> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS 
>>> renegotiation with high power consumption in DTLS1.2
>>> 
>>> 
 On Jul 12, 2017, at 7:56 AM, Sean Turner  wrote:
 
 
> On Jul 6, 2017, at 23:04, yinxinxing  wrote:
> 
> Hi all,
> 
> The NAT table expiring problem mentioned in the  following email should 
> also be considered in DTLS1.2 as an extension.
> 
> The value and necessity are as follows.
> 
> 1. Essentially, NAT expiring problem causing DTLS renegotiation with high 
> power consumption is existing in DTLS 1.2. Even if we solve this in 
> DTLS1.3, this problem still exist for products using DTLS1.2.
> Currently, many IOT products using DTLS 1.2 are going to be deployed 
> commercially, such as intelligent water/gas meter. These meters usually 
> have limited battery and low cost. To be more accurate, the battery of 
> the chip module of the intelligent water/gas meter are required to last 
> for 10 years. These lead to an exercise strict control over the power 
> consumption of the chip module. NAT expiring problem causing DTLS 
> renegotiation with high power consumption is a bottleneck of these IOT 
> devices. According to our experimental data, under the worst coverage 
> level (ECL2), power consumption of the chip module when DTLS is embedded 
> increases by nearly 60%. Therefore, there should be a solution to solve 
> the urgent problem to match the low-cost and low-battery feature of the 
> IOT devices in DTLS 1.2.
 
 I have to ask whether these IoT devices are updatable?
 
> 2. DTLS 1.3 will be standardized in 2018, but the corresponding open 
> source code will be available about one year later after the 
> standardization. At present, large-scale commercial IOT industry 
> deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope 
> that the above problem could be solved in DTLS 1.2 as soon as possible.
 
 On this point, I’m hoping that you’ll be wrong ;). From the list of TLS 
 implementations found here:
 https://github.com/tlswg/tls13-spec/wiki/Implementations
 and assuming there is as much enthusiasm to implement DTLS1.3 as there was 
 for TLS1.3 then I’m hoping that the DTLS implementations will be ready 
 much sooner than a year after publication (they might be ready before the 
 RFC is published).
>>> 
>>> 
 Yin Xinxing,
>>> 
 While waiting for cid, perhaps today do session resumption 
 (RFC5077), anytime the client has reason to suspect their UDP port 
 o

[TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt

[Kazuho Oku]

Hi,

I am happy to see us having discussions on how to protected SNI. I am
also happy to see that draft-huitema-tls-sni-encryption [1] proposes
actual methods that we might want to use, and that the I-D discusses
about various attack vectors that we need to be aware of.

On the other hand, as stated on the mailing list an on the mic, I am
not super happy with the fact that the proposed methods have a
negative impact on connection establishment time.

So here goes my straw-man proposal, as an Internet Draft:
https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.

In essence, the draft proposes of sending information (e.g.,
semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.

Since DNS queries can run in parallel, there would be no negative
performance impact, as long as DNS responses can be obtained in a
single RTT.

The draft mainly discusses about sending a signed bootstrap
information together with the certificate chain, since doing so is not
only more secure but opens up other possibilities in the future (such
as 0-RTT full handshake). However, since transmitting a bootstrap
record with digital signature and identity is unlikely to fit in a
single packet (and therefore will have negative performance impact
until DNS over TLS or QUIC becomes popular), the draft also discusses
the possibility of sending the EC(DH) key unsigned in the "Things to
Consider" section.

I would appreciate it if you could give me comments / suggestions on
the proposed approach. Thank you in advance.

[1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/


-- Forwarded message --
From:  
Date: 2017-07-19 5:38 GMT+02:00
Subject: New Version Notification for draft-kazuho-protected-sni-00.txt
To: Kazuho Oku 



A new version of I-D, draft-kazuho-protected-sni-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name:   draft-kazuho-protected-sni
Revision:   00
Title:  TLS Extensions for Protecting SNI
Document date:  2017-07-19
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-protected-sni-00.txt
Status: https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/
Htmlized:   https://tools.ietf.org/html/draft-kazuho-protected-sni-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00


Abstract:
   This memo introduces TLS extensions and a DNS Resource Record Type
   that can be used to protect attackers from obtaining the value of the
   Server Name Indication extension being transmitted over a Transport
   Layer Security (TLS) version 1.3 handshake.




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

The IETF Secretariat



-- 
Kazuho Oku

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

Re: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt

[Tom Ritter]

If I remember correctly, the idea of enabling SNI encryption (and
0RTT) via DNS had been brought up very early on in the discussion.
draft-nygren-service-bindings was the first (only? major?) concrete
proposal.

In general, I think the feedback was "DNS gets filtered to only
A/CNAME records so frequently that anything that relies on other DNS
records isn't going to work an appreciable portion of the time".

I'm disappointed by this also; but as we are also trying to deploy DNS
privacy - mechanisms that rely on an easily surveilled, censored, or
blocked mechanism to enable other sorts of privacy are concerning.

-tom


On 18 July 2017 at 22:42, Kazuho Oku  wrote:
> Hi,
>
> I am happy to see us having discussions on how to protected SNI. I am
> also happy to see that draft-huitema-tls-sni-encryption [1] proposes
> actual methods that we might want to use, and that the I-D discusses
> about various attack vectors that we need to be aware of.
>
> On the other hand, as stated on the mailing list an on the mic, I am
> not super happy with the fact that the proposed methods have a
> negative impact on connection establishment time.
>
> So here goes my straw-man proposal, as an Internet Draft:
> https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.
>
> In essence, the draft proposes of sending information (e.g.,
> semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
> DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.
>
> Since DNS queries can run in parallel, there would be no negative
> performance impact, as long as DNS responses can be obtained in a
> single RTT.
>
> The draft mainly discusses about sending a signed bootstrap
> information together with the certificate chain, since doing so is not
> only more secure but opens up other possibilities in the future (such
> as 0-RTT full handshake). However, since transmitting a bootstrap
> record with digital signature and identity is unlikely to fit in a
> single packet (and therefore will have negative performance impact
> until DNS over TLS or QUIC becomes popular), the draft also discusses
> the possibility of sending the EC(DH) key unsigned in the "Things to
> Consider" section.
>
> I would appreciate it if you could give me comments / suggestions on
> the proposed approach. Thank you in advance.
>
> [1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/
>
>
> -- Forwarded message --
> From:  
> Date: 2017-07-19 5:38 GMT+02:00
> Subject: New Version Notification for draft-kazuho-protected-sni-00.txt
> To: Kazuho Oku 
>
>
>
> A new version of I-D, draft-kazuho-protected-sni-00.txt
> has been successfully submitted by Kazuho Oku and posted to the
> IETF repository.
>
> Name:   draft-kazuho-protected-sni
> Revision:   00
> Title:  TLS Extensions for Protecting SNI
> Document date:  2017-07-19
> Group:  Individual Submission
> Pages:  9
> URL:
> https://www.ietf.org/internet-drafts/draft-kazuho-protected-sni-00.txt
> Status: https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/
> Htmlized:   https://tools.ietf.org/html/draft-kazuho-protected-sni-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00
>
>
> Abstract:
>This memo introduces TLS extensions and a DNS Resource Record Type
>that can be used to protect attackers from obtaining the value of the
>Server Name Indication extension being transmitted over a Transport
>Layer Security (TLS) version 1.3 handshake.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> --
> Kazuho Oku
>
> ___
> 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: New Version Notification for draft-kazuho-protected-sni-00.txt

[Kazuho Oku]

Hi,

Thank you for the response.

I was not aware that the penetration rates of minor DNS records were
low. I will read the I-D and the mailing list archive.

OTOH, I think that the penetration rate being low might not be a
killer for the proposal, since in the short term, SNI encryption can
be an opportunistic feature, considering the fact that DNS packets
will be sent in cleartext anyways.

It might be possible to query for the A record and the bootstrap
record simultaneously and activate SNI protection only if responses to
both queries are obtained.

2017-07-19 6:03 GMT+02:00 Tom Ritter :
> If I remember correctly, the idea of enabling SNI encryption (and
> 0RTT) via DNS had been brought up very early on in the discussion.
> draft-nygren-service-bindings was the first (only? major?) concrete
> proposal.
>
> In general, I think the feedback was "DNS gets filtered to only
> A/CNAME records so frequently that anything that relies on other DNS
> records isn't going to work an appreciable portion of the time".
>
> I'm disappointed by this also; but as we are also trying to deploy DNS
> privacy - mechanisms that rely on an easily surveilled, censored, or
> blocked mechanism to enable other sorts of privacy are concerning.
>
> -tom
>
>
> On 18 July 2017 at 22:42, Kazuho Oku  wrote:
>> Hi,
>>
>> I am happy to see us having discussions on how to protected SNI. I am
>> also happy to see that draft-huitema-tls-sni-encryption [1] proposes
>> actual methods that we might want to use, and that the I-D discusses
>> about various attack vectors that we need to be aware of.
>>
>> On the other hand, as stated on the mailing list an on the mic, I am
>> not super happy with the fact that the proposed methods have a
>> negative impact on connection establishment time.
>>
>> So here goes my straw-man proposal, as an Internet Draft:
>> https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.
>>
>> In essence, the draft proposes of sending information (e.g.,
>> semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
>> DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.
>>
>> Since DNS queries can run in parallel, there would be no negative
>> performance impact, as long as DNS responses can be obtained in a
>> single RTT.
>>
>> The draft mainly discusses about sending a signed bootstrap
>> information together with the certificate chain, since doing so is not
>> only more secure but opens up other possibilities in the future (such
>> as 0-RTT full handshake). However, since transmitting a bootstrap
>> record with digital signature and identity is unlikely to fit in a
>> single packet (and therefore will have negative performance impact
>> until DNS over TLS or QUIC becomes popular), the draft also discusses
>> the possibility of sending the EC(DH) key unsigned in the "Things to
>> Consider" section.
>>
>> I would appreciate it if you could give me comments / suggestions on
>> the proposed approach. Thank you in advance.
>>
>> [1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/
>>
>>
>> -- Forwarded message --
>> From:  
>> Date: 2017-07-19 5:38 GMT+02:00
>> Subject: New Version Notification for draft-kazuho-protected-sni-00.txt
>> To: Kazuho Oku 
>>
>>
>>
>> A new version of I-D, draft-kazuho-protected-sni-00.txt
>> has been successfully submitted by Kazuho Oku and posted to the
>> IETF repository.
>>
>> Name:   draft-kazuho-protected-sni
>> Revision:   00
>> Title:  TLS Extensions for Protecting SNI
>> Document date:  2017-07-19
>> Group:  Individual Submission
>> Pages:  9
>> URL:
>> https://www.ietf.org/internet-drafts/draft-kazuho-protected-sni-00.txt
>> Status: https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/
>> Htmlized:   https://tools.ietf.org/html/draft-kazuho-protected-sni-00
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00
>>
>>
>> Abstract:
>>This memo introduces TLS extensions and a DNS Resource Record Type
>>that can be used to protect attackers from obtaining the value of the
>>Server Name Indication extension being transmitted over a Transport
>>Layer Security (TLS) version 1.3 handshake.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>> --
>> Kazuho Oku
>>
>> ___
>> 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] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt

[Ilari Liusvaara]

On Wed, Jul 19, 2017 at 05:42:24AM +0200, Kazuho Oku wrote:
> Hi,
> 
> I am happy to see us having discussions on how to protected SNI. I am
> also happy to see that draft-huitema-tls-sni-encryption [1] proposes
> actual methods that we might want to use, and that the I-D discusses
> about various attack vectors that we need to be aware of.
> 
> On the other hand, as stated on the mailing list an on the mic, I am
> not super happy with the fact that the proposed methods have a
> negative impact on connection establishment time.
> 
> So here goes my straw-man proposal, as an Internet Draft:
> https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.

At least that method does not obviously vulernable to replay. However,
it has multitude of other problems:

> In essence, the draft proposes of sending information (e.g.,
> semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
> DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.

There are multiple problems with use of DNS:

- Individual DNS records can be at most 64kB.
- The whole DNS reply can be at most 64kB.
- In practice, exceeding about 1200 bytes for response starts
  causing problems with DNSoDTLS (there is a fallback to DNSoTLS,
  but it is not very pleasant).
- The textual representation starts getting unpleasant way before
  that.
- DNS records are defined to have textual and wire formats. Using TLS
  notation would be pretty great for latter, but not good for the
  former.

> Since DNS queries can run in parallel, there would be no negative
> performance impact, as long as DNS responses can be obtained in a
> single RTT.

Unfortunately, this is not quite true:

- Packets can get lost, and DNS retransmissions are fairly slow.
- There are lots of horked DNS servers that respond in all sorts of
  bad ways (including timing out, or sending utterly bogus error
  codes) to unknown RRTypes, especially if the RRType number is
  above 255 (but bad servers that do that to any RRType they do
  not know about still exist).

(And let's also ignore difficulties in adding new RRTypes, despite
RFC3597 being almost 14 years old, and covering almost everything that
has been added (one needs extra justfication for breaking RFC3597-
complatiblity[1]).)


[1] In practicular, following kinds of things break RFC3597:

- Compressing RRDATA with reference to rest of the DNS message (e.g.,
  DNS name compression).
- Requiring any kinds of transofrmations on the data in path between
  the master file and the end application.

> The draft mainly discusses about sending a signed bootstrap
> information together with the certificate chain, since doing so is not
> only more secure but opens up other possibilities in the future (such
> as 0-RTT full handshake). However, since transmitting a bootstrap
> record with digital signature and identity is unlikely to fit in a
> single packet (and therefore will have negative performance impact
> until DNS over TLS or QUIC becomes popular), the draft also discusses
> the possibility of sending the EC(DH) key unsigned in the "Things to
> Consider" section.

There is not much space in DNS records for anything bigger than one
ECDH key per record (but there is space for a few records of that
kind).


-Ilari

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