[TLS] Comments on draft-ietf-tls-sni-encryption-01.txt

[R du Toit]

I have analyzed the two mechanisms proposed in the draft, with specific focus 
on the impact of middleboxes. 

 

Assumptions:

The middlebox is deployed inline, between the client and the fronting server, 
and is allowed to intercept TLS sessions.  The middlebox is policy-driven, and 
uses SNI as an input in determining whether or not to intercept the session; 
the policy must use the SNI of the hidden server.

 

Mechanism #1 : Tunnel ClientHello in 0-RTT early data.

(1) Mechanism #1 requires 0-RTT support, but the middlebox would not be 
violating the TLS 1.3 specification by not implementing 0-RTT.  The middlebox 
intercepts all sessions destined to a specific fronting server (F); the 
identity of F should be public knowledge, but even if it is not, we have to 
assume that the middlebox has a mechanism to decide when to intercept sessions 
destined to F.  

 

(2) Assume that the middlebox actually supports PSK and 0-RTT, i.e. TLS 
intercept with PSK/0-RTT support in the session between the client and the 
middlebox, as well as PSK/0-RTT support in the session between the middlebox 
and the fronting server.  The middlebox will be able to decode ClientHello#2 
sent in the 0-RTT early data because the client_early_traffic_secret will be 
known to the middlebox.  The middlebox would thus have access to the SNI of the 
hidden server, and would be able to evaluate policy.  The middlebox would have 
the option to pull out of the session after sending ClientHello#2 to the 
fronting server (re-encrypted with the client_early_traffic_secret shared 
between the middlebox and the fronting server).

 

Mechanism #2: Session ticket that can be decoded by Fronting and Hidden server.

(3) Mechanism #2 relies on PSK session resumption support in the middlebox; 
this is not guaranteed.

 

(4) The middlebox would not participate or interfere in any of the out-of-band 
channels between the fronting server and the hidden server, which implies that 
the middlebox will not be able to decode the session ticket generated by the 
hidden server - but it does not have to.  The middlebox would be able to 
observe the encoded session ticket in the NewSessionTicket message because it 
intercepts the initial TLS session between the client and the hidden server 
(even if mechanism #1 is used for the first session).  The middlebox would thus 
be able to extract the SNI of the hidden server from the NewSessionTicket 
message and build a mapping of encoded session tickets to hidden servers. TLS 
sessions (destined to the fronting server) that were not previously intercepted 
by the middlebox will use PSK identities that are not in the mapping table - 
the middlebox would likely force intercept of those sessions and strip the 
unknown PSK identities, which would result in a TLS session that terminates on 
the fronting server, leaving the fronting server without any knowledge of the 
hidden server.

 

(5) Ignoring middleboxes, in my opinion the infrastructure required for 
collaboration between fronting servers and hidden servers (stateful, 
shared-key, public-key, or otherwise) would be a practical barrier to entry for 
most server administrators.

 

 

--Roelof

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

Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Martin Thomson]

I think that the current behavior is fine, but we might add text to
suggest that identities be self-authenticating to avoid this sort of
enumeration.  Note that in common practice, this sort of enumeration
would be over an infeasibly large space, it's only where identities
are more easily enumerable that it becomes an issue (e.g., "ted" as an
identity, rather than a self-encrypted session ticket)

On Thu, Feb 22, 2018 at 1:31 AM, Eric Rescorla  wrote:
> i think your general point is sound here, but I'll nitpick the statement
> that
> "if the server recognises an identity but is unable to verify corresponding
> binder".
>
> 1. The server only picks one identity so you if you send A, B, and C and you
> get an abort, you don't know if it recognized one or all.
> 2. The server can *recognize* the identity but ignore it (say it's a ticket
> that's
> too old)
>
> With that said, I think it would probably be safe to say you must ignore an
> identity
> where the binder doesn't validate, but I'd like to hear from cryptographers
> on this
> one.
>
> Thanks,
> -Ekr
>
>
> On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kario  wrote:
>>
>> On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote:
>> > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario  wrote:
>> > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
>> > > > The IESG has received a request from the Transport Layer Security WG
>> > >
>> > > (tls)
>> > >
>> > > > to consider the following document: - 'The Transport Layer Security
>> > > > (TLS)
>> > > > Protocol Version 1.3'
>> > > >
>> > > >as Proposed Standard
>> > >
>> > > The current draft states that if the server recognises an identity but
>> > > is
>> > > unable to verify corresponding binder, it "MUST abort the handshake"
>> >
>> > Which text are you referring to here?
>>
>> Section 4.2.11:
>>
>>Prior to accepting PSK key establishment, the server MUST validate
>>the corresponding binder value (see Section 4.2.11.2 below).  If this
>>value is not present or does not validate, the server MUST abort the
>>handshake.  Servers SHOULD NOT attempt to validate multiple binders;
>>rather they SHOULD select a single PSK and validate solely the binder
>>that corresponds to that PSK.
>>
>> > -Ekr
>> >
>> > at the same time, they "SHOULD select as single PSK and validate solely
>> > the
>> >
>> > > binder that corresponds to that PSK"
>> > > (Page 60, draft-ietf-tls-tls13-24).
>> > >
>> > > That allows for trivial enumeration of externally established
>> > > identities -
>> > > the
>> > > attacker just needs to send to the server a list of identity guesses,
>> > > with
>> > > random data as binders, if the server recognises any identity it will
>> > > abort
>> > > connection, if it doesn't, it will continue to a non-PSK handshake.
>> > >
>> > > Behaviour like this is generally considered a vulnerability:
>> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190
>> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229
>> > >
>> > > I was wondering if the document shouldn't recommend ignoring any and
>> > > all
>> > > identities for which binders do not verify to prevent this kind of
>> > > attack.
>> > > --
>> > > 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
>> > > ___
>> > > 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
>
>

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

