Re: [TLS] Duplicate oid_filters

[Sean Turner]

Okay so the OIDs can’t appear twice in the certificate, because certificate 
extensions are only supposed to appear once so why don’t we just follow suit 
and require no dupes?

spt

> On Mar 9, 2018, at 16:44, Benjamin Kaduk  wrote:
> 
> (See also https://github.com/tlswg/tls13-spec/issues/1179)
> 
> On 03/09/2018 03:35 PM, Eric Rescorla wrote:
>> See issue #1166.
>> 
>> The current text neither allows nor prohibits the same OID appearing
>> twice. We should do one or the other.
>> 
> 
> ___
> 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] Alexey Melnikov's Discuss on draft-ietf-tls-tls13-26: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Wed, Mar 7, 2018 at 6:16 AM, Eric Rescorla  wrote:

>
>
> On Wed, Mar 7, 2018 at 5:29 AM, Alexey Melnikov 
> wrote:
>
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-tls-tls13-26: 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-tls13/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> Thank you for a well written document. I will be switching to Yes once the
>> following is addressed/discussed:
>>
>> Relationship to TLS 1.2 needs to be clarified. The document is adding
>> requirements on TLS 1.2 clients. Implementors of TLS 1.2 are not going to
>> (or
>> very unlikely to) read this document. This looks fishy to me. Two
>> examples on
>> page 37:
>>
>>   TLS 1.2 clients SHOULD also check that the last eight bytes  are not
>> equal to
>>   the second value if the ServerHello indicates TLS  1.1 or below
>>
>> and
>>
>>  A legacy TLS client performing renegotiation with TLS 1.2 or prior  and
>> which
>>  receives a TLS 1.3 ServerHello during renegotiation MUST  abort the
>> handshake
>>  with a "protocol_version" alert.  Note that  renegotiation is not
>> possible
>>  when TLS 1.3 has been negotiated.
>>
>> There are similar statements on page 45:
>>
>>   TLS 1.2 implementations SHOULD also process this extension.
>>
>> and on page 48:
>>
>>   However, the old semantics did not constrain the signing
>>   curve.  If TLS 1.2 is negotiated, implementations MUST be prepared
>>   to accept a signature that uses any curve that they advertised in
>>   the "supported_groups" extension.
>>
>> I think you need to clarify whether these normative requirements apply to
>> pure
>> TLS 1.2 clients or TLS clients that implement both 1.2 and 1.3 and choose
>> to
>> use 1.2 for some reason. Or maybe you need to say in the
>> Abstract/Introduction
>> that although this document obsoletes TLS 1.2 it also specifies new
>> requirements on TLS 1.2 implementations. (So it is sort of both
>> "Obsoletes" and
>> "Updates" TLS 1.2 RFC.)
>>
>
>
> The intent is that these affect old TLS 1.2 implementations as well. S 1.4
> tries
> to be clear about this, but maybe it fails.
>
> I suggest we:
>
> (1) Add the following sentence to the abstract:
> "This document also specifies new requirements for TLS 1.2 implementations.
>
> (2) Rewrite the first sentence of S 1.4 to say:
>This document defines several changes that optionally affect
>implementations of TLS 1.2, including those which do not also
>support TLS 1.3
>
> (3) Strike the following graf:
>
>An implementation of TLS 1.3 that also supports TLS 1.2 might need to
>include changes to support these changes even when TLS 1.3 is not in
>use.  See the referenced sections for more details.
>
>
>
>
>>
>> --
>> COMMENT:
>> --
>>
>> 1) On page 47:
>>  The length of the salt MUST be equal to the length of the digest
>> algorithm
>>
>> Length of algorithm?
>>
>
> Right. Output of.
>
>
>
>>
>> 2) DER need a Normative Reference on first use. There are some references
>> on
>> 2nd/3rd use.
>>
>
> Thanks.
>

I just double-checked and this actually is: under ECDSA.


