Re: [TLS] Adam Roach's Yes on draft-ietf-tls-record-limit-02: (with COMMENT)

[Adam Roach]

On 4/4/18 1:44 AM, Martin Thomson wrote:

Hi Adam,

Thanks for the review.  You picked up on something that was a little
sloppy there.

PR: https://github.com/tlswg/tls-record-limit/pull/19

On Wed, Apr 4, 2018 at 3:58 PM, Adam Roach  wrote:>
Adam Roach has entered the following ballot position for

§4:


  MUST NOT send a value higher than the protocol-defined maximum record
  size unless explicitly allowed by such a future version or extension.

Presumably, recipients MUST gracefully accept values higher than the maximum
record size?  That is implied by this text (and the text that follows), but
given how TLS frequently aborts connections at the first sign of any
irregularity, it's probably worth saying explicitly.

I thought that the following text was doing precisely that:


A server MUST NOT enforce this restriction; a client might advertise a higher 
limit that is enabled by an extension or version the server does not understand.


It would, if it were present. The IESG is reviewing version -02 of the 
document, in which that text does not appear. (I see it's in your repo, 
so presumably the -03 version will address the issue I highlight).



A client can enforce the restriction, because it knows the entire set
of possible extensions that determine the maximum size.  I'll concede
that it's a little sloppy in that it doesn't explicitly say whether a
client is expected to police the value.  Is that a change you would
like to see?  As in:


A client MAY abort the handshake with an illegal_parameter alert if the 
record_size_limit extension includes a value greater than the maximum record 
size permitted by the negotiated protocol version and extensions.

Note that this wasn't made a MUST because if there is an extension
that raises the limit, the client has to do a second pass over the
extensions and that's awkward.


I'm okay both with and without the change. What I really wanted was text 
equivalent to what you quote above.





§4:


  a DTLS endpoint that
  receives a record larger than its advertised limit MAY either
  generate a fatal "record_overflow" alert or discard the record.

I'm concerned about the interaction between the option to discard the record and
protocols that perform retransmission of lost packets over DTLS (e.g., proposals
such as draft-rescorla-quic-over-dtls). In the case that an oversized packet is
simply discarded, retransmissions of that (presumably still oversized) packet
will take a while to time out (I'm not particularly well-versed in QUIC, but
assume it has characteristics similar to TCP's ~nine-minute timeout), which
would result in really bad user experiences.  Is there rationale for this 
optionality?
It would seem to be cleaner if the response were simply to always send a fatal
error.

The problem is that you only want to abort if you decrypt the record.
DTLS doesn't kill connections if it receives junk.


Ah, okay. That makes perfect sense. Under such circumstances, I agree 
that dropping such packets seems to be the least bad path. No document 
change is necessary, although I wouldn't object if you added an 
explanation to the document that says exactly what you say above.


/a

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

Re: [TLS] Adam Roach's Yes on draft-ietf-tls-record-limit-02: (with COMMENT)

[Martin Thomson]

On Wed, Apr 4, 2018 at 5:44 PM, Adam Roach  wrote:
>>> A server MUST NOT enforce this restriction; a client might advertise a
>>> higher limit that is enabled by an extension or version the server does not
>>> understand.
>
> It would, if it were present. The IESG is reviewing version -02 of the
> document, in which that text does not appear. (I see it's in your repo, so
> presumably the -03 version will address the issue I highlight).

My fault.  Sean prompted me to push out a new version, then IESG
reviews started coming in, so I held back.  That was the result of a
secdir review.

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

[TLS] Ignas Bagdonas' No Objection on draft-ietf-tls-record-limit-02

[Ignas Bagdonas]

Ignas Bagdonas has entered the following ballot position for
draft-ietf-tls-record-limit-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/


There are no remarks associated with this position.




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

[TLS] Ignas Bagdonas' No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Ignas Bagdonas]

Ignas Bagdonas has entered the following ballot position for
draft-ietf-tls-iana-registry-updates-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/



--
COMMENT:
--

s/aligment/alignment
s/prviate/private


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

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

[Hubert Kario]

On Friday, 30 March 2018 11:42:23 CEST Vakul Garg wrote:
> Hi Martin
> 
> > -Original Message-
> > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Rex
> > Sent: Thursday, March 29, 2018 4:47 AM
> > To: Steve Fenter 
> > Cc: tls@ietf.org
> > Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do
> > it)> 
> > Steve Fenter  wrote:
> > > To clarify for anyone who has confusion on the enterprise TLS
> > > visibility use case, I think enterprises need to be able to do
> > > out-of-band decryption anywhere in the network that they own.
> > 
> > This is argument is so lame.
> > 
> > In Germany, monitoring communications between individuals or between
> > individuals and legal entities, including communications over corporate
> > networks, was made a serious crime in 2004 (TKG 2004) with a penalty of up
> > to 5 years in prison for listening into such communication.
> > 
> > The world didn't end.  Really, consider it proven that there is no need.
> 
> Could monitoring could be legally done if user provided his consent at the
> time of login into enterprise managed terminal?
> I guess that's the case in enterprise managed networks.

No, even then the employer needs to establish a concrete case for inspection 
of the communications of an employee.
Employer also must not continue inspection of an email as soon as it has 
noticed that it is part of a private message.

https://www.lexology.com/library/detail.aspx?g=f946064a-05d0-4603-ace9-3846b1c7536d

and this is true, to a large degree, for the whole of EU:
https://www.theguardian.com/law/2017/sep/05/romanian-chat-messages-read-by-employer-had-privacy-breached-court-rules

From the ECHR ruling:
"An employer[...] cannot reduce private social life in the workplace to zero. 
Respect for private life and for the privacy of correspondence continues to 
exist, even if these may be restricted in so far as necessary."

> > There may be _desires_.  For me, those desires are no less unethical as
> > data collections by apple, camebridge analytica, facebook, google,
> > microsoft, whathaveyou...
> > 
> >  and fortunately, for corporations in germany, such data gathering is
> > not just unethical, but truely criminal by law.
> > 
> > 
> > -Martin
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7Cvakul.garg%40n
> > xp.com%7C17aacd25ee5c49568aca08d595021677%7C686ea1d3bc2b4c6fa9
> > 2cd99c5c301635%7C0%7C0%7C636578758559728633&sdata=sa3hcM4C94
> > %2BX826Xcu4BwvfkIFzfJiB8cjPjOh7s8pI%3D&reserved=0
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

[Roland Zink]

Am 04.04.2018 um 14:43 schrieb Hubert Kario:

On Friday, 30 March 2018 11:42:23 CEST Vakul Garg wrote:

Hi Martin


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Rex
Sent: Thursday, March 29, 2018 4:47 AM
To: Steve Fenter 
Cc: tls@ietf.org
Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do
it)>
Steve Fenter  wrote:

To clarify for anyone who has confusion on the enterprise TLS
visibility use case, I think enterprises need to be able to do
out-of-band decryption anywhere in the network that they own.

This is argument is so lame.

In Germany, monitoring communications between individuals or between
individuals and legal entities, including communications over corporate
networks, was made a serious crime in 2004 (TKG 2004) with a penalty of up
to 5 years in prison for listening into such communication.

The world didn't end.  Really, consider it proven that there is no need.

Could monitoring could be legally done if user provided his consent at the
time of login into enterprise managed terminal?
I guess that's the case in enterprise managed networks.

No, even then the employer needs to establish a concrete case for inspection
of the communications of an employee.
Employer also must not continue inspection of an email as soon as it has
noticed that it is part of a private message.

https://www.lexology.com/library/detail.aspx?g=f946064a-05d0-4603-ace9-3846b1c7536d

and this is true, to a large degree, for the whole of EU:
https://www.theguardian.com/law/2017/sep/05/romanian-chat-messages-read-by-employer-had-privacy-breached-court-rules

 From the ECHR ruling:
"An employer[...] cannot reduce private social life in the workplace to zero.
Respect for private life and for the privacy of correspondence continues to
exist, even if these may be restricted in so far as necessary."


This is true, but at the same time the employer is required in many 
countries including Germany to archive many emails and other relevant 
messages. See for example https://en.wikipedia.org/wiki/Email_archiving 
or https://www.intradyn.com/email-retention-laws/. This is often in 
conflict with the above mentioned laws, for an example see 
https://www.theguardian.com/business/2016/jan/08/volkswagen-withhold-emissions-documents-investigations.



I don't think breaking TLS is the way to fulfill such requirements but I 
also think TLS connection to a company shouldn't end up at a third party 
providing hosting or CDN services.



Regards,
Roland






There may be _desires_.  For me, those desires are no less unethical as
data collections by apple, camebridge analytica, facebook, google,
microsoft, whathaveyou...

 and fortunately, for corporations in germany, such data gathering is