Re: [TLS] Opsdir telechat review of draft-ietf-tls-record-limit-02

[Martin Thomson]

Thanks Éric.

https://github.com/tlswg/tls-record-limit/pull/16 fixes your nit.

On Thu, Feb 22, 2018 at 12:46 AM, Éric Vyncke  wrote:
> Reviewer: Éric Vyncke
> Review result: Has Nits
>
> Reviewer: Eric Vyncke
> Review results: has nits
>
> Hello Martin,
>
> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These 
> comments
> were written with the intent of improving the operational aspects of the IETF
> drafts.
>
> The document is about an extension to TLS (record_size_limit) allowing
> endpoints to negotiate the maximum size of protected records. The document 
> also
> deprecates a previous extension max_fragment_length.
>
> The different scenarios (whether endpoints support this option or not) as well
> as behavior of future versions of TLS are specified. Section 5 also describes
> the behavior when endpoints use the proposed and the deprecated TLS options.
>
> Nits in section 5: "MUST ignore *and* "max_fragment_length""
>
> This is a short document and IMHO all operational issues are well documented
> and correct.
>
> -éric
>
>

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

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

[Eric Rescorla]

On Wed, Feb 21, 2018 at 11:21 AM, Paul Wouters  wrote:

> On Thu, 8 Feb 2018, Viktor Dukhovni wrote:
>
> For clients that do reject PKIX success based on DANE failure, and
>> cache obtained TLSA records, it might have been good to recommend
>> refreshing the TLSA records while the cached data is still valid
>> (say the smaller of some refresh time or 50% of TTL has expired).
>> That way, for a client that keeps communicating regularly may be
>> (partially) protected against downgrades.  Perhaps it is too late
>> to make such a change at this stage in the document's life-cycle.
>>
>
> Is it customary for TLS clients that do PKIX validation to check the
> certificate expiry for long lived TLS connections?
>
> I assumed most TLS clients verification is done at the start of the
> connection only and the connection is then deemed verified until it
> closes - irrespective of the signature lifetimes of the certificate?
>

To the best of my knowledge you are correct.

-Ekr


>
> Paul
>
> ___
> 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] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Viktor Dukhovni]

> On Feb 21, 2018, at 2:21 PM, Paul Wouters  wrote:
> 
>> For clients that do reject PKIX success based on DANE failure, and
>> cache obtained TLSA records, it might have been good to recommend
>> refreshing the TLSA records while the cached data is still valid
>> (say the smaller of some refresh time or 50% of TTL has expired).
>> That way, for a client that keeps communicating regularly may be
>> (partially) protected against downgrades.  Perhaps it is too late
>> to make such a change at this stage in the document's life-cycle.
> 
> Is it customary for TLS clients that do PKIX validation to check the
> certificate expiry for long lived TLS connections?

The text you're responding to is NOT about long-lived TLS connections,
rather it addresses the case where the client makes repeated connections
frequently enough to benefit from caching previously obtained TLSA
records for verifying future connections.  In that case it makes sense
to "refresh" the TLSA records (include the extension in a new request)
even before the previously cached data has expired.

> I assumed most TLS clients verification is done at the start of the
> connection only and the connection is then deemed verified until it
> closes - irrespective of the signature lifetimes of the certificate?

Correct, but not applicable to the topic at hand.

-- 
Viktor.

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

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

[Paul Wouters]

On Wed, 21 Feb 2018, Shumon Huque wrote:


Okay, got it. For people that have already implemented this, I think
there has been an implicit understanding that the format of the chain
data is a sequence of concatenated wire format RRs exactly as they appear
in a DNS message section


Note, I would not call it "sequence of concatenated wire format RRs", as
it is simply the wireformat of a DNS message. The fact that some parts
are concatenated RR's is just part of the wireformat of the DNS reply
message. That is, this isn't introducing some new form of concatenated
content - it is _just_ a regular DNS wire format message, and the
document should not go deeper into its explanation.

I noticed some discussion about the ordering of this content. I am not
sure why that should be done. DNS doesn't care about the order, and
neither should producers or consumers of this extension. DNS has no
ordering inside its message. In pseudo code, they should simply:

while(not stuck and not empty(RRlist)):
stuck = True
for each RR in RRlist:
if validated_with_cache(RR):
add_to_cache(RR)
remove_from_RRlist(RR)
stuck = False

And then the order of RRs doesn't matter.


I don't think getting unrelated DNSSEC records would be an issue. TLS
has its maximum sizes for the handshake. In fact, it could allow the
extension to have some useful data in the case of MX or SRV.  (and could
be a feature to build a nice resolver over TLS using 1 tor circuit)

I'm also not sure about the talking of unsigned CNAME records from
DNAME. The above pseudo code (extended with special cases) should be
in some DNS library, and that library will know what records to expect
unsigned which are proven by the DNAME (or wildcard) synthesis and knows
when/if to add it to the validated cache. I don't think that should be
explained in this RFC at all. The DNS implementation does not need
to be specified in this document and it should just focus on saying
that "the DNS message response is validated and upon validation the
content can be considered DANE validated".

Paul

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

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

[Paul Wouters]

On Thu, 8 Feb 2018, Viktor Dukhovni wrote:


For clients that do reject PKIX success based on DANE failure, and
cache obtained TLSA records, it might have been good to recommend
refreshing the TLSA records while the cached data is still valid
(say the smaller of some refresh time or 50% of TTL has expired).
That way, for a client that keeps communicating regularly may be
(partially) protected against downgrades.  Perhaps it is too late
to make such a change at this stage in the document's life-cycle.


Is it customary for TLS clients that do PKIX validation to check the
certificate expiry for long lived TLS connections?

I assumed most TLS clients verification is done at the start of the
connection only and the connection is then deemed verified until it
closes - irrespective of the signature lifetimes of the certificate?

Paul

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

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

[Viktor Dukhovni]

> On Feb 21, 2018, at 11:00 AM, Shumon Huque  wrote:
> 
> On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson  
> wrote:
> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
>  wrote:
>> What's the behavior when the middlebox is a proxy, let's say existing
>> a managed network?  I presume from from section 3.1 that this
>> negotiation doesn't work in that instance unless sites configured for
>> this are not subject to the proxy as is often done for financial site
>> access from corporate networks.  It would be good to know if it does
>> work and that is addressed with the text Mirja calls out for her #1
>> question.  Having this clarified could be helpful.
> 
> If there is a MitM, then this extension simply isn't negotiated.
> That's pretty well understood.  I don't see why that requires special
> mention.
> 
> Yeah, I agree Martin .. this is the same as with any other extension.

Actually, I don't think it is quite the same.  This extension may
be naïvely expected to provide a different peer authentication
mechanism than the traditional WebPKI.  Users who might expect this
extension to protect them from WebPKI compromise via DANE TLSA
records, need to understand that such protection only exists when
DANE is enforced (mandatory) by the client.

The absence of DANE TLSA records, which is downgrade-resistant
when the client has access to DNSSEC authenticated denial of
existence (makes its own DNSSEC lookups) is no longer downgrade-
resistant when delivered via this extension if the client
is willing to accept just WebPKI in the (apparent) absence of DANE
TLSA records.

-- 
Viktor.



-- 
Viktor.

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

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

[Eric Rescorla]

On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque  wrote:

> Sorry for my belated follow-up. Was temporarily overwhelmed by the
> day job ..
>
>
> On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla  wrote:
> > On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque  wrote:
> >
> > > > 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.
> > >
> > > We could add an explicit reference here to the DNS protocol document(s)
> > > and sections within them that define the canonical form of domain
> > > names (RFC 4034, Section 6 probably is the best reference), or even
> > > excerpt the relevant text from that document. Would this satisfy your
> > > concern?
> > >
> >
> > Well, and remove your text about it being possible to implement solely
> from
> > this
> > document.
>
> Yes, I agree, we need to remove that.
>
>
> > It's not the algorithm. I don't believe this document is sufficient to
> > parse the
> > structure.
>
>
> Okay, got it. For people that have already implemented this, I think
> there has been an implicit understanding that the format of the chain
> data is a sequence of concatenated wire format RRs exactly as they appear
> in a DNS message section (with one injunction against doing DNS name
> compression). I'll write some text to make this more explicit and describe
> the format in more detail with references to the appropriate DNS specs.
>
> This is also the format that is readily generated and consumed by some
> DNS libraries and the Intro section of this document has the following
> assumption: "... (assuming that the data will be prepared and consumed
> by a DNS-specific library) ..."
>