>
>
>>
>> 3) On page 57:
>>
>>The
>>server then ignores early data by attempting to decrypt received
>>records in the handshake traffic keys until it is able to receive
>>the client's second flight and complete an ordinary 1-RTT
>>handshake, skipping records that fail to decrypt, up to the
>>configured max_early_data_size.
>>
>> I read this several times and still don't understand what this is saying.
>> It is
>> saying "ignores ... until it is able to receive". I think you either
>> don't mean
>> "ignore" (as in discard the rest) or I misunderstood. I clarifying
>> example or a
>> reference to another section (e.g. with the diagram) would be very
>> helpful here.
>>
>
> We do mean discard. The idea here is that you try to decrypt those records
> using the handshake keys and if that fails you ignore them.
>
>
>> 4) On page 82:
>>
>>When record protection has not yet been engaged, TLSPlaintext
>> structures
>>are written directly onto the wire.  Once record  protection has
>> started,
>>TLSPlaintext records are protected and sent   as described in the
>> following
>>section
>>
>> Just to double check: are you saying that before the 

Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-tls13-26: (with COMMENT)

[Eric Rescorla]

Following up.

> §4.1.2, first paragraph: " When a client first connects to a server, it
is REQUIRED to send the
>ClientHello as its first message. "
>
> Is that intended to prohibit the use of STARTTLS or similar application
layer patterns?
> (To be clear, this is not an objection, just a clarification request.)

This was clarified.


> §4.1.2, legacy_compression_methods: "Note that TLS 1.3 servers might
receive TLS 1.2 or prior
>   ClientHellos which contain other compression methods and MUST
>   follow the procedures for the appropriate prior version of TLS."
>
> Is that intended to require TLS 1.3 servers to always be willing and able
to negotiate 1.2? §4.2.1

We clarified this text.


> has a similar assertion:
>
> "If this extension is not present, servers which are compliant with
>this specification MUST negotiate TLS 1.2 or prior as specified in
>[RFC5246], even if ClientHello.legacy_version is 0x0304 or later."

I added a clarification here.