not just unethical, but truely criminal by law.


-Martin

___
TLS mailing list
TLS@ietf.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7Cvakul.garg%40n
xp.com%7C17aacd25ee5c49568aca08d595021677%7C686ea1d3bc2b4c6fa9
2cd99c5c301635%7C0%7C0%7C636578758559728633&sdata=sa3hcM4C94
%2BX826Xcu4BwvfkIFzfJiB8cjPjOh7s8pI%3D&reserved=0

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




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


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

Re: [TLS] Adam Roach's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Benjamin Kaduk]

On Tue, Apr 03, 2018 at 09:09:21PM -0700, Adam Roach wrote:
> --
> COMMENT:
> --
> 
> ---
> 
> Abstract:
> 
> Please include the list of updated RFCs in the abstract. See
>  §3.1.D. The current 
> formulation
> of "This document updates many (D)TLS RFCs (see updates header)" is 
> problematic
> due to the factors described in the final paragraph of RFC 7322 §4.3.

Would you be happy with just removing the "see updates header" bit?
Because I do not see much wrong with the use of "updates many (D)TLS
RFCs" in this case, which effects broad sweeping changes and for
which listing the individually affected documents is not very
helpful.


> ---
> 
> §8:
> 
> This section doesn't indicate anything about the disposition of
> "token_binding," which is due to (potentially) expire in 11 months. Given that
> the temporary property of this registration is due only to the previous policy
> that this document is obsoleting, it seems that this document should instruct
> IANA to remove the temporary status from the "token_binding" TLS 
> ExtensionType.

good catch

> ---
> 
> §8:
> 
> The table that adds a "Recommended" column to the TLS ExtensionType does not
> indicate values for "token_binding" or "cached_info." I suggest either adding
> them, or adding text to explain their omission.

Yeah, trying to keep a document like this up-to-date is always
exciting.  I have confidence that the interaction between IANA and
the authors will sort things out properly, though.

> ---
> 
> §17:
> 
> >  o  [SHALL update/has updated] the TLS HashAlgorithm Registry to list
> > values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry
> > to list values 4-223 as "Reserved".
> 
> HashAlgorithm 8 is already assigned, as are SignatureAlgorithms 7 and 8.
> Presumably the reserved ranges should be "7 and 9-223" and "4-6 and 9-223",
> respectively.

This is already addressed in a pull request against the github repo.

[some other uncontroversial nits trimmed]

-Benjamin

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

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

[Hubert Kario]

On Wednesday, 4 April 2018 16:46:36 CEST Roland Zink wrote:
> Am 04.04.2018 um 14:43 schrieb Hubert Kario:
> > On Friday, 30 March 2018 11:42:23 CEST Vakul Garg wrote:
> >> Hi Martin
> >> 
> >>> -Original Message-
> >>> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Rex
> >>> Sent: Thursday, March 29, 2018 4:47 AM
> >>> To: Steve Fenter 
> >>> Cc: tls@ietf.org
> >>> Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't
> >>> do
> >>> it)>
> >>> 
> >>> Steve Fenter  wrote:
>  To clarify for anyone who has confusion on the enterprise TLS
>  visibility use case, I think enterprises need to be able to do
>  out-of-band decryption anywhere in the network that they own.
> >>> 
> >>> This is argument is so lame.
> >>> 
> >>> In Germany, monitoring communications between individuals or between
> >>> individuals and legal entities, including communications over corporate
> >>> networks, was made a serious crime in 2004 (TKG 2004) with a penalty of
> >>> up
> >>> to 5 years in prison for listening into such communication.
> >>> 
> >>> The world didn't end.  Really, consider it proven that there is no need.
> >> 
> >> Could monitoring could be legally done if user provided his consent at
> >> the
> >> time of login into enterprise managed terminal?
> >> I guess that's the case in enterprise managed networks.
> > 
> > No, even then the employer needs to establish a concrete case for
> > inspection of the communications of an employee.
> > Employer also must not continue inspection of an email as soon as it has
> > noticed that it is part of a private message.
> > 
> > https://www.lexology.com/library/detail.aspx?g=f946064a-05d0-4603-ace9-384
> > 6b1c7536d
> > 
> > and this is true, to a large degree, for the whole of EU:
> > https://www.theguardian.com/law/2017/sep/05/romanian-chat-messages-read-by
> > -employer-had-privacy-breached-court-rules> 
> >  From the ECHR ruling:
> > "An employer[...] cannot reduce private social life in the workplace to
> > zero. Respect for private life and for the privacy of correspondence
> > continues to exist, even if these may be restricted in so far as
> > necessary."
> 
> This is true, but at the same time the employer is required in many
> countries including Germany to archive many emails and other relevant
> messages. See for example https://en.wikipedia.org/wiki/Email_archiving
> or https://www.intradyn.com/email-retention-laws/. This is often in
> conflict with the above mentioned laws, for an example see
> https://www.theguardian.com/business/2016/jan/08/volkswagen-withhold-emissio
> ns-documents-investigations.
> 
> 
> I don't think breaking TLS is the way to fulfill such requirements but I
> also think TLS connection to a company shouldn't end up at a third party
> providing hosting or CDN services.

it's not in conflict, just because you control of have the data doesn't mean 
you are allowed to access it - think phone companies listening on customer 
conversations

What it does mean, is that realtime access to TLS connections is definitely 
not necessary to retain messages for criminal investigations, that can and 
should be done at the endpoint in control of the company, not in transit at 
network boundary.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Alexey Melnikov]

Hi Benjamin,

On Tue, Apr 3, 2018, at 10:50 PM, Benjamin Kaduk wrote:
> I will trim the purely editorial stuff, as the authors should be
> able to handle that (and have already started, since the cipher
> suite/hash+signature algorithm thing was already noted).
> 
> On Tue, Apr 03, 2018 at 09:56:16AM -0700, Alexey Melnikov wrote:
> > Alexey Melnikov has entered the following ballot position for
> > draft-ietf-tls-iana-registry-updates-04: No Objection
> > 
> > --
> > COMMENT:
> > --
> > 
> > I support the idea behind this document. I have a few minor issues which I
> > would like to discuss before recommending its approval:
> > 
> > 1) In several places:
> > 
> > "IESG action is REQUIRED for a Yes->No transition."
> > 
> > Firstly, this should be "IESG Approval", not "IESG action" (according to RFC
> > 8126).
> 
> Sure, let's use the right term.
> 
> > Secondly, are you saying that this is the ONLY way to transition from Yes to
> > No? Surely, Standards Action should also be allowed in case there is no 
> > rush?
> > Besides IESG is likely to prefer a document explaining the transition 
> > anyway.
> 
> Is IESG Approval mutaully exclusive with Standards-Action?
> My reading of 8126's:
> 
>New assignments may be approved by the IESG.  Although there is no
>requirement that the request be documented in an RFC, the IESG has
>the discretion to request documents or other supporting materials on
>a case-by-case basis.
> 
> is that a standards-track document could include an "IESG
> Considerations" section that requests the IESG to effect the
> transition.

I suppose this can work, but typically "IESG Approval" is used for exception 
cases, where here it is always used. I think "IETF Consensus or IESG Approval" 
is more natural way of phrasing the intent.

> That is to say, while I have no objection to your proposed (idea
> for) text, I also am not sure that it is qualitatively different
> from the current text.

Best Regards,
Alexey

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

[TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Joseph Salowey]

Hi Folks,

Some objections were raised late during the review of
the draft-ietf-tls-dnssec-chain-extension. The question before the working
group is either to publish the document as is or to bring the document back
into the working group to address the following issues:

- Recommendation of adding denial of existence proofs in the chain provided
by the extension
- Adding signaling to require the use of this extension for a period of
time (Pinning with TTL)

This is a consensus call on how to progress this document.  Please answer
the following questions:

1) Do you support publication of the document as is, leaving these two
issues to potentially be addressed in follow-up work?

If the answer to 1) is no then please indicate if you think the working
group should work on the document to include

A) Recommendation of adding denial of existence proofs in the chain
provided by the extension
B) Adding signaling to require the use of this extension for a period of
time (Pinning with TTL)
C) Both

This call will be open until April 18, 2018.

Thanks,

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

Re: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Sean Turner]