Sure. I'm not arguing that this is a bad format. It's just a matter of
making
clear to the user what they have to do to parse it.



> > > * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation
> mechanisms
> > >   need to be consulted and honored.
> > >
> >
> > Well, neither of these modes is useful here, as an attacker will simply
> > ignore the
> > extension.
>
> Just to confirm, I assume the attacker here is an entity attempting
> to impersonate the TLS server (with presumably valid PKIX credentials).
> If so, yes it can trivially ignore the extension, but this is the case
> for any DANE usage mode (not just the PKIX constraining ones).
>

Agreed. It's just a less useful form of attack for the DANE modes where
you are authenticating with DANE only, as it's basically just a form of DOS.



> As discussed in Section 8, the protocol as currently specified really
> only allows opportunistic DANE authentication, unless some mechanism
> external to TLS is employed to mandate DANE usage. (The protocol could
> be extended to require TLS servers to also provide a DNSSEC proof that
> they don't have a signed TLSA record, but that could only be deployed
> in a TLS application system where all servers supported this extension).
>

I agree.



> > 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.
> > >
> > > Sure, we can elaborate.
> > >
> > > The DANE mode to be used is advertised by the server in its TLSA
> record(s),
> > > so the server already knows whether it needs to return the X.509 chain.
> > > If the TLSA RRset has only DANE-EE, then only the end-entity
> certificate
> > > needs to be returned. If DANE-TA, then only the chain from the TA cert
> to
> > > the
> > > EE needs to be returned. If using the PKIX modes, then yes, the entire
> > > X.509
> > > chain has to be sent.
> > >
> >
> > The problem is that the client is the decider about what it wants to
> > accept, not
> > the server.
>
> My comment was about what DANE mode choices the server is offering to
> the client. Certainly, the client can decide whether it wants to use
> DANE or not, and whether it wants to fallback to PKIX. The protocol
> should probably not be proscriptive here, and allow different TLS
> applications (or configurations of such applications) to make choices.
> But maybe there are some general recommendations to be made.
>

> One additional comment about PKIX fallback on DANE failure: If a
> server is using DANE-EE or DANE-TA, it has the ability to send back
> a much shorter Certificate message - just the EE certificate for the
> former, and typically a very short X.509 chain for the latter. But
> this means that for fallback to PKIX, the client would have to start
> a new handshake omitting the dnssec_chain extension. For efficient
> fallback within the same handshake, the server would always have to
> send back the full PKIX X.509 

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

[Shumon Huque]

On Wed, Feb 21, 2018 at 12:05 PM, Viktor Dukhovni 
wrote:

>
>
> > On Feb 21, 2018, at 10:57 AM, Shumon Huque  wrote:
> >
> > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni 
> wrote:
> >
> > Summary as I see it:
> >
> >   * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure
> > of PKIX-TA(0) and PKIX-EE(1).  Must fail when no TLSA RRs
> > are cache and the server does not present the extension.
>
> Just to clarify "failure of PKIX-TA(0) and PKIX-EE(1)" is intended to
> consider failure to satisfy the usual PKIX verification requirements
> for these certificate usages. Naturally, mandatory DANE can also be
> satisfied via matching DANE-TA(2) or DANE-EE(3) or fail via broken
>
> DANE-TA(2) or DANE-EE(3).
>

Yup, I understood, but thanks for clarifying ...


> >
> >   * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1)
> > if caching replies, and SHOULD attempt to refresh cache before
> > expiration to reduce opportunity for downgrades.  Non-caching
> > clients don't really gain security by refusing valid PKIX on
> > DANE failure, and MAY choose to continue.
> >
> > This seems reasonable to me too.
>
> Here too, a client MAY choose to fail when the presented certificate
> chain fails all the associated (cached or freshly obtained) DANE TLSA
> records whether these are PKIX-TA/EE, DANE-TA/EE or some mixture.
> The restricted focus on just PKIX-TA/PKIX-EE is not needed.
>

Yes, no need to restrict such a policy choice to only the PKIX-* modes.

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

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

[Viktor Dukhovni]