> But §4.2.3 says:
>
>  "Note that TLS 1.2 defines this extension differently.  TLS 1.3
>implementations willing to negotiate TLS 1.2 MUST behave in
>accordance with the requirements of [RFC5246] when negotiating that
>version."
>
> ... which seems inconsistent (noting that this paragraph talks about
"implementations"
> rather than "servers", so perhaps there's a subtle difference?

The extension was relevant for clients and servers in TLS 1.2.


> §4.2.1.1: The section is marked for removal. Do you expect that RFC
implementations
> will ever need to interop with draft implementations? If so, the
information in this section
> may continue to be useful for some time.

RFC implementations don't interop with draft implementations in any
meaningful way. I.e., they just negotiate TLS 1.2.

>
> §D.5: This section has a lot of normative requirements that seem
important. I wonder why it has been
> relegated to an appendix.o

Because they are levies in the non-TLS 1.3 portions of the imp.



> *** Editorial Comments and nits:
>
> §2: "If (EC)DHE key establishment
>is in use, then the ServerHello contains a "key_share" extension with
>the server’s ephemeral Diffie-Hellman share which MUST be in the same
>group as one of the client’s shares. "
>
> missing comma prior to "which".

I made a slightly different change.


> §4.1.1: "Note that if the PSK can be used without (EC)DHE then non-
>overlap in the "supported_groups" parameters need not be fatal, as it
>is in the non-PSK case discussed in the previous paragraph."
>
> I read "need not be fatal" to mean that it may still be fatal at times.
Is that the intent?

Yes. Suppose you could only use the PSK with ECDHE. That's what the "if the
PSK can be used..."
is about.


> §11: The IANA considerations have a number of constructions similar to
"SHALL update/has updated".
> Is that text expected to collapse to "has updated" at some point?

Yes. RFC-Ed typically does this.

-Ekr


On Wed, Mar 7, 2018 at 5:47 PM, Eric Rescorla  wrote:

>
>
> On Wed, Mar 7, 2018 at 4:39 PM, Sean Turner  wrote:
>
>>
>>
>> > On Mar 7, 2018, at 16:35, Ben Campbell  wrote:
>> >
>> >
>> >
>> >> On Mar 7, 2018, at 2:49 PM, Sean Turner  wrote:
>> >>
>> >>
>> >>
>> >>> On Mar 6, 2018, at 12:27, Ben Campbell  wrote:
>> >>>
>> >>> Ben Campbell has entered the following ballot position for
>> >>> draft-ietf-tls-tls13-26: 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/stat
>> ement/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-tls13/
>> >>>
>> >>>
>> >>>
>> >>> 
>> --
>> >>> COMMENT:
>> >>> 
>> --
>> >>>
>> >>> There has clearly been a lot of work put into this. It's a
>> surprisingly
>> >>> understandable document, given its length and the complexity of the
>> subject. I
>> >>> am balloting yes, but I have a few minor comments and nits. None of
>> these are
>> >>> showstoppers, so please do with them as you will.
>> >>>
>> >>> *** Substantive Comments:
>> >>>
>> >>> §4.1.2, first paragraph: " When a client first connects to a server,
>> it is
>> >>> REQUIRED to send the
>> >>> ClientHello as its first message. "
>> >>>
>> >>> Is that intended to prohibit the use of STARTTLS or similar
>> application layer
>> >>> patterns? (To be clear, this is not an objection, just a
>> clarification request.)
>> >>
>> >> No - this is just how it works TLS - clients send the ClientHello
>> 

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

Kathleen,

On 09/03/18 21:57, Kathleen Moriarty wrote:
> Hello, Stephen.
> 
> On Fri, Mar 9, 2018 at 4:24 PM, Stephen Farrell
>  wrote:
>>
>> Hi Joe,
>>
>> I'm sorry, but I gotta say that answer seems to me both unresponsive
>> to the questions asked and unconvincing.
>>
>> On 08/03/18 23:08, Joseph Salowey wrote:
>>> Hi Stephen,
>>>
>>> In the meeting in Prague there was interest in this problem space, but
>>> neither the consensus to accept or reject this work.
>>
>> Without rough consensus to adopt, the work is not adopted.
>>
>> But your statement above isn't accurate - it wasn't "this work"
>> (as in this draft) that was discussed in Prague, but rather the
>> entire idea of weakening TLS in these ways - quoting from the
>> Prague minutes [1]:
>>
>> "The main question: Is this subject something that the WG should
>> consider?"
> 
> The hummed answer to that question was very close to 50/50 in the
> room, inconclusive.

I'm sorry to disagree but it was entirely clear there was a
lack of consensus. That's the significant thing here. And
there is zero evidence that anyone's changing their position.

That ought be enough for the chairs to say no to all proposals
in this space unless someone turns up with something unexpected.

That's not the case here - in discussion of this draft, various
folks asked on the list that we stop the constant debate about
making TLS worse, so there is zero evidence that this draft is
going to change people's minds.

Where am I wrong?

> 
>>
>> There is clearly no consensus to adopt *any* work in this space,
>> whether that be draft-green or this latest iteration from Russ
>> and Ralph.
> 
> It was clear that there was no consensus to adopt draft-green and that
> is considered dead in the water, we agree there. 

The question asked in Prague was not specific to draft-green.
I would have preferred if it had been and Lucy Lynch suggested
that in fact (so say the minutes) but the chairs conferred and
asked a much more general question. The consequence is that
Russ and Ralph's draft, having been discussed on the list, with
no evidence that it's changed minds, ought not be taken further
in the WG and ought not get agenda time.

Where am I wrong?

> Since there was
> interest (50% of the room) to consider work in this space, I agree
> with the chairs assessment to allow this presentation.  I am confident
> they will work on any hums to carefully assess next steps and if any
> future proposals belong in this WG or elsewhere.

Again, I'm sorry but that's just not logical. There's abundant
evidence that people's opinions have not changed from the earlier
discussion of Russ and Ralph's draft so it makes no sense at all
to repeatedly impose this divisive topic on the WG.

S.


> 
>>
>> I see nothing whatsoever to indicate any significant change in
>> sets of opinions since Prague.
>>
>> What makes you think iterating on yet more proposals like this
>> will ever conclude? If there's no evidence of that we ought not
>> waste the time and energy. Can you point at any change that
>> could possibly indicate that this bun-fight is worth doing yet
>> again?
>>
>>>  The authors have
>>> revised their proposal to address some of the concerns raised by working
>>> group members and are asking to bring the new approach in front of the
>>> working group.
>>
>> What significant change has there been since -00 of Russ and Ralph's
>> draft? I see nothing major there. that -00 was debated on the list
>> which is the primary place for  discussion. My read of that set of
>> threads it that it pretty clearly showed that the same folks have
>> the same opinions with no significant movement. Can you point at
>> some evidence to the contrary? If not, we shouldn't bother to waste
>> more time on this.
>>
>> If instead you mean Russ and Ralph's draft differs from draft-green,
>> then see above - it wasn't only draft-green that was rejected in
>> Prague, but the entire idea of adopting work in this space, which
>> includes Russ and Ralph's -00 and -01.
>>
>> That the authors have asked for time counts for nothing, when the
>> WG have no consensus to work in this space. If just asking for time
>> does matter, then I'll now publicly repeat my request for time
>> to refure the assertions that'll be made for breaking TLS. You said
>> no to my request, so what's different about one that relates to a
>> draft that has been debated on the list and attracted significant
>> negative comment?
>>
>>> I believe in this case this is the right thing to do even
>>> if it appears there is some repetition of topic.
>>
>> It is not "some repetition" - this topic has been debated f2f and
>> on this draft on the list and there's zero evidence of significant
>> changes in opinion, in fact the opposite. Can you point at any
>> such evidence? If not, your position as chairs seems illogical.
>>
>>> However, if the new
>>> approach fails to achieve significantly more support I believe the authors
>>> will 

Re: [TLS] Duplicate oid_filters

[Andrei Popov]

It should be OK to restrict to one appearance of the same OID, if there is a 
desire to do so.

-Original Message-
From: TLS  On Behalf Of Benjamin Kaduk
Sent: Friday, March 9, 2018 1:45 PM
To:  
Subject: Re: [TLS] Duplicate oid_filters

(See also 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Ftls13-spec%2Fissues%2F1179=04%7C01%7CAndrei.Popov%40microsoft.com%7Cddb0cb5ca2684dcdf7d708d58607050a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636562287068258523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-2=3QfikwA9T0ScU6Yw9T%2Fo3IDhmj1zYgcJzye1sx5M%2Bp0%3D=0)

On 03/09/2018 03:35 PM, Eric Rescorla wrote:
> See issue #1166.
>
> The current text neither allows nor prohibits the same OID appearing 
> twice. We should do one or the other.
>

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=04%7C01%7CAndrei.Popov%40microsoft.com%7Cddb0cb5ca2684dcdf7d708d58607050a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636562287068258523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-2=ArdtWlWWMO0DfeuREq%2F1ab8vNFhxvhoLW1yWIz089Oc%3D=0

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Kathleen Moriarty]