> On Apr 4, 2018, at 12:48, Alexey Melnikov  wrote:
> 
> Hi Benjamin,
> 
> On Tue, Apr 3, 2018, at 10:50 PM, Benjamin Kaduk wrote:
>> I will trim the purely editorial stuff, as the authors should be
>> able to handle that (and have already started, since the cipher
>> suite/hash+signature algorithm thing was already noted).
>> 
>> On Tue, Apr 03, 2018 at 09:56:16AM -0700, Alexey Melnikov wrote:
>>> Alexey Melnikov has entered the following ballot position for
>>> draft-ietf-tls-iana-registry-updates-04: No Objection
>>> 
>>> --
>>> COMMENT:
>>> --
>>> 
>>> I support the idea behind this document. I have a few minor issues which I
>>> would like to discuss before recommending its approval:
>>> 
>>> 1) In several places:
>>> 
>>> "IESG action is REQUIRED for a Yes->No transition."
>>> 
>>> Firstly, this should be "IESG Approval", not "IESG action" (according to RFC
>>> 8126).
>> 
>> Sure, let's use the right term.

Yep my bad - fixing this.

>>> Secondly, are you saying that this is the ONLY way to transition from Yes to
>>> No? Surely, Standards Action should also be allowed in case there is no 
>>> rush?
>>> Besides IESG is likely to prefer a document explaining the transition 
>>> anyway.
>> 
>> Is IESG Approval mutaully exclusive with Standards-Action?
>> My reading of 8126's:
>> 
>>   New assignments may be approved by the IESG.  Although there is no
>>   requirement that the request be documented in an RFC, the IESG has
>>   the discretion to request documents or other supporting materials on
>>   a case-by-case basis.
>> 
>> is that a standards-track document could include an "IESG
>> Considerations" section that requests the IESG to effect the
>> transition.
> 
> I suppose this can work, but typically "IESG Approval" is used for exception 
> cases, where here it is always used. I think "IETF Consensus or IESG 
> Approval" is more natural way of phrasing the intent.

We wanted a bar that implied some adult supervision hence the IESG Approval :). 
I’d prefer to leave it at the lower because technically IETF Consensus also 
includes IESG Approval right?  I mean if somebody gets their draft through the 
process doesn’t it end with IESG approval?

>> That is to say, while I have no objection to your proposed (idea
>> for) text, I also am not sure that it is qualitatively different
>> from the current text.

Here’s a link to the PR:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/70

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Paul Wouters]

On Wed, 4 Apr 2018, Joseph Salowey wrote:


This is a consensus call on how to progress this document.  Please answer the 
following questions:

1) Do you support publication of the document as is, leaving these two issues 
to potentially be addressed
in follow-up work?


I do NOT support publication of the document as-is.


If the answer to 1) is no then please indicate if you think the working group 
should work on the document to
include 

A) Recommendation of adding denial of existence proofs in the chain provided by 
the extension
B) Adding signaling to require the use of this extension for a period of time 
(Pinning with TTL)
C) Both


These options need a bit of clarification.

If you do A) then by publishing the proof of non-existance records, you
can cancel any outstanding kind of pin done. And you would not need B)

But that requires the server farm consistently send the TLS extension at all
times. If they stop doing this, you have to somehow determine if this is
an attack or an administrative discontinuation. Doing a pin as per B)
would help identify if this is an attack or not. And a pin whose value
meants "no commitment" would allow for a farm of TLS servers where not
all servers have the extension (obviously at a price of reduced security)

So to support all cases, I would say C) but I think B) would get us
pretty far on a lot of deployments.

The document's intension is clearly to staple DNSSEC answers for the
TLSA query on the TLS handshake. Omiting proof of non-existence means
it fails to achieve its specified goal and makes this TLS extension
completely useless[*]

Paul
[*] The only use case would to accept WebPKI _or_ DNSSEC, which only
reduces the currently available security levels instead of increasing
it.

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Richard Barnes]

On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey  wrote:

> Hi Folks,
>
> Some objections were raised late during the review of
> the draft-ietf-tls-dnssec-chain-extension. The question before the
> working group is either to publish the document as is or to bring the
> document back into the working group to address the following issues:
>
> - Recommendation of adding denial of existence proofs in the chain
> provided by the extension
> - Adding signaling to require the use of this extension for a period of
> time (Pinning with TTL)
>
> This is a consensus call on how to progress this document.  Please answer
> the following questions:
>
> 1) Do you support publication of the document as is, leaving these two
> issues to potentially be addressed in follow-up work?
>

I support publication of the document as is.  I would also be comfortable
with a minor modification to say that TLSA certificate usages 0 and 1 (the
restrictive ones) MUST NOT be used with this mechanism.

Even if this document is restricted to the assertive use cases, it can
still be used in cases where clients and servers have agreed to forego the
"normal" PKI and rely on DANE, or in cases where servers are able to switch
between DANE and non-DANE authentication depending on the client's
capabilities.  The former pattern could be made to work in the web if there
were interest; I believe DKG has indicated that DPRIVE might fall in the
former category.

While there may be utility in the restrictive use cases, the discussion to
date indicates that there is sufficient complexity and controversy involved
in making that work that we should not block this document from enabling
assertive use cases while that is in progress.

--Richard



> If the answer to 1) is no then please indicate if you think the working
> group should work on the document to include
>
> A) Recommendation of adding denial of existence proofs in the chain
> provided by the extension
> B) Adding signaling to require the use of this extension for a period of
> time (Pinning with TTL)
> C) Both
>
> This call will be open until April 18, 2018.
>
> Thanks,
>
> Joe
>
>
>
> ___
> 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] Adam Roach's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Sean Turner]

On Apr 3, 2018, at 23:09, Adam Roach  wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-tls-iana-registry-updates-04: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for the work everyone put in on this document. I have a handful of
> comments, ranging from nits to minor issues. They appear in document order.
> 
> ---
> 
> Title:
> 
> Please expand "TLS" and "DTLS" in the title. See
> https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

Sure, but I have also just sent a request off to get TLS and DTLS added as 
well-known abbreviations so I’m hoping to change it back during AUTH48 ;)

> ---
> 
> Abstract:
> 
> Please include the list of updated RFCs in the abstract. See
>  §3.1.D. The current 
> formulation
> of "This document updates many (D)TLS RFCs (see updates header)" is 
> problematic
> due to the factors described in the final paragraph of RFC 7322 §4.3.

See Ben’s response.

> ---
> 
> §2:
> 
>> Instead of listing the changes and their rationale in this,
>> the introductory, section each section provides rationale for the
>> proposed change(s).
> 
> There's something awkward with the commas here. Perhaps you mean:
> 
>> Instead of listing the changes and their rationale in this,
>> the introductory section, each section provides rationale for the
>> proposed change(s).

Yep that does read better.

> ---
> 
> §8:
> 
> This section doesn't indicate anything about the disposition of
> "token_binding," which is due to (potentially) expire in 11 months. Given that
> the temporary property of this registration is due only to the previous policy
> that this document is obsoleting, it seems that this document should instruct
> IANA to remove the temporary status from the "token_binding" TLS 
> ExtensionType.

I think that would be terribly unfair especially since the draft defining the 
token_binding extension is on the 5/10 telechat ;)
https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/
How about I just get them to add a Recommended = Yes column.

> ---
> 
> §8:
> 
> The table that adds a "Recommended" column to the TLS ExtensionType does not
> indicate values for "token_binding" or "cached_info." I suggest either adding
> them, or adding text to explain their omission.

Can’t believe I forgot cached_info.   I’ll add a note about token_binding.  I 
also just sent the WG a note about needing to add the Recommended “Yes” value 
to their IANA considerations.

> ---
> 
> §9:
> 
>> assigned via Specification Required {{RFC8126}}.  Values with the
>> first byte 255 (decimal) are reserved for Private Use {{RFC8126}}.
> 
> Nit: the "{{...}}" citation style is probably not what you intended.

Ah it did that because it’s a code snipet :(. Fixed the multiple occurrences.

> ---
> 
> §13:
> 
>> o  A "Recommended" column to the TLS Exporter Label registry.  The
>>table that follows has been generated by marking Standards Track
>>RFCs as "Yes" and all others as "No".
> 
> No rows are marked "No." Presumably, the text above should instead say "any
> values not indicated in the table below [will be/have been] marked 'No’"

yeah I think it’s that the others are "to be marked” (same for the cipher 
suites).

> ---
> 
> §14:
> 
>> 120   no_application_protocol  Y  [RFC7301]
> 
> Every other updated table is amended to also point to this document. I presume
> that omitting it from this entry is an oversight, and that it should instead 
> be:
> 
>> 120   no_application_protocol  Y  [RFC7301] [RFCthis]

Yep.

See the following PR to address the above changes:

https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/71

> ---
> 
> §17:
> 
>> o  [SHALL update/ha

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Melinda Shore]

On 4/4/18 2:53 PM, Richard Barnes wrote:
> I support publication of the document as is.  I would also be
> comfortable with a minor modification to say that TLSA certificate
> usages 0 and 1 (the restrictive ones) MUST NOT be used with this mechanism.