> On Feb 21, 2018, at 10:57 AM, Shumon Huque  wrote:
> 
> On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni  
> wrote:
> 
> Summary as I see it:
> 
>   * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure
> of PKIX-TA(0) and PKIX-EE(1).  Must fail when no TLSA RRs
> are cache and the server does not present the extension.

Just to clarify "failure of PKIX-TA(0) and PKIX-EE(1)" is intended to
consider failure to satisfy the usual PKIX verification requirements
for these certificate usages. Naturally, mandatory DANE can also be
satisfied via matching DANE-TA(2) or DANE-EE(3) or fail via broken
DANE-TA(2) or DANE-EE(3).

> 
>   * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1)
> if caching replies, and SHOULD attempt to refresh cache before
> expiration to reduce opportunity for downgrades.  Non-caching
> clients don't really gain security by refusing valid PKIX on
> DANE failure, and MAY choose to continue.
> 
> This seems reasonable to me too.

Here too, a client MAY choose to fail when the presented certificate
chain fails all the associated (cached or freshly obtained) DANE TLSA
records whether these are PKIX-TA/EE, DANE-TA/EE or some mixture.
The restricted focus on just PKIX-TA/PKIX-EE is not needed.

-- 
Viktor.

___
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 9:05 PM, Shumon Huque  wrote:

> 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.
>

A quick follow-up on this. I think we just keep this as a SHOULD. I looked
at what an existing DNS library implementation does, and it includes the
synthesized CNAME. It's easy enough for the client to just ignore it when
validating the chain.

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

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

[Kathleen Moriarty]

On Wed, Feb 21, 2018 at 11:00 AM, Shumon Huque  wrote:
> On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson 
> wrote:
>>
>> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
>>  wrote:
>> > What's the behavior when the middlebox is a proxy, let's say existing
>> > a managed network?  I presume from from section 3.1 that this
>> > negotiation doesn't work in that instance unless sites configured for
>> > this are not subject to the proxy as is often done for financial site
>> > access from corporate networks.  It would be good to know if it does
>> > work and that is addressed with the text Mirja calls out for her #1
>> > question.  Having this clarified could be helpful.
>>
>> If there is a MitM, then this extension simply isn't negotiated.
>> That's pretty well understood.  I don't see why that requires special
>> mention.
>
>
> Yeah, I agree Martin .. this is the same as with any other extension.

OK, I think it is clear in the discussion with 1.2, but wasn't sure if
it was clear enough elsewhere and figured it was best to ask.
>
> Shumon.
>



-- 

Best regards,
Kathleen

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

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

[Shumon Huque]

On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson 
wrote:

> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
>  wrote:
> > What's the behavior when the middlebox is a proxy, let's say existing
> > a managed network?  I presume from from section 3.1 that this
> > negotiation doesn't work in that instance unless sites configured for
> > this are not subject to the proxy as is often done for financial site
> > access from corporate networks.  It would be good to know if it does
> > work and that is addressed with the text Mirja calls out for her #1
> > question.  Having this clarified could be helpful.
>
> If there is a MitM, then this extension simply isn't negotiated.
> That's pretty well understood.  I don't see why that requires special
> mention.
>

Yeah, I agree Martin .. this is the same as with any other extension.

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

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

[Shumon Huque]

On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni 
wrote:
>
>
> Summary as I see it:
>
>   * Mandatory DANE:
>   MUST Refuse absence of TLSA RRs or failure
> of PKIX-TA(0) and PKIX-EE(1).  Must fail when no TLSA RRs
> are cache and the server does not present the extension.
>
>   * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1)
> if caching replies, and SHOULD attempt to refresh cache before
> expiration to reduce opportunity for downgrades.  Non-caching
> clients don't really gain security by refusing valid PKIX on
> DANE failure, and MAY choose to continue.
>

This seems reasonable to me too.

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

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

[Shumon Huque]

Sorry for my belated follow-up. Was temporarily overwhelmed by the
day job ..


On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla  wrote:
> On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque  wrote:
>
> > > 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.
> >
> > We could add an explicit reference here to the DNS protocol document(s)
> > and sections within them that define the canonical form of domain
> > names (RFC 4034, Section 6 probably is the best reference), or even
> > excerpt the relevant text from that document. Would this satisfy your
> > concern?
> >
>
> Well, and remove your text about it being possible to implement solely
from
> this
> document.

Yes, I agree, we need to remove that.


> It's not the algorithm. I don't believe this document is sufficient to
> parse the
> structure.