Hello, Stephen.

On Fri, Mar 9, 2018 at 4:24 PM, Stephen Farrell
 wrote:
>
> Hi Joe,
>
> I'm sorry, but I gotta say that answer seems to me both unresponsive
> to the questions asked and unconvincing.
>
> On 08/03/18 23:08, Joseph Salowey wrote:
>> Hi Stephen,
>>
>> In the meeting in Prague there was interest in this problem space, but
>> neither the consensus to accept or reject this work.
>
> Without rough consensus to adopt, the work is not adopted.
>
> But your statement above isn't accurate - it wasn't "this work"
> (as in this draft) that was discussed in Prague, but rather the
> entire idea of weakening TLS in these ways - quoting from the
> Prague minutes [1]:
>
> "The main question: Is this subject something that the WG should
> consider?"

The hummed answer to that question was very close to 50/50 in the
room, inconclusive.

>
> There is clearly no consensus to adopt *any* work in this space,
> whether that be draft-green or this latest iteration from Russ
> and Ralph.

It was clear that there was no consensus to adopt draft-green and that
is considered dead in the water, we agree there.  Since there was
interest (50% of the room) to consider work in this space, I agree
with the chairs assessment to allow this presentation.  I am confident
they will work on any hums to carefully assess next steps and if any
future proposals belong in this WG or elsewhere.