The addition of text that clarifies that seems absolutely reasonable
to me.

I do think there would be a problem with adding additional complexity
to the extension to support functionality that nobody has said that
they intend to use (including the proponents of the changes), given
that the changes would not be introduced to correct an error in
the existing spec.

Melinda


-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] Adam Roach's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Sean Turner]

> On Apr 4, 2018, at 17:05, Sean Turner  wrote:
> 
>> 
>> Abstract:
>> 
>> Please include the list of updated RFCs in the abstract. See
>>  §3.1.D. The current 
>> formulation
>> of "This document updates many (D)TLS RFCs (see updates header)" is 
>> problematic
>> due to the factors described in the final paragraph of RFC 7322 §4.3.
> 
> See Ben’s response.

Here we are again.  This time I updated the abstract to include the 8 RFCs this 
draft “updates”.*

spt

* I still think this policy is silly.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni]

> On Apr 4, 2018, at 1:50 PM, Joseph Salowey  wrote:
> 
> - Recommendation of adding denial of existence proofs in the chain provided 
> by the extension
> - Adding signaling to require the use of this extension for a period of time 
> (Pinning with TTL)

These are indeed the immediate proposed fixes, and ultimately the consensus 
call will be about
whether the fixes should be formalized and integrated or the document advanced 
as-is, but before
we consider them in a vacuum, I'd like to explain in some detail *why* they are 
needed.  This
requires firstly an examination of why the extension is needed in the first 
place, and what
use-cases it should address.  This will be detailed below, but first:

> This is a consensus call on how to progress this document.  Please answer the 
> following questions:
> 
> 1) Do you support publication of the document as is, leaving these two issues 
> to potentially be addressed in follow-up work?
> 
> If the answer to 1) is no then please indicate if you think the working group 
> should work on the document to include 
> 
> A) Recommendation of adding denial of existence proofs in the chain provided 
> by the extension
> B) Adding signaling to require the use of this extension for a period of time 
> (Pinning with TTL)
> C) Both

For the record, (C) both.  And now to explain why:

The first thing to understand is why this extension is needed in the first 
place.  A partial
answer can bee seen in the introduction to the draft. Please pardon burying the 
lede, below
I quote from the text of the introduction in order of presentation, but the 
main point is closer
to the end:

  -
  This draft describes a new TLS [RFC5246] [TLS13] extension for
  transport of a DNS record set serialized with the DNSSEC signatures
  [RFC4034] needed to authenticate that record set.
  -

We should note that an empty record set (NXDOMAIN or NODATA) is still
a record set, and DNSSEC *authenticates* denial of existence, and it
is necessary to also support denial of existence, in order to support
downgrade-resistance against "TLSA-stripping".  The reason is that this
extension is not being introduced into brand new internet in which the
CA/B forum WebPKI does not exist and DANE will be the *only* way for
TLS clients to authenticate servers.  For this extension to coexist
with the WebPKI clients will need to be able to *some* servers via
DANE and others (those that don't have DANE TLSA records) via the
existing WebPKI.

Suppose that, in the absence of authenticated denial of existence,
and clients being able to rely on continued support for the extension:

   * As will be the cast for most existing applications, the client
 is willing to use the WebPKI when DANE TLSA records don't appear
 to be availble.

   * An attacker is able to obtain a fraudulent WebPKI certificate.

Then the attacker can impersonate the target server by leaving out
the extension and presenting just the fraudulent WebPKI certificate,
and the client will have to accept this even when the real server
previously employed the extension and provided TLSA records.

What the above establishes is that in mixed environments, i.e.
almost all use-cases for this specification, TLSA records provide
no additional protection, if WebPKI fails, security is compromised
even with DANE.

Some have argued that this is OK, that even though the above
"restrictive" use-case is unavailable we still get an "additive"
use case, where servers can be authenticated with DANE when
that happens to be present and otherwise WebPKI.  Sadly, that
use-case is largely a mirage.  Firstly, given the existing
dominant client base that only supports WebPKI, any server
would in any case still need WebPKI certificates (say from
Let's Encrypt), and that will suffice for all clients both
those that support DANE and those that don't.  Thus enabling
DANE on the server, only makes it possible to impersonate
the server if DANE is compromised, but does not defend against
WebPKI compromise.  So the server gets more complexity, and
reduced security, and maybe even increased risk of failure
if the TLSA records are managed carelessly and fail to match.

No rational server operator will employ the "additive" mode.
Some DANE idealists might do it to signal their support for
the technology, but this will be futile, they'll get no real
benefit from doing so.

Continuing on with the introduction:

  -
  The intent of this
  proposal is to allow TLS clients to perform DANE Authentication
  [RFC6698] [RFC7671] of a TLS server without performing additional DNS
  record lookups and incurring the associated latency penalty.  It also
  provides the ability to avoid potential problems with TLS clients
  being unable to look up DANE records because of an interfering or
  broken middlebox on the path between the client and a DNS server
  [HAMPERING].  And lastly, it allows a TLS client to validate the
  server's DANE (TLSA) records its

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni]

> On Apr 4, 2018, at 6:12 PM, Melinda Shore  
> wrote:
> 
>> I support publication of the document as is.  I would also be
>> comfortable with a minor modification to say that TLSA certificate
>> usages 0 and 1 (the restrictive ones) MUST NOT be used with this mechanism.
> 
> The addition of text that clarifies that seems absolutely reasonable
> to me.

That addition is fundamentally flawed.  THere is no realistic scalable
adoption model in which a server publishes DANE-only certificates to
and expects thereby to support a meaningful set of clients that would
don't trust Let's Encrypt (for example).  Nor do I see the browser
community accepting DANE alone as a sufficient security mechanism.


> I do think there would be a problem with adding additional complexity

Ignoring a 16-bit field in the extension adds ZERO complexity.  Not
sending a denial of existence response and not accepting one if
given (in applications that don't need this feature) likewise adds
ZERO complexity.  The complexity argument is a mirage.

> to the extension to support functionality that nobody has said that
> they intend to use (including the proponents of the changes), given
> that the changes would not be introduced to correct an error in
> the existing spec.

The changes are needed to support the extension in any application
where adoption is necessarily incremental (i.e. all existing WebPKI
applications).  To refute that, one would need to refute the security
and cost-benefit analyses in my post and somehow demonstrate
"alternative facts" that establish the viability of an additive
model, and some other way to compensate for the fact the present
extension has a major downgrade hole.

It is precisely the "restrictive" use-case that Richard says can be
left out that users expect from DANE, that is tangible benefit over
and above just using WebPKI, from say Let's Encrypt.

-- 
Viktor.

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

Re: [TLS] Eric Rescorla's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Sean Turner]

> On Mar 31, 2018, at 12:54, Eric Rescorla  wrote:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-tls-iana-registry-updates-04: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
> 
> 
> 
> --
> COMMENT:
> --
> 
> requires standards action.  Not all parameters defined in standards
>   track documents need to be marked as recommended.
> It might be useful to capitalize Recommended here.

Here and a couple of other places I capitalized recommended.

>   been through the IETF consensus process, has limited applicability,
>   or is intended only for specific use cases.
> I think technically it has "Recommended = No”

yeah the OPSDIR review noted this as well so I changed the sentence to be:

If an item is not marked as recommended it does …

https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/62/files

>   Note:  Supported Groups marked as "Yes" are those allocated via
>  Standards Track RFCs.  Supported Groups marked as "No" are not;
>  supported groups marked "No" range from "good" to "bad" from a
> This may need a revision because some have not been allocated that way.

Supported Groups is the one real odd-ball here because they were originally not 
on standards track, but 4492bis is going to move them there.  Would this work:

These “Yes” groups are taken from Standards Track RFCs; 
{{?I-D.ietf-tls-rfc4492bis}} elevates secp256r1 and secp384r1 to Standards 
Track.

>  thus requiring a new construction.  The exporter interface remains
>  the same, however the value is computed different.
> differently.

PR for the three changes:

https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/72

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

Re: [TLS] Ignas Bagdonas' No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Sean Turner]

> On Apr 4, 2018, at 06:21, Ignas Bagdonas  wrote:
> 
> Ignas Bagdonas has entered the following ballot position for
> draft-ietf-tls-iana-registry-updates-04: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
> 
> 
> 
> --
> COMMENT:
> --
> 
> s/aligment/alignment
> s/prviate/private

I think this ought to fix it up:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/73

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Martin Thomson]

Given what we've learned about pinning (it is being removed from
browsers), this seems like a bad plan to me.

Your cost benefit analysis seems about right though.

