Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Shumon Huque]

On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind  wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-tls-dnssec-chain-extension-06: No Objection
>
> --
> COMMENT:
> --
>
> Two minor, mostly editorial comments:
>
> 1) Intro (sec 2): " 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."
> Is that actually a well-known problem (can you provide a reference?)


Some folks (at Google and NLnet Labs if I recall; maybe others) have done
measurements to show this is an actual problem -- for a relatively small but
still non-trivial fraction of clients. We'll try to see if we can dig up
specific
references to documents that could be cited.

or would
> it be enough to say something like this: " It also provides the
>ability to avoid potential problems with TLS clients being unable to
>look up DANE records when DNS server is not reachable."
>

Your rewording of this sentence would unfortunately not be accurate.
It's usually not the DNS server that is unreachable, but that some middlebox
has done something wrong, such as: not allow DANE queries or responses
through; not allow DNSSEC signatures through; not allow EDNS options
that enable DNSSEC through, or engage in other misbehavior.


> 2) IANA Considerations should probably be updated.
>

I guess you are suggesting that the last sentence is probably obsolete:

"If the draft is adopted by the WG, the authors expect to make an
 early allocation request as specified in [RFC7120]."

Agreed. It's a little late for that! :-)

We will remove it.

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

Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Shumon Huque]

On Wed, Feb 7, 2018 at 6:22 PM, Ben Campbell  wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-tls-dnssec-chain-extension-06: Yes
>
> --
> COMMENT:
> --
>
> I am happy to see this published, but have a few minor comments:
>
> - I agree with Alexey's comments.
>

Yup, addressed previously in email ..


>
> -3.4: "If the TLSA record set was synthesized by a DNS wildcard, the chain
>must include the signed NSEC or NSEC3 records that prove that there
>was no explicit match of the TLSA record name and no closer wildcard
>match."
>
> Should that "must" be a "MUST"?
>

Yes, thanks for catching that.


>
> - Nit in Authors List: Unless I've missed something, Richard's affiliation
> is
> no longer current. (I only point it out in case it's an oversight; I have
> no
> objection if it's that way on purpose.)
>

I'll let Richard chime in ..

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

Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Shumon Huque]

On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov 
wrote:

> Alexey Melnikov has entered the following ballot position for
> draft-ietf-tls-dnssec-chain-extension-06: Discuss
>
> --
> DISCUSS:
> --
>
> I think this is a useful document and I will ballot Yes once my small
> issues are resolved:
>
> 1) In 3.4:
>
>The first RRset in the chain MUST contain the TLSA record set being
>presented.  However, if the owner name of the TLSA record set is an
>alias (CNAME or DNAME), then it MUST be preceded by the chain of
>alias records needed to resolve it.  DNAME chains should omit
>
> SHOULD? What are the implications if this is not followed?
>

Ok. I guess we need the upper case word here, yes.

Implication: If the synthesized CNAME records are included in the chain
then the client will have to ignore them (they aren't signed and thus can't
be
validated) - the signed DNAME record is sufficient for the client to
securely
validate the mapping and continue processing.

It might make things simpler to just make this a MUST. I would guess this
would not raise any objections from the working group.


>unsigned CNAME records that may have been synthesized in the response
>from a DNS resolver.
>
> 2) TLS 1.3 needs to be a normative reference, but it is not even listed in
> References.
>

Ok, we will add it.


> --
> COMMENT:
> --
>
> The first mention of NSEC3 need a normative reference.
>

Yup, will do [RFC 5155]

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

[TLS] Ben Campbell's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: 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-dnssec-chain-extension/



--
COMMENT:
--

I am happy to see this published, but have a few minor comments:

- I agree with Alexey's comments.

-3.4: "If the TLSA record set was synthesized by a DNS wildcard, the chain
   must include the signed NSEC or NSEC3 records that prove that there
   was no explicit match of the TLSA record name and no closer wildcard
   match."

Should that "must" be a "MUST"?