>
> I see nothing whatsoever to indicate any significant change in
> sets of opinions since Prague.
>
> What makes you think iterating on yet more proposals like this
> will ever conclude? If there's no evidence of that we ought not
> waste the time and energy. Can you point at any change that
> could possibly indicate that this bun-fight is worth doing yet
> again?
>
>>  The authors have
>> revised their proposal to address some of the concerns raised by working
>> group members and are asking to bring the new approach in front of the
>> working group.
>
> What significant change has there been since -00 of Russ and Ralph's
> draft? I see nothing major there. that -00 was debated on the list
> which is the primary place for  discussion. My read of that set of
> threads it that it pretty clearly showed that the same folks have
> the same opinions with no significant movement. Can you point at
> some evidence to the contrary? If not, we shouldn't bother to waste
> more time on this.
>
> If instead you mean Russ and Ralph's draft differs from draft-green,
> then see above - it wasn't only draft-green that was rejected in
> Prague, but the entire idea of adopting work in this space, which
> includes Russ and Ralph's -00 and -01.
>
> That the authors have asked for time counts for nothing, when the
> WG have no consensus to work in this space. If just asking for time
> does matter, then I'll now publicly repeat my request for time
> to refure the assertions that'll be made for breaking TLS. You said
> no to my request, so what's different about one that relates to a
> draft that has been debated on the list and attracted significant
> negative comment?
>
>> I believe in this case this is the right thing to do even
>> if it appears there is some repetition of topic.
>
> It is not "some repetition" - this topic has been debated f2f and
> on this draft on the list and there's zero evidence of significant
> changes in opinion, in fact the opposite. Can you point at any
> such evidence? If not, your position as chairs seems illogical.
>
>> However, if the new
>> approach fails to achieve significantly more support I believe the authors
>> will need to find another path for their work that does not go through the
>> TLS working group.
>
> But the WG has already demonstrated a lack of consensus to even
> consider "work in this space" (your choice of words I believe.)
> That should be enough. What does or doesn't happen outside the
> TLS WG is not at issue here.
>
> To reiterate, in Prague you asked "The main question: Is this subject
> something that the WG should consider?" The result was a clear lack of
> any consensus to work in this space, which means not working in this
> space. Yet here we are again giving agenda time to highly controversial
> proposals in this space.
>
> Please: just take this off the agenda and let the WG do it's real work.
>
> Thanks,
> S.
>
> [1] https://datatracker.ietf.org/meeting/99/materials/minutes-99-tls

Relevant comment from minutes:
Hums: No clarity whatsoever. Seemed pretty even.

Best,
Kathleen

>
>>
>> Cheers,
>>
>> Joe
>>
>> On Thu, Mar 8, 2018 at 9:21 AM, Stephen Farrell 
>> wrote:
>>
>>>
>>> Hi Sean, Joe,
>>>
>>> On 08/03/18 16:20, Sean Turner wrote:
 I’ve posted the draft agendas:

 Monday:
   https://datatracker.ietf.org/meeting/101/materials/agenda-
>>> 101-tls-sessb
>>>
>>> That includes:
>>> "
>>> TLS Vizability - Russ & Chairs - 30min
>>>  - 10min draft - Russ
>>>   https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
>>>  - 

Re: [TLS] Duplicate oid_filters

[Benjamin Kaduk]

(See also https://github.com/tlswg/tls13-spec/issues/1179)

On 03/09/2018 03:35 PM, Eric Rescorla wrote:
> See issue #1166.
>
> The current text neither allows nor prohibits the same OID appearing
> twice. We should do one or the other.
>

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

[TLS] Duplicate oid_filters

[Eric Rescorla]

See issue #1166.

The current text neither allows nor prohibits the same OID appearing twice.
We should do one or the other.

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