On Thu, Apr 5, 2018 at 9:27 AM, Viktor Dukhovni  wrote:
>
>
>> On Apr 4, 2018, at 1:50 PM, Joseph Salowey  wrote:
>>
>> - Recommendation of adding denial of existence proofs in the chain provided 
>> by the extension
>> - Adding signaling to require the use of this extension for a period of time 
>> (Pinning with TTL)
>
> These are indeed the immediate proposed fixes, and ultimately the consensus 
> call will be about
> whether the fixes should be formalized and integrated or the document 
> advanced as-is, but before
> we consider them in a vacuum, I'd like to explain in some detail *why* they 
> are needed.  This
> requires firstly an examination of why the extension is needed in the first 
> place, and what
> use-cases it should address.  This will be detailed below, but first:
>
>> This is a consensus call on how to progress this document.  Please answer 
>> the following questions:
>>
>> 1) Do you support publication of the document as is, leaving these two 
>> issues to potentially be addressed in follow-up work?
>>
>> If the answer to 1) is no then please indicate if you think the working 
>> group should work on the document to include
>>
>> A) Recommendation of adding denial of existence proofs in the chain provided 
>> by the extension
>> B) Adding signaling to require the use of this extension for a period of 
>> time (Pinning with TTL)
>> C) Both
>
> For the record, (C) both.  And now to explain why:
>
> The first thing to understand is why this extension is needed in the first 
> place.  A partial
> answer can bee seen in the introduction to the draft. Please pardon burying 
> the lede, below
> I quote from the text of the introduction in order of presentation, but the 
> main point is closer
> to the end:
>
>   -
>   This draft describes a new TLS [RFC5246] [TLS13] extension for
>   transport of a DNS record set serialized with the DNSSEC signatures
>   [RFC4034] needed to authenticate that record set.
>   -
>
> We should note that an empty record set (NXDOMAIN or NODATA) is still
> a record set, and DNSSEC *authenticates* denial of existence, and it
> is necessary to also support denial of existence, in order to support
> downgrade-resistance against "TLSA-stripping".  The reason is that this
> extension is not being introduced into brand new internet in which the
> CA/B forum WebPKI does not exist and DANE will be the *only* way for
> TLS clients to authenticate servers.  For this extension to coexist
> with the WebPKI clients will need to be able to *some* servers via
> DANE and others (those that don't have DANE TLSA records) via the
> existing WebPKI.
>
> Suppose that, in the absence of authenticated denial of existence,
> and clients being able to rely on continued support for the extension:
>
>* As will be the cast for most existing applications, the client
>  is willing to use the WebPKI when DANE TLSA records don't appear
>  to be availble.
>
>* An attacker is able to obtain a fraudulent WebPKI certificate.
>
> Then the attacker can impersonate the target server by leaving out
> the extension and presenting just the fraudulent WebPKI certificate,
> and the client will have to accept this even when the real server
> previously employed the extension and provided TLSA records.
>
> What the above establishes is that in mixed environments, i.e.
> almost all use-cases for this specification, TLSA records provide
> no additional protection, if WebPKI fails, security is compromised
> even with DANE.
>
> Some have argued that this is OK, that even though the above
> "restrictive" use-case is unavailable we still get an "additive"
> use case, where servers can be authenticated with DANE when
> that happens to be present and otherwise WebPKI.  Sadly, that
> use-case is largely a mirage.  Firstly, given the existing
> dominant client base that only supports WebPKI, any server
> would in any case still need WebPKI certificates (say from
> Let's Encrypt), and that will suffice for all clients both
> those that support DANE and those that don't.  Thus enabling
> DANE on the server, only makes it possible to impersonate
> the server if DANE is compromised, but does not defend against
> WebPKI compromise.  So the server gets more complexity, and
> reduced security, and maybe even increased risk of failure
> if the TLSA records are managed carelessly and fail to match.
>
> No rational server operator will employ the "additive" mode.
> Some DANE idealists might do it to signal their support for
> the technology, but this will be futile, they'll get no real
> benefit from doing so.
>
> Continuing on with the introduction:
>
>   -
>   The intent of this
>   proposal is to allow TLS clients to perform DANE Authentication
>   [RFC6698] [RFC7671] of a TLS server without performing 

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni]

> On Apr 4, 2018, at 10:07 PM, Martin Thomson  wrote:
> 
> Given what we've learned about pinning (it is being removed from
> browsers), this seems like a bad plan to me.

Question, are you thinking of HPKP or STS?  HPKP pins rather volatile
data, and is too fragile to be used (something I would have predicted
without even running the experiment).  STS and this proposal pin a
capability:

* STS:  I can be relied on to support TLS
* option (B): I can be relied on to support the TLS extension
  for the specified itme (or not when the TTL is 0).

So I rather that the unsurprising failure of HPKP is the wrong lesson
to apply.  STS seems successful enough, indeed in the UTA working
group Google, Microsoft, Yahoo et. al. are standardizing an STS for
SMTP (as a work-around for lack of DNSSEC in their domains) and this
pins an STS policy for timescales comparable to the proposal here.

The UTA STS draft has just cleared WG last call, Should I expect that the
folks in this WG opposing the pin for the DANE chain extension are strongly
opposed to SMTP STS and will argue against it in IETF last call and if
IESG members in IESG review?

-- 
Viktor.

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Eric Rescorla]

On Wed, Apr 4, 2018 at 7:15 PM, Viktor Dukhovni 
wrote:

>
>
> > On Apr 4, 2018, at 10:07 PM, Martin Thomson 
> wrote:
> >
> > Given what we've learned about pinning (it is being removed from
> > browsers), this seems like a bad plan to me.
>
> Question, are you thinking of HPKP or STS?  HPKP pins rather volatile
> data, and is too fragile to be used (something I would have predicted
> without even running the experiment).  STS and this proposal pin a
> capability:
>
> * STS:  I can be relied on to support TLS
> * option (B): I can be relied on to support the TLS extension
>   for the specified itme (or not when the TTL is 0).
>

I don't think that this comparison is particularly apt.The representation
in HSTS
is simply "I support HSTS". The representation in HPKP is "I will use
either consistent
keying material *or* a consistent set of CAs". The representation here is
"I will
continue to have DNSSEC-signed DANE records". That is a significantly more
risky
proposition than continuing to support TLS (and I'm ignoring the risk of
hijacking
attacks that people were concerned with with HPKP), and so this seems rather
more like HPKP to me.

-Ekr




> --
> Viktor.
>
> ___
> 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

On Wed, Apr 04, 2018 at 10:50:15AM -0700, Joseph Salowey wrote:
> Some objections were raised late during the review of
> the draft-ietf-tls-dnssec-chain-extension. The question before the working
> group is either to publish the document as is or to bring the document back
> into the working group to address the following issues:

For the record, I've had a document need changes after IESG publication
approval that were then made with a WG LC for those changes rather than
a repeat of WG LC, IETF LC, and IESG review.

I'm surprised that this changes should require "bring[ing] the document
back into the working group" if by that you mean going through the full
process all over.  Though, to be sure, I don't object if that's the
required path now, but I don't want people to feel compelled to be
against this LC on account of the delay in publication being much
bigger, not if there's a shorter method.  (Also, I don't mind a delay
all that much: it's hardly that big a deal; RFCs often end up stuck in
AUTH48 for much much longer!)

> - Recommendation of adding denial of existence proofs in the chain provided
> by the extension
> - Adding signaling to require the use of this extension for a period of
> time (Pinning with TTL)
> 
> This is a consensus call on how to progress this document.  Please answer
> the following questions:
> 
> 1) Do you support publication of the document as is, leaving these two
> issues to potentially be addressed in follow-up work?

I do not.

> If the answer to 1) is no then please indicate if you think the working
> group should work on the document to include
> 
> A) Recommendation of adding denial of existence proofs in the chain
> provided by the extension
> B) Adding signaling to require the use of this extension for a period of
> time (Pinning with TTL)
> C) Both

At least (B), and preferably (C).

My rationale for (B) is that this is the sort of thing where adding it
from the get-go will yield deployment where DANE is not mandatory for
the application whereas not adding it now will yield non-deployment of
DANE in such applications for a very long time.

My rationale for (C) is that (A) is trivial, so might as well throw it
in.  Mind you, (B) is also trivial (two bytes! to be conveyed however
you want, with 0 -> clear the pin to DANE).

Thanks,

Nico
-- 

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
> I don't think that this comparison is particularly apt.The
> representation in HSTS is simply "I support HSTS". The representation
> in HPKP is "I will use either consistent keying material *or* a
> consistent set of CAs". The representation here is "I will continue to
> have DNSSEC-signed DANE records". That is a significantly more risky
> proposition than continuing to support TLS (and I'm ignoring the risk
> of hijacking attacks that people were concerned with with HPKP), and
> so this seems rather more like HPKP to me.