Okay, got it. For people that have already implemented this, I think
there has been an implicit understanding that the format of the chain
data is a sequence of concatenated wire format RRs exactly as they appear
in a DNS message section (with one injunction against doing DNS name
compression). I'll write some text to make this more explicit and describe
the format in more detail with references to the appropriate DNS specs.

This is also the format that is readily generated and consumed by some
DNS libraries and the Intro section of this document has the following
assumption: "... (assuming that the data will be prepared and consumed
by a DNS-specific library) ..."


> > 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.
> >
> > We can add some text about this. Basically the client would scan the
chain
> > reading RRs and group adjacent RRs that share the same RR name, type,
and
> > class into a distinct RRset.
> >
>
> I'd have to review your text to know if it was sufficient.

Ok. I'm working on text for this ..

> >
> > * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation
mechanisms
> >   need to be consulted and honored.
> >
>
> Well, neither of these modes is useful here, as an attacker will simply
> ignore the
> extension.

Just to confirm, I assume the attacker here is an entity attempting
to impersonate the TLS server (with presumably valid PKIX credentials).
If so, yes it can trivially ignore the extension, but this is the case
for any DANE usage mode (not just the PKIX constraining ones).

As discussed in Section 8, the protocol as currently specified really
only allows opportunistic DANE authentication, unless some mechanism
external to TLS is employed to mandate DANE usage. (The protocol could
be extended to require TLS servers to also provide a DNSSEC proof that
they don't have a signed TLSA record, but that could only be deployed
in a TLS application system where all servers supported this extension).


> On your last case, "cert validates but DANE does not", I assume
> > you mean the cert validates via PKIX but not DANE? I'm not sure this
> > is explicitly discussed in any other DANE document but presumably
> > if DANE is being used, DANE must validate.
> >
>
> Why would that be so? This only is useful in DANE-EE and DANE-TA modes in
> the first place, and so there is a possibilityt aht PKIX is valid.

I think Viktor's earlier reply to this thread goes into detail about
possible
client behaviors here and what we might recommend (which seems reasonable
to me). I'll follow-up there.


> > 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.
> >
> > Sure, we can elaborate.
> >
> > The DANE mode to be used is advertised by the server in its TLSA
record(s),
> > so the server already knows whether it needs to return the X.509 chain.
> > If the TLSA RRset has only DANE-EE, then only the end-entity certificate
> > needs to be returned. If DANE-TA, then only the chain from the TA cert
to
> > the
> > EE needs to be returned. If using the PKIX modes, then yes, the entire
> > X.509
> > chain has to be sent.
> >
>
> The problem is that the client is the decider about what it wants to
> accept, not
> the server.

My comment was about what DANE mode choices the server is offering to
the client. Certainly, the client can decide whether it wants to use
DANE or not, and whether it wants to fallback to PKIX. The protocol
should probably not be proscriptive here, and allow different TLS
applications (or configurations of such 

Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Eric Rescorla]

i think your general point is sound here, but I'll nitpick the statement
that
"if the server recognises an identity but is unable to verify corresponding
binder".

1. The server only picks one identity so you if you send A, B, and C and you
get an abort, you don't know if it recognized one or all.
2. The server can *recognize* the identity but ignore it (say it's a ticket
that's
too old)

With that said, I think it would probably be safe to say you must ignore an
identity
where the binder doesn't validate, but I'd like to hear from cryptographers
on this
one.

Thanks,
-Ekr


On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kario  wrote:

> On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote:
> > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario  wrote:
> > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> > > > The IESG has received a request from the Transport Layer Security WG
> > >
> > > (tls)
> > >
> > > > to consider the following document: - 'The Transport Layer Security
> > > > (TLS)
> > > > Protocol Version 1.3'
> > > >
> > > >as Proposed Standard
> > >
> > > The current draft states that if the server recognises an identity but
> is
> > > unable to verify corresponding binder, it "MUST abort the handshake"
> >
> > Which text are you referring to here?
>
> Section 4.2.11:
>
>Prior to accepting PSK key establishment, the server MUST validate
>the corresponding binder value (see Section 4.2.11.2 below).  If this
>value is not present or does not validate, the server MUST abort the
>handshake.  Servers SHOULD NOT attempt to validate multiple binders;
>rather they SHOULD select a single PSK and validate solely the binder
>that corresponds to that PSK.
>
> > -Ekr
> >
> > at the same time, they "SHOULD select as single PSK and validate solely
> the
> >
> > > binder that corresponds to that PSK"
> > > (Page 60, draft-ietf-tls-tls13-24).
> > >
> > > That allows for trivial enumeration of externally established
> identities -
> > > the
> > > attacker just needs to send to the server a list of identity guesses,
> with
> > > random data as binders, if the server recognises any identity it will
> > > abort
> > > connection, if it doesn't, it will continue to a non-PSK handshake.
> > >
> > > Behaviour like this is generally considered a vulnerability:
> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190
> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229
> > >
> > > I was wondering if the document shouldn't recommend ignoring any and
> all
> > > identities for which binders do not verify to prevent this kind of
> attack.
> > > --
> > > 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
> > > ___
> > > 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Hubert Kario]