- Nit in Authors List: Unless I've missed something, Richard's affiliation is
no longer current. (I only point it out in case it's an oversight; I have no
objection if it's that way on purpose.)


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

Re: [TLS] [Gen-art] Genart telechat review of draft-ietf-tls-dnssec-chain-extension-06

[Alissa Cooper]

Matt, thanks for your review. Shumon, thanks for your response. I have entered 
a No Objection ballot.

Alissa

> On Feb 6, 2018, at 11:31 PM, Shumon Huque  wrote:
> 
> On Tue, Feb 6, 2018 at 8:25 PM, Matthew Miller 
> > 
> wrote:
> Reviewer: Matthew Miller
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
>  >.
> 
> Document: draft-ietf-tls-dnssec-chain-extension-06
> Reviewer: Matthew A. Miller
> Review Date: 2018-02-06
> IETF LC End Date: 2018-02-07
> IESG Telechat date: 2018-02-08
> 
> Summary:
> 
> This document is ready, with one issue that I think could benefit
> from some clarification.
> 
> Major issues:
> 
> NONE
> 
> Minor issue:
> 
> This is more a question, that might warrant some clarification:
> In 7. Verification, the last paragraph discusses client-side
> caching of the RRsets. If a client has cached the full RRset chain
> from TLSA to root RRSIG (and that cache is still viable), is the
> client still expected to specify the "dnssec_chain" extension?
> 
> In my reading, that does not seem necessary, and I think it might
> be worth noting if that is true.
> 
> Yes, if the client has cached either the validated TLSA RRset or the 
> full chain, then it doesn't need to send the dnssec_chain for subsequent
> connections.
> 
> If it has only cached other portions of the chain, then it needs to. 
> 
> We can clarify this.
> 
> Shumon Huque
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [TLS] Recommended yes->no for max_fragment_length extension?

[Russ Housley]

I misread the question.  You are right, is should be "No".

Russ


> On Feb 7, 2018, at 3:56 PM, Martin Thomson  wrote:
> 
> This is about the OLD extension.  I think that NO is appropriate for
> something we deprecate.
> 
> https://github.com/tlswg/tls-record-limit/pull/14
> 
> On Thu, Feb 8, 2018 at 7:37 AM, Russ Housley  wrote:
>> If the WG is going to publish the standards track RFC, then the extension it 
>> defines should say 'Yes' in the recommended column.
>> 
>> Russ
>> 
>> 
>>> On Feb 7, 2018, at 3:33 PM, Sean Turner  wrote:
>>> 
>>> All,
>>> 
>>> Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG needs 
>>> to confirm that draft-ietf-tls-record-limit should change 
>>> max_fragment_length [1] from “Yes” in our soon to be created Recommended 
>>> column (see [2]) to a “No”.  Please indicate by 2359 UTC on 14 Feb whether 
>>> you are for or against this change; and if you are against please indicate 
>>> why.
>>> 
>>> spt
>>> 
>>> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/
>>> [1] https://datatracker.ietf.org/doc/rfc6066/
>>> [2] https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
>>> ___
>>> 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] Recommended yes->no for max_fragment_length extension?

[Martin Thomson]

This is about the OLD extension.  I think that NO is appropriate for
something we deprecate.

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

On Thu, Feb 8, 2018 at 7:37 AM, Russ Housley  wrote:
> If the WG is going to publish the standards track RFC, then the extension it 
> defines should say 'Yes' in the recommended column.
>
> Russ
>
>
>> On Feb 7, 2018, at 3:33 PM, Sean Turner  wrote:
>>
>> All,
>>
>> Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG needs 
>> to confirm that draft-ietf-tls-record-limit should change 
>> max_fragment_length [1] from “Yes” in our soon to be created Recommended 
>> column (see [2]) to a “No”.  Please indicate by 2359 UTC on 14 Feb whether 
>> you are for or against this change; and if you are against please indicate 
>> why.
>>
>> spt
>>
>> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/
>> [1] https://datatracker.ietf.org/doc/rfc6066/
>> [2] https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
>> ___
>> 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] Recommended yes->no for max_fragment_length extension?

[Eric Rescorla]

I am for this change.

-Ekr


On Wed, Feb 7, 2018 at 12:33 PM, Sean Turner  wrote:

> All,
>
> Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG needs
> to confirm that draft-ietf-tls-record-limit should change
> max_fragment_length [1] from “Yes” in our soon to be created Recommended
> column (see [2]) to a “No”.  Please indicate by 2359 UTC on 14 Feb whether
> you are for or against this change; and if you are against please indicate
> why.
>
> spt
>
> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/
> [1] https://datatracker.ietf.org/doc/rfc6066/
> [2] https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
> ___
> 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] Recommended yes->no for max_fragment_length extension?

[Russ Housley]

If the WG is going to publish the standards track RFC, then the extension it 
defines should say 'Yes' in the recommended column.

Russ


> On Feb 7, 2018, at 3:33 PM, Sean Turner  wrote:
> 
> All,
> 
> Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG needs to 
> confirm that draft-ietf-tls-record-limit should change max_fragment_length 
> [1] from “Yes” in our soon to be created Recommended column (see [2]) to a 
> “No”.  Please indicate by 2359 UTC on 14 Feb whether you are for or against 
> this change; and if you are against please indicate why.
> 
> spt
> 
> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/
> [1] https://datatracker.ietf.org/doc/rfc6066/
> [2] https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
> ___
> 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] Recommended yes->no for max_fragment_length extension?

[Sean Turner]

All,

Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG needs to 
confirm that draft-ietf-tls-record-limit should change max_fragment_length [1] 
from “Yes” in our soon to be created Recommended column (see [2]) to a “No”.  
Please indicate by 2359 UTC on 14 Feb whether you are for or against this 
change; and if you are against please indicate why.