Without a TTL (with zero meaning "clear the pin to DANE") this extension
can only really be used with mandatory-to-use-with-DANE protocols, where
the commitment to "continue to have DNSSEC-signed DANE records" is
implied.

The TTL allows one to put a bound on that commitment, thus alleviating
the risk.

That's the whole point: to alleviate the risk of commitment to DANE in
order to not discourage opportunistic deployment.

Nico
-- 

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

On Thu, Apr 05, 2018 at 12:07:57PM +1000, Martin Thomson wrote:
> Given what we've learned about pinning (it is being removed from
> browsers), this seems like a bad plan to me.

You can use this TTL, or not.  You're not required to set it to any
value other than the max ("infinity") or min (zero) if you don't want
to.  You can pin or not pin.  You can make DNAE mandatory (TTL set to
infinity) or not.

Adding this TTL cannot have a negative impact on the initial application
of this extension.

Nico
-- 

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Richard Barnes]

Re-adding the list.

On Wed, Apr 4, 2018, 22:39 Richard Barnes  wrote:

>
>
> On Wed, Apr 4, 2018, 22:34 Nico Williams  wrote:
>
>> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
>> > I don't think that this comparison is particularly apt.The
>> > representation in HSTS is simply "I support HSTS". The representation
>> > in HPKP is "I will use either consistent keying material *or* a
>> > consistent set of CAs". The representation here is "I will continue to
>> > have DNSSEC-signed DANE records". That is a significantly more risky
>> > proposition than continuing to support TLS (and I'm ignoring the risk
>> > of hijacking attacks that people were concerned with with HPKP), and
>> > so this seems rather more like HPKP to me.
>>
>> Without a TTL (with zero meaning "clear the pin to DANE") this extension
>> can only really be used with mandatory-to-use-with-DANE protocols, where
>> the commitment to "continue to have DNSSEC-signed DANE records" is
>> implied.
>>
>
> This is just not true.  As I said in my earlier message, servers can
> switch based on the ClientHello.
>
> Clients advertise which methods they support, servers switch, and they
> both see how often DANE gets used.  When it gets high enough, they turn off
> the fallback.  Just like every other TLS feature we've ever done.
>
> --Richard
>
>
>
>> The TTL allows one to put a bound on that commitment, thus alleviating
>> the risk.
>>
>> That's the whole point: to alleviate the risk of commitment to DANE in
>> order to not discourage opportunistic deployment.
>>
>> Nico
>> --
>>
>> ___
>> 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

On Wed, Apr 04, 2018 at 05:33:27PM -0400, Paul Wouters wrote:
> On Wed, 4 Apr 2018, Joseph Salowey wrote:
> >A) Recommendation of adding denial of existence proofs in the chain provided 
> >by the extension
> >B) Adding signaling to require the use of this extension for a period of 
> >time (Pinning with TTL)
> >C) Both
> 
> These options need a bit of clarification.
> 
> If you do A) then by publishing the proof of non-existance records, you
> can cancel any outstanding kind of pin done. And you would not need B)

Hmm, not quite.  You might want to publish the "clear the pin" (TTL ==
zero) without having to first stop publishing TLSA RRs.

The idea is to first ramp up the TTL, and if there's any problems /
change of mind, ramp it down and remove the TLSA RRs when the last
possible extant pin must have expired.

Therefore I think (B) is more urgent.  (A) is even more trivial than
(B), so there's no reason not to do both ((C)).

> [..]
> 
> So to support all cases, I would say C) but I think B) would get us
> pretty far on a lot of deployments.

+1

> The document's intension is clearly to staple DNSSEC answers for the
> TLSA query on the TLS handshake. Omiting proof of non-existence means
> it fails to achieve its specified goal and makes this TLS extension
> completely useless[*]

+1

Thanks,

Nico
-- 

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Eric Rescorla]

On Wed, Apr 4, 2018 at 7:20 PM, Nico Williams  wrote:

> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
> > I don't think that this comparison is particularly apt.The
> > representation in HSTS is simply "I support HSTS". The representation
> > in HPKP is "I will use either consistent keying material *or* a
> > consistent set of CAs". The representation here is "I will continue to
> > have DNSSEC-signed DANE records". That is a significantly more risky
> > proposition than continuing to support TLS (and I'm ignoring the risk
> > of hijacking attacks that people were concerned with with HPKP), and
> > so this seems rather more like HPKP to me.
>
> Without a TTL (with zero meaning "clear the pin to DANE") this extension
> can only really be used with mandatory-to-use-with-DANE protocols, where
> the commitment to "continue to have DNSSEC-signed DANE records" is
> implied.
>

This simply isn't true, for the reasons Richard Barnes indicated in his
response
to you.


> The TTL allows one to put a bound on that commitment, thus alleviating
> the risk.
>
> That's the whole point: to alleviate the risk of commitment to DANE in
> order to not discourage opportunistic deployment.
>

HPKP had a TTL and yet as a practical matter, people found it very
problematic.
And, of course, if you're concerned with hijacking attacks, the hijacker
will
just advertise a very long TTL.

-Ekr

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

On Thu, Apr 05, 2018 at 02:39:43AM +, Richard Barnes wrote:
> Re-adding the list.

Removing one level of quotes.

> On Wed, Apr 4, 2018, 22:34 Nico Williams  wrote:
>> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
>> > I don't think that this comparison is particularly apt.The
>> > representation in HSTS is simply "I support HSTS". The representation
>> > in HPKP is "I will use either consistent keying material *or* a
>> > consistent set of CAs". The representation here is "I will continue to
>> > have DNSSEC-signed DANE records". That is a significantly more risky
>> > proposition than continuing to support TLS (and I'm ignoring the risk
>> > of hijacking attacks that people were concerned with with HPKP), and
>> > so this seems rather more like HPKP to me.
>>
>> Without a TTL (with zero meaning "clear the pin to DANE") this extension
>> can only really be used with mandatory-to-use-with-DANE protocols, where
>> the commitment to "continue to have DNSSEC-signed DANE records" is
>> implied.
>
> This is just not true.  As I said in my earlier message, servers can
> switch based on the ClientHello.
>
> Clients advertise which methods they support, servers switch, and they
> both see how often DANE gets used.  When it gets high enough, they turn off
> the fallback.  Just like every other TLS feature we've ever done.

If clients and servers just negotiate the use of DANE, then there's a
downgrade attack when DANE is the only outcome desired by the server
operator but some WebPKI CA is willing to issue a rogue certificate for
it.

That downgrade is a fatal flaw for any protocols where this extension
isn't mandatory.

QED.

We cannot be serious about security while promoting a protocol with a
glaring downgrade attack.

The TTL with pin-to-DANE semantics alleviates this by allowing the use
of DANE to become mandatory-like for some time after first-use.  It's
TOFU-ish (Trust On First Use).  TOFU has worked rather well for some
protocols, and it will probably work well in the future.

This mechanism to make this extension mandatory-for-some-time negates
the downgrade attack *and* simultaneously provides a path to undo the
use of DANE -- something that operators can reasonably be expected to
demand for any protocol where this extension is not mandatory.

Nico
-- 

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

On Wed, Apr 04, 2018 at 07:44:53PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 7:20 PM, Nico Williams  wrote:
> 
> > On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
> > > I don't think that this comparison is particularly apt.The
> > > representation in HSTS is simply "I support HSTS". The representation
> > > in HPKP is "I will use either consistent keying material *or* a
> > > consistent set of CAs". The representation here is "I will continue to
> > > have DNSSEC-signed DANE records". That is a significantly more risky
> > > proposition than continuing to support TLS (and I'm ignoring the risk
> > > of hijacking attacks that people were concerned with with HPKP), and
> > > so this seems rather more like HPKP to me.
> >
> > Without a TTL (with zero meaning "clear the pin to DANE") this extension
> > can only really be used with mandatory-to-use-with-DANE protocols, where
> > the commitment to "continue to have DNSSEC-signed DANE records" is
> > implied.
> >
> 
> This simply isn't true, for the reasons Richard Barnes indicated in his
> response
> to you.

See my response to him.  For any non-mandatory use of this extension,
without the pinning semantics there is a glaring downgrade attack.

> HPKP had a TTL and yet as a practical matter, people found it very
> problematic.

I can see why: you have to commit to one certificate in the chain not
changing.  Whereas here you only have to commit to continue to publish
TLSA RRs (and signing them and your zone).  This is a big difference.

> And, of course, if you're concerned with hijacking attacks, the
> hijacker will just advertise a very long TTL.

But it's a TOFU-ish thing.  The server impersonator has to have the
right timing or else be detected -- that's very risky for them, and a
deterrent to even trying.  It's not fool-proof, but it's not nothing
either.