On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote:
> On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario  wrote:
> > On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> > > The IESG has received a request from the Transport Layer Security WG
> > 
> > (tls)
> > 
> > > to consider the following document: - 'The Transport Layer Security
> > > (TLS)
> > > Protocol Version 1.3'
> > > 
> > >as Proposed Standard
> > 
> > The current draft states that if the server recognises an identity but is
> > unable to verify corresponding binder, it "MUST abort the handshake"
> 
> Which text are you referring to here?

Section 4.2.11:

   Prior to accepting PSK key establishment, the server MUST validate
   the corresponding binder value (see Section 4.2.11.2 below).  If this
   value is not present or does not validate, the server MUST abort the
   handshake.  Servers SHOULD NOT attempt to validate multiple binders;
   rather they SHOULD select a single PSK and validate solely the binder
   that corresponds to that PSK.
 
> -Ekr
> 
> at the same time, they "SHOULD select as single PSK and validate solely the
> 
> > binder that corresponds to that PSK"
> > (Page 60, draft-ietf-tls-tls13-24).
> > 
> > That allows for trivial enumeration of externally established identities -
> > the
> > attacker just needs to send to the server a list of identity guesses, with
> > random data as binders, if the server recognises any identity it will
> > abort
> > connection, if it doesn't, it will continue to a non-PSK handshake.
> > 
> > Behaviour like this is generally considered a vulnerability:
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229
> > 
> > I was wondering if the document shouldn't recommend ignoring any and all
> > identities for which binders do not verify to prevent this kind of attack.
> > --
> > 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
> > ___
> > 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

[TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Hubert Kario]

(fixing missed i...@ietf.org)

On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG (tls)
> to consider the following document: - 'The Transport Layer Security (TLS)
> Protocol Version 1.3'
>as Proposed Standard

The current draft states that if the server recognises an identity but is 
unable to verify corresponding binder, it "MUST abort the handshake"
at the same time, they "SHOULD select as single PSK and validate solely the 
binder that corresponds to that PSK"
(Page 60, draft-ietf-tls-tls13-24).

That allows for trivial enumeration of externally established identities - the 
attacker just needs to send to the server a list of identity guesses, with 
random data as binders, if the server recognises any identity it will abort 
connection, if it doesn't, it will continue to a non-PSK handshake.

Behaviour like this is generally considered a vulnerability:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229

I was wondering if the document shouldn't recommend ignoring any and all 
identities for which binders do not verify to prevent this kind of attack.

-- 
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] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Eric Rescorla]

On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario  wrote:

> On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> > The IESG has received a request from the Transport Layer Security WG
> (tls)
> > to consider the following document: - 'The Transport Layer Security (TLS)
> > Protocol Version 1.3'
> >as Proposed Standard
>
> The current draft states that if the server recognises an identity but is
> unable to verify corresponding binder, it "MUST abort the handshake"
>

Which text are you referring to here?

-Ekr

at the same time, they "SHOULD select as single PSK and validate solely the
> binder that corresponds to that PSK"
> (Page 60, draft-ietf-tls-tls13-24).
>
> That allows for trivial enumeration of externally established identities -
> the
> attacker just needs to send to the server a list of identity guesses, with
> random data as binders, if the server recognises any identity it will abort
> connection, if it doesn't, it will continue to a non-PSK handshake.
>
> Behaviour like this is generally considered a vulnerability:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229
>
> I was wondering if the document shouldn't recommend ignoring any and all
> identities for which binders do not verify to prevent this kind of attack.
> --
> 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
> ___
> 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] Future interoperability issues for HRR for new extensions; Was: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standar

[Eric Rescorla]

On Wed, Feb 21, 2018 at 6:10 AM, Benjamin Kaduk  wrote:

> On 02/21/2018 05:46 AM, Hubert Kario wrote:
> > On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> >> The IESG has received a request from the Transport Layer Security WG
> (tls)
> >> to consider the following document: - 'The Transport Layer Security
> (TLS)
> >> Protocol Version 1.3'
> >>as Proposed Standard
> > Section 4.1.2 currently states that the only changes allowed to the
> second
> > ClientHello message (in HelloRetryRequest case) are:
> >  - replacing key_share
> >  - removing early_data
> >  - adding cookie
> >  - updating pre_shared_key
> >  - adding, removing or changing padding
> >
> > What about extensions undefined now? What if in the future we have
> another
> > extension like the PSK extension that needs to be updated for the second
> > ClientHello?
> >
> > Do we accept that the above list is set in stone and will never change
> (except
> > for new protocol versions), requiring all future extensions to also
> require
> > the same extension payload for first and second ClientHello?
> >
>
> It seems to me that such a hypothetical future extension could include a
> signaling value in the HRR to indicate that the server understands the
> new extension, and the semantics of the extension defined such that when
> the server understands the extension the client may change its value
> between ClientHello1 and ClientHello2.
>
> This might be slightly inefficient if the extension's information flow
> is only from client to server, but I think it would be a compatible way
> to allow an extension value to change after HRR.
>

Yes. Also, there's not really any good reason to change an extension that
is not
mentioned in HRR.

-Ekr


> -Ben
>
> ___
> 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] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Hubert Kario]

On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG (tls)
> to consider the following document: - 'The Transport Layer Security (TLS)
> Protocol Version 1.3'
>as Proposed Standard

The current draft states that if the server recognises an identity but is 
unable to verify corresponding binder, it "MUST abort the handshake"
at the same time, they "SHOULD select as single PSK and validate solely the 
binder that corresponds to that PSK"
(Page 60, draft-ietf-tls-tls13-24).

That allows for trivial enumeration of externally established identities - the 
attacker just needs to send to the server a list of identity guesses, with 
random data as binders, if the server recognises any identity it will abort 
connection, if it doesn't, it will continue to a non-PSK handshake.

Behaviour like this is generally considered a vulnerability:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229

I was wondering if the document shouldn't recommend ignoring any and all 
identities for which binders do not verify to prevent this kind of attack.
-- 
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] Future interoperability issues for HRR for new extensions; Was: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standar

[Benjamin Kaduk]

On 02/21/2018 05:46 AM, Hubert Kario wrote:
> On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
>> The IESG has received a request from the Transport Layer Security WG (tls)
>> to consider the following document: - 'The Transport Layer Security (TLS)
>> Protocol Version 1.3'
>>as Proposed Standard
> Section 4.1.2 currently states that the only changes allowed to the second 
> ClientHello message (in HelloRetryRequest case) are:
>  - replacing key_share
>  - removing early_data
>  - adding cookie
>  - updating pre_shared_key
>  - adding, removing or changing padding
>
> What about extensions undefined now? What if in the future we have another 
> extension like the PSK extension that needs to be updated for the second 
> ClientHello?
>
> Do we accept that the above list is set in stone and will never change 
> (except 
> for new protocol versions), requiring all future extensions to also require 
> the same extension payload for first and second ClientHello?
>

It seems to me that such a hypothetical future extension could include a
signaling value in the HRR to indicate that the server understands the
new extension, and the semantics of the extension defined such that when
the server understands the extension the client may change its value
between ClientHello1 and ClientHello2.

This might be slightly inefficient if the extension's information flow
is only from client to server, but I think it would be a compatible way
to allow an extension value to change after HRR.

-Ben

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

[TLS] Opsdir telechat review of draft-ietf-tls-record-limit-02

[Éric Vyncke]

Reviewer: Éric Vyncke
Review result: Has Nits

Reviewer: Eric Vyncke
Review results: has nits

Hello Martin,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts.

The document is about an extension to TLS (record_size_limit) allowing
endpoints to negotiate the maximum size of protected records. The document also
deprecates a previous extension max_fragment_length.

The different scenarios (whether endpoints support this option or not) as well
as behavior of future versions of TLS are specified. Section 5 also describes
the behavior when endpoints use the proposed and the deprecated TLS options.

Nits in section 5: "MUST ignore *and* "max_fragment_length""

This is a short document and IMHO all operational issues are well documented
and correct.

-éric


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

[TLS] Future interoperability issues for HRR for new extensions; Was: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Hubert Kario]

On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG (tls)
> to consider the following document: - 'The Transport Layer Security (TLS)
> Protocol Version 1.3'
>as Proposed Standard

Section 4.1.2 currently states that the only changes allowed to the second 
ClientHello message (in HelloRetryRequest case) are:
 - replacing key_share
 - removing early_data
 - adding cookie
 - updating pre_shared_key
 - adding, removing or changing padding

What about extensions undefined now? What if in the future we have another 
extension like the PSK extension that needs to be updated for the second 
ClientHello?

Do we accept that the above list is set in stone and will never change (except 
for new protocol versions), requiring all future extensions to also require 
the same extension payload for first and second ClientHello?

-- 
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