spt

[0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/
[1] https://datatracker.ietf.org/doc/rfc6066/
[2] https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss

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-dnssec-chain-extension/



--
DISCUSS:
--

I think this is a useful document and I will ballot Yes once my small issues 
are resolved:

1) In 3.4:

   The first RRset in the chain MUST contain the TLSA record set being
   presented.  However, if the owner name of the TLSA record set is an
   alias (CNAME or DNAME), then it MUST be preceded by the chain of
   alias records needed to resolve it.  DNAME chains should omit

SHOULD? What are the implications if this is not followed?

   unsigned CNAME records that may have been synthesized in the response
   from a DNS resolver.

2) TLS 1.3 needs to be a normative reference, but it is not even listed in 
References.


--
COMMENT:
--

The first mention of NSEC3 need a normative reference.


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

[TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss

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-dnssec-chain-extension/



--
DISCUSS:
--




This draft seems generally sound, but I believe there are pieces that
are still underspecified. These should be easy to fix.

the Signer's Name field in canonical form and the signature field
   excluded.

IMPORTANT: I'm not sure that this is actually sufficient to allow an
independent implementation without referring to the other documents. I
mean, I think I pretty clearly can't validate this chain from the
above. Similarly, although I think this is enough to break apart the
RRSETs into RRs, it doesn't tell me how to separate the RRSETs from
each other. I think you need to either make this a lot more complete
or alternately stop saying it's sufficient.



   abort the connection, the server uses the domain name associated with
   the server IP address to which the connection has been established.
IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple names 
for the same IP.


   DNSSEC authentication chain extension from a server, SHOULD use this
   information to perform DANE authentication of the server.  In order
   to do this, it uses the mechanism specified by the DNSSEC protocol

IMPORTANT: What happens if the DANE validates but the cert is revoked
or alternately the cert validates but DANE does not?


[RFC4035] [RFC5155].  This mechanism is sometimes implemented in a
   DNSSEC validation engine or library.
IMPORTANT: shouldn't it be a requirement to perform this validation?


--
COMMENT:
--



typically not be used for general DNSSEC validation of TLS endpoint
   names.
Can you rephrase this. I *think* it means "it's not used to validate the A/
lookup"...?

   validation of endpoint names, but is more appropriate for validation
   of DANE TLSA records.
Same comment as abive

   This mechanism is useful for TLS applications that need to address
   the problems described above, typically web browsers or VoIP and XMPP
   applications.  It may not be relevant for many other applications.
Nit; cites to SIP/XMPP appropriate here,

   ClientHello message that the DNS authentication chain be returned in
   the (extended) ServerHello message.  If the server is configured for
   DANE authentication, then it performs the appropriate DNS queries,
This is not correct for TLS 1.3.

3.1.  Protocol, TLS 1.2
You should probably provide some guidance about whether the server should still
provide the whole X.509 chain to the client. I believe with these semantics,
the server cannot tell which DANE mode the client wants and therefore has to
provide the entire chain.

   Servers receiving a "dnssec_chain" extension in the ClientHello, and
   which are capable of being authenticated via DANE, MAY return a
   serialized authentication chain in the extended ServerHello message,
Nit: I believe you want to remove the commas here, as they indicate a
nonrestrictive clause.

   arbitrary domain names using this mechanism.  Therefore, a server
   MUST NOT construct chains for domain names other than its own.
"its own" is a bit fraught, as servers may not actually know all their domain
names, at least at the TLS layer.. Can you be more specific about what the
server algorithm is.

   Servers receiving a "dnssec_chain" extension in the ClientHello, and
   which are capable of being authenticated via DANE, SHOULD return a
   serialized authentication chain in the extension block of the
Why is this a SHOULD where the corresponding reqt for TLS 1.2 and below is a
MAY?

   to a DNSSEC trust root.  This has the added benefit of mitigating an
   unknown key share attack, as described in [I-D.barnes-dane-uks],
   since it effectively augments the raw public key with the server's
"unknown key share (UKS)"

   handshake, to a domain name which has been validated as belonging to
   the owner name.
The key point here is that the commitment is bound to the EE key. Also, this
only really works for TLS 1.3 and modes with EMS because otherwise there are
other UKS attacks

I think you probably want to cite SIGMA and triple handhshake here.

 opaque AuthenticationChain<0..2^16-1>
Is 0 actually appropriate here as a lower bound? Presumably at least one such
instance 

[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Mirja Kühlewind]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: 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-dnssec-chain-extension/



--
COMMENT:
--

Two minor, mostly editorial comments:

1) Intro (sec 2): " 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."
Is that actually a well-known problem (can you provide a reference?) or would
it be enough to say something like this: " It also provides the
   ability to avoid potential problems with TLS clients being unable to
   look up DANE records when DNS server is not reachable."

2) IANA Considerations should probably be updated.


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