Nico
-- 

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Eric Rescorla]

On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams  wrote:

> On Thu, Apr 05, 2018 at 02:39:43AM +, Richard Barnes wrote:
> > Re-adding the list.
>
> Removing one level of quotes.
>
> > On Wed, Apr 4, 2018, 22:34 Nico Williams  wrote:
> >> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
> >> > I don't think that this comparison is particularly apt.The
> >> > representation in HSTS is simply "I support HSTS". The representation
> >> > in HPKP is "I will use either consistent keying material *or* a
> >> > consistent set of CAs". The representation here is "I will continue to
> >> > have DNSSEC-signed DANE records". That is a significantly more risky
> >> > proposition than continuing to support TLS (and I'm ignoring the risk
> >> > of hijacking attacks that people were concerned with with HPKP), and
> >> > so this seems rather more like HPKP to me.
> >>
> >> Without a TTL (with zero meaning "clear the pin to DANE") this extension
> >> can only really be used with mandatory-to-use-with-DANE protocols, where
> >> the commitment to "continue to have DNSSEC-signed DANE records" is
> >> implied.
> >
> > This is just not true.  As I said in my earlier message, servers can
> > switch based on the ClientHello.
> >
> > Clients advertise which methods they support, servers switch, and they
> > both see how often DANE gets used.  When it gets high enough, they turn
> off
> > the fallback.  Just like every other TLS feature we've ever done.
>
> If clients and servers just negotiate the use of DANE, then there's a
> downgrade attack when DANE is the only outcome desired by the server
> operator but some WebPKI CA is willing to issue a rogue certificate for
> it.
>
> That downgrade is a fatal flaw for any protocols where this extension
> isn't mandatory.
>
> QED.
>
> We cannot be serious about security while promoting a protocol with a
> glaring downgrade attack.
>

Unfortunately, you are conflating the assertive and restrictive use cases.

To recap, there are two potential reasons why one might want thi
technology:

1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's
a pain). This rationale was stronger back before Let's Encrypt, but
I suppose some people may still feel that way.

2. Restrictive: To protect yourself from compromise of the WebPKI.

Yes, if your motivation is #2, then the flow you suggest is a real problem,
but it's not a problem for #1. While not an author of this document, I'd
understood it's primary motivation to be #1, and that's what Richard's
earlier notes have said as well.

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Richard Barnes]

And just to be clear, by "downgrade attack", you mean "normal PKI
authentication that we rely on today".  There's nothing in here that
degrades security (except maybe the legacy crypto in the DNS); it's just
not meeting the bar that you are setting.   That doesn't mean there's not
still some utility to be had.

--Richard


On Wed, Apr 4, 2018, 22:57 Eric Rescorla  wrote:

>
>
> On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams 
> wrote:
>
>> On Thu, Apr 05, 2018 at 02:39:43AM +, Richard Barnes wrote:
>> > Re-adding the list.
>>
>> Removing one level of quotes.
>>
>> > On Wed, Apr 4, 2018, 22:34 Nico Williams  wrote:
>> >> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
>> >> > I don't think that this comparison is particularly apt.The
>> >> > representation in HSTS is simply "I support HSTS". The representation
>> >> > in HPKP is "I will use either consistent keying material *or* a
>> >> > consistent set of CAs". The representation here is "I will continue
>> to
>> >> > have DNSSEC-signed DANE records". That is a significantly more risky
>> >> > proposition than continuing to support TLS (and I'm ignoring the risk
>> >> > of hijacking attacks that people were concerned with with HPKP), and
>> >> > so this seems rather more like HPKP to me.
>> >>
>> >> Without a TTL (with zero meaning "clear the pin to DANE") this
>> extension
>> >> can only really be used with mandatory-to-use-with-DANE protocols,
>> where
>> >> the commitment to "continue to have DNSSEC-signed DANE records" is
>> >> implied.
>> >
>> > This is just not true.  As I said in my earlier message, servers can
>> > switch based on the ClientHello.
>> >
>> > Clients advertise which methods they support, servers switch, and they
>> > both see how often DANE gets used.  When it gets high enough, they turn
>> off
>> > the fallback.  Just like every other TLS feature we've ever done.
>>
>> If clients and servers just negotiate the use of DANE, then there's a
>> downgrade attack when DANE is the only outcome desired by the server
>> operator but some WebPKI CA is willing to issue a rogue certificate for
>> it.
>>
>> That downgrade is a fatal flaw for any protocols where this extension
>> isn't mandatory.
>>
>> QED.
>>
>> We cannot be serious about security while promoting a protocol with a
>> glaring downgrade attack.
>>
>
> Unfortunately, you are conflating the assertive and restrictive use cases.
>
> To recap, there are two potential reasons why one might want thi
> technology:
>
> 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's
> a pain). This rationale was stronger back before Let's Encrypt, but
> I suppose some people may still feel that way.
>
> 2. Restrictive: To protect yourself from compromise of the WebPKI.
>
> Yes, if your motivation is #2, then the flow you suggest is a real problem,
> but it's not a problem for #1. While not an author of this document, I'd
> understood it's primary motivation to be #1, and that's what Richard's
> earlier notes have said as well.
>
> -Ekr
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Eric Rescorla]

On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams  wrote:

> On Wed, Apr 04, 2018 at 07:44:53PM -0700, Eric Rescorla wrote:
> > On Wed, Apr 4, 2018 at 7:20 PM, Nico Williams 
> wrote:
> >
> > > On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote:
> > > > I don't think that this comparison is particularly apt.The
> > > > representation in HSTS is simply "I support HSTS". The representation
> > > > in HPKP is "I will use either consistent keying material *or* a
> > > > consistent set of CAs". The representation here is "I will continue
> to
> > > > have DNSSEC-signed DANE records". That is a significantly more risky
> > > > proposition than continuing to support TLS (and I'm ignoring the risk
> > > > of hijacking attacks that people were concerned with with HPKP), and
> > > > so this seems rather more like HPKP to me.
> > >
> > > Without a TTL (with zero meaning "clear the pin to DANE") this
> extension
> > > can only really be used with mandatory-to-use-with-DANE protocols,
> where
> > > the commitment to "continue to have DNSSEC-signed DANE records" is
> > > implied.
> > >
> >
> > This simply isn't true, for the reasons Richard Barnes indicated in his
> > response
> > to you.
>
> See my response to him.  For any non-mandatory use of this extension,
> without the pinning semantics there is a glaring downgrade attack.
>

I've responded to this separately.


> > HPKP had a TTL and yet as a practical matter, people found it very
> > problematic.
>
> I can see why: you have to commit to one certificate in the chain not
> changing.


No, this isn't correct, in two respects.

1. HPKP pins the SPKI, not the certificate, it's about the *key* not
changing,
and intermediates and roots change quite infrequently.
(https://tools.ietf.org/html/rfc7469#section-2.1.1)

2. It's not one key. HPKP allowed you to pin multiple keys and in fact
*required* you to set a backup pin
(https://tools.ietf.org/html/rfc7469#section-2.5)


Whereas here you only have to commit to continue to publish
> TLSA RRs (and signing them and your zone).  This is a big difference.
>

I don't think that's it all obvious that this is going to be easier to
guarantee,
especially given the rather high DNSSEC misconfiguration rate
(https://link.springer.com/content/pdf/10.1186%2Fs13388-015-0023-y.pdf,
https://indico.dns-oarc.net/event/14/contribution/14/material/slides/0.pdf).

> And, of course, if you're concerned with hijacking attacks, the
> > hijacker will just advertise a very long TTL.
>
> But it's a TOFU-ish thing.  The server impersonator has to have the
> right timing or else be detected -- that's very risky for them, and a
> deterrent to even trying.  It's not fool-proof, but it's not nothing
> either.
>

Given that the motivation for this kind of hijacking was generally
expected to be vandalism or ransom, this doesn't seem very comforting.

-Ekr


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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

On Wed, Apr 04, 2018 at 07:56:37PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams  wrote:
> > We cannot be serious about security while promoting a protocol with a
> > glaring downgrade attack.
> 
> Unfortunately, you are conflating the assertive and restrictive use cases.

I'm conflating nothing.  I want to be able to use this HTTPS with DANE,
but this extension as-is cannot be used in any protocol where it isn't
mandatory.

(Richard B. proposes that one can use this with HTTPS when using a CA
that is not likely to be trusted by some clients.  But that's hardly the
enticing use of this extension for HTTPS.  The interesting use-case is
DANE for HTTPS, with or without WebPKI, and having a method of possibly
deploying this.  By "possibly" I mean "incremental".)

> To recap, there are two potential reasons why one might want thi
> technology:
> 
> [...]

You're not being serious.  You're rationalizing the document as-is.

Nico
-- 

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

On Thu, Apr 05, 2018 at 03:04:03AM +, Richard Barnes wrote:
> And just to be clear, by "downgrade attack", you mean "normal PKI
> authentication that we rely on today".  There's nothing in here that

It's NOT that using WebOKI is a downgrade.

It's that if an operator wants to use DANE (with any usage), then they
want to use DANE.  If an impersonator can make that not happen, it's a
downgrade from the operator's perspective (because they then don't get
what they wanted).

> degrades security (except maybe the legacy crypto in the DNS); it's
> just not meeting the bar that you are setting.   That doesn't mean
> there's not still some utility to be had.

Nonsense.  The operator wants DANE?  They should be able to get it.  If
an active attacker can make that not happen at will, then that is and
can only be called a downgrade attack.  Waving your hands doesn't make
this go away.  The WebPKI's security is irrelevant to this discussion.
Only the server operator's desired outcome is relevant.  If they can't
get it, then this protocol is not useful to them.  And this protocol is
all about using DANE in TLS applications!!!

Nico
-- 

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni]

> On Apr 4, 2018, at 10:34 PM, Nico Williams  wrote:
> 
> I can see why: you have to commit to one certificate in the chain not
> changing.  Whereas here you only have to commit to continue to publish
> TLSA RRs (and signing them and your zone).  This is a big difference.

Even more strongly NOT ONLY do you not actually commit to publishing
TLSA records going forward since with (A) (denial of existence) you
can just prove they don't exist.  You can even stop using DNSSEC for
your domain entirely.  And yet still support the extension and just
furnish proof (again denial of existence) that your domain is no
longer signed (i.e. no DS records in the parent or ancestor thereof
as signed by that parent or ancestor).

THEREFORE, the pin is *precisely* just a capability pin (like STS),
saying I can present the extension, there is NO obligation to
provide any specific content in that extension.

-- 
Viktor.

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams]

On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams  wrote:
> 
> > > HPKP had a TTL and yet as a practical matter, people found it very
> > > problematic.
> >
> > I can see why: you have to commit to one certificate in the chain not
> > changing.
> 
> No, this isn't correct, in two respects.
> 
> 1. HPKP pins the SPKI, not the certificate, it's about the *key* not
> changing, and intermediates and roots change quite infrequently.
> (https://tools.ietf.org/html/rfc7469#section-2.1.1)

Either way it's the same impact: you cannot roll that key over.

Whereas with pin-to-DANE there's no such problem.  I thought I made that
clear.

> 2. It's not one key. HPKP allowed you to pin multiple keys and in fact
> *required* you to set a backup pin
> (https://tools.ietf.org/html/rfc7469#section-2.5)

The problem remains: you're pinning to key material, which complicates
key management.

> Whereas here you only have to commit to continue to publish
> > TLSA RRs (and signing them and your zone).  This is a big difference.
> >
> 
> I don't think that's it all obvious that this is going to be easier to
> guarantee, especially given the rather high DNSSEC misconfiguration
> rate
> (https://link.springer.com/content/pdf/10.1186%2Fs13388-015-0023-y.pdf,
> https://indico.dns-oarc.net/event/14/contribution/14/material/slides/0.pdf).

I flubbed that up a bit.  With the pin you commit to continue to using
this extension for as long as the clients have pinned it (which you
control via the TTL).  You can actually stop signing your zone provided
that you continue to use the extension.

> > And, of course, if you're concerned with hijacking attacks, the
> > > hijacker will just advertise a very long TTL.
> >
> > But it's a TOFU-ish thing.  The server impersonator has to have the
> > right timing or else be detected -- that's very risky for them, and a
> > deterrent to even trying.  It's not fool-proof, but it's not nothing
> > either.
> 
> Given that the motivation for this kind of hijacking was generally
> expected to be vandalism or ransom, this doesn't seem very comforting.

The motivation for opportunistically using this is to be able to
incrementally deploy DANE for HTTPS (and browsers).  Without that it
won't get deployed at all for HTTPS.

Nico
-- 

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Eric Rescorla]

On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams  wrote:

> On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote:
> > On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams 
> wrote:
> >
> > > > HPKP had a TTL and yet as a practical matter, people found it very
> > > > problematic.
> > >
> > > I can see why: you have to commit to one certificate in the chain not
> > > changing.
> >
> > No, this isn't correct, in two respects.
> >
> > 1. HPKP pins the SPKI, not the certificate, it's about the *key* not
> > changing, and intermediates and roots change quite infrequently.
> > (https://tools.ietf.org/html/rfc7469#section-2.1.1)
>
> Either way it's the same impact: you cannot roll that key over.
>
> Whereas with pin-to-DANE there's no such problem.  I thought I made that
> clear.
>

Yes, I agree that you're relying on a different guarantee from your parent
zone, I just don't think it's particularly obvious that that guarantee is
easier
to ensure, for the reasons I indicated previously.


> > And, of course, if you're concerned with hijacking attacks, the
> > > > hijacker will just advertise a very long TTL.
> > >
> > > But it's a TOFU-ish thing.  The server impersonator has to have the
> > > right timing or else be detected -- that's very risky for them, and a
> > > deterrent to even trying.  It's not fool-proof, but it's not nothing
> > > either.
> >
> > Given that the motivation for this kind of hijacking was generally
> > expected to be vandalism or ransom, this doesn't seem very comforting.
>
> The motivation for opportunistically using this is to be able to
> incrementally deploy DANE for HTTPS (and browsers).  Without that it
> won't get deployed at all for HTTPS.
>

I don't see how this is responsive to the concern that this technique will
be used for hijacking.

-Ekr


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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Martin Thomson]

On Thu, Apr 5, 2018 at 1:09 PM, Nico Williams  wrote:
> The motivation for opportunistically using this is to be able to
> incrementally deploy DANE for HTTPS (and browsers).  Without that it
> won't get deployed at all for HTTPS.

Do you have both clients and servers that are interested in this
particular approach?

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

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni]

> On Apr 4, 2018, at 1:50 PM, Joseph Salowey  wrote:
> 
> A) Recommendation of adding denial of existence proofs in the chain provided 
> by the extension
> B) Adding signaling to require the use of this extension for a period of time 
> (Pinning with TTL)
> C) Both

The discussion so far has demonstrated the need for an important clarification 
about the nature of the pinning in B):

  * The pin would not require *anything* more than continuing support for the 
extension.
  * In particular, it would not require continued presence of TLSA records, nor 
even
continued DNSSEC support by the server's domain.
  * This is because the server can respond with denial of existence of either 
its TLSA
records, or even of the the DS records for its domain or some parent domain.

This is why my claim that this is essentially like STS, and nothing like HPKP 
is valid.

A corollary of the above is that (B) requires (A).  Just (B) alone is not 
sufficient,
it is too limited a mechanism without denial of existence.

If support for the extension itself is mandatory in some application context 
(implicit
unbounded pin), then of course (A) alone is enough, but we should note that 
such implicit
indefinite pinning is fragile during partial deployment and does not protect 
applications
where the implicit requirement is not an option (incremental deployment).

Therefore, the real choice before us is (C) or not (C), the choices of (A) 
alone or (B)
alone are unsound half-measures.

(C) is essentially STS for dane chains over TLS with downgrade protection after 
first
contact, and imposes no burden on the present implementors.  If they were 
willing to
implement without a pin or denial of existence, they can ignore the pin TTL and 
never
transmit denial of existence (which their clients would not expect to process).

On the other hand, they may find after some experience that the proposed 
features
are actually useful, and might add them to their application logic.  I don't 
know
whether DANE is mandatory with DPRIV or is just an "additive" alternative to 
WebPKI.
If the latter, with the present draft it is trivially stripped, and again there 
is
little incentive to not just use WebPKI, especially if DANE support is not 
required
from all clients (thus servers need at least WebPKI).

Looking at RFC8310, I see hints of support for both WebPKI and DANE, with no 
guidance
as to how a client is to choose between them, accept either both, avoid 
downgrades
to one when the other is preferred, ...

So I rather suspect that even the DPRIV use-case, which supposedly does not need
the proposed changes, actually does need them for meaningful security from using
DANE, and we've not just not looked at the details closely enough yet.  It may
well turn out not substantially different from the browser use-case that is not
adequately met by the current draft.

Can someone explain briefly how DPRIV avoids the same downgrade issues, and
negative adoption incentives (cost-benfit comparison)?  If it turns out that
no adequate explanation is possible, and indeed the same issues are present,
then the proposed changes (which are still needed elsewhere) are all the
more pressing.

-- 
Viktor.

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