Re: [TLS] Comment on draft-sullivan-tls-opaque-00

[steve]

On 04/08/2021, 14:43, "Scott Fluhrer (sfluhrer)"  wrote:
> 
> I am glad that someone in the working group is looking at this.  However, as 
> I reviewed this before the wg meeting, I was completely puzzled by this text 
> (from section 6.1):
> 
> 3DH
> 
>C computes K = H(g^y ^ PrivU || PubU ^ x || PubS ^ PrivU || IdU || IdS )
>S computes K = H(g^x ^ PrivS || PubS ^ y || PubU ^ PrivS || IdU || IdS )
> 

There are three errors in this the two you pointed out and the third term. The 
correct K calculations for 3DH are:

C computes K = H(g^y ^ PrivU || PubS ^ x|| g^y ^ x || IdU || IdS)
S computes K = H(PubU ^ y|| g^x ^ PrivS || g^x ^ y || IdU || IdS)

Where C has x, g^y, PubS, PrivU and S has y, g^x, PubU, PrivS. Which are 
calculated like:
g^x = g ^ x(yes I know it's bad to name it like
g^y = g ^ y this, but that's how they did it)
PubS = g ^ PrivS
PubU = g ^ PrivU

Although the terms can be in any order and I don't speak for them, but those 
are the correct terms with matching counterparts.

> Obviously these needs to be the same for an honest client-server pair.  I 
> can't see where the above variables are defined in the doc; I would assume 
> that the meanings are:
> 
> 
>   *   x, y are the private values from the ephemeral DH operation, and are 
> randomly selected for each exchange.
>   *   PrivU, PubU, PrivS, PubS are static values from the Opaque record.
> 

That's how I read it.

> However, if that's the case, I can't see how that could work; for one, g^y ^ 
> PrivU and g^x ^ PrivS would be different values, and so differing values 
> would be stirred into the Master Secret.  In addition, I can't see how PubU ^ 
> x (where PubU and x would appear to be client specific) could be expected to 
> be the same as PubS ^ y (as both those values would be server specific).
> 
> What am I missing?
> 

Those are actual problems. As a side note 3DH looks like this where each 
straight line is a DH calculation (hopefully those two lines look like they 
make an "X"). i_* being their identity public-private key pairs (PrivU, PubU, 
PrivS, PubS) and e_* being their ephemeral public-private key pairs (x, g^x, y, 
g^y).

i_c   i_s
   \ /
 \ /
 / \
   / \
e_c - e_s

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

[TLS] Recommending ALPN (was Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11 ...)

[Martin Thomson]

(dprive to bcc, because this is getting further afield)

On Fri, Apr 30, 2021, at 00:26, Salz, Rich wrote:
> >No new protocol should use TLS without ALPN.  It only opens space for 
> > cross-protocol attacks.  Did the working group consider this possibility in 
> > their discussions?
> 
> I don't believe that message has been made as public as it should be.

I see that UTA is working on a revision of RFC 7525.  Is text on this something 
that would be in scope.  I only just searched for "ALPN", finding nothing, so 
maybe it is not in the original scope and maybe there are things that might 
prevent expansion of scope.

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

Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Eric Rescorla]

On Thu, Apr 29, 2021 at 11:38 AM Stephen Farrell 
wrote:

>
>
> On 29/04/2021 19:28, Salz, Rich wrote:
> > To make it obvious (I thought it was): I agree, and think we need to
> > make that fact more widely known.
>
> I think I agree but seems like ECH may add a subtlety - maybe
> what we need to promote is the idea that new protocols should
> define new ALPN strings, but also that intermediaries can't
> depend on those to route connections as the inner and outer
> ALPN values can be independent in the case of ECH (use of
> which might not that visible to the application if a library
> were to default to use of ECH where possible).
>

Correct. The purpose of ALPN in this context is to avoid cross-protocol
attacks on the endpoints. Reliance on them by intermediaries is difficult
absent some fairly strong assumptions about the endpoints.

-Ekr


> Cheers,
> S.
>
> >
> > From: Eric Rescorla  Date: Thursday, April 29, 2021 at
> > 2:24 PM To: Rich Salz  Cc: Martin Thomson
> > , "dns-priv...@ietf.org" ,
> > "tls@ietf.org"  Subject: Re: [dns-privacy] [TLS] Martin
> > Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with
> > COMMENT)
> >
> > Probably not, but I agree with MT.
> >
> > The general idea here is that any given protocol trace should only be
> > interpretable in one way. So, either you need the interior protocol
> > to be self-describing or you need to separate the domains with ALPN.
> > I don't believe that either the IP ACL or mTLS addresses this issue,
> > and in fact arguably mTLS makes the problem worse because it provides
> > authenticated protocol traces which might be usable for
> > cross-protocol attacks.
> >
> > -Ekr
> >
> >
> > On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich
> > mailto:40akamai@dmarc.ietf.org>>
> > wrote:
> >> No new protocol should use TLS without ALPN.  It only opens space
> >> for cross-protocol attacks.  Did the working group consider this
> >> possibility in their discussions?
> >
> > I don't believe that message has been made as public as it should
> > be.
> >
> > ___ dns-privacy mailing
> > list dns-priv...@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy<
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dns-privacy__;!!GjvTz_vk!EtJaCTiH36U_bsA5vP82lZpBELKgq8908Dnb9MmdFc9M0FfjBeJMg3QwgwSs$
> >
> >
> >
> >
> > ___ 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] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Eric Rescorla]

On Thu, Apr 29, 2021 at 11:49 AM Allison Mankin 
wrote:

> Hi Ekr,
>
> As Sara wrote, the spec had ALPN. The WG consensus during the IETF 108
> meeting was very strong to take it out, including quite strong statements
> from you along the lines that distinguishing between XoT and DOT was an
> incorrect usage of ALPN.
>

I don't have the message you are referring to at hand, so I'm not able to
respond to that. However, I don't believe that an ALPN is needed to
distinguish XoT from DoT because there is no confusion between the protocol
traces of XoT and DoT. However there should be an ALPN to distinguish XoT
and DoT from HTTP, SMTP, etc.IOW, this protocol should use ALPN="dot".


I understand that the perspective changed since IETF108 (that WG discussion
> was at the end of July 2020) and that communications were not wide enough
> for us to know about it in March when the WG moved the draft to WGLC,
> Directorates Review, and IETF LC
>

I don't think anyone is saying that the WG somehow did something wrong
procedurally, merely that this is a defect that ought to be corrected prior
to publication.

-Ekr


On Thu, Apr 29, 2021 at 14:25 Eric Rescorla  wrote:
>
>> Probably not, but I agree with MT.
>>
>> The general idea here is that any given protocol trace should only be
>> interpretable in one way. So, either you need the interior protocol to be
>> self-describing or you need to separate the domains with ALPN. I don't
>> believe that either the IP ACL or mTLS addresses this issue, and in fact
>> arguably mTLS makes the problem worse because it provides authenticated
>> protocol traces which might be usable for cross-protocol attacks.
>>
>> -Ekr
>>
>>
>> On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich > 40akamai@dmarc.ietf.org> wrote:
>>
>>> >No new protocol should use TLS without ALPN.  It only opens space
>>> for cross-protocol attacks.  Did the working group consider this
>>> possibility in their discussions?
>>>
>>> I don't believe that message has been made as public as it should be.
>>>
>>> ___
>>> dns-privacy mailing list
>>> dns-priv...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>> ___
>> 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] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Allison Mankin]

Hi Ekr,

As Sara wrote, the spec had ALPN. The WG consensus during the IETF 108
meeting was very strong to take it out, including quite strong statements
from you along the lines that distinguishing between XoT and DOT was an
incorrect usage of ALPN.

I understand that the perspective changed since IETF108 (that WG discussion
was at the end of July 2020) and that communications were not wide enough
for us to know about it in March when the WG moved the draft to WGLC,
Directorates Review, and IETF LC

On Thu, Apr 29, 2021 at 14:25 Eric Rescorla  wrote:

> Probably not, but I agree with MT.
>
> The general idea here is that any given protocol trace should only be
> interpretable in one way. So, either you need the interior protocol to be
> self-describing or you need to separate the domains with ALPN. I don't
> believe that either the IP ACL or mTLS addresses this issue, and in fact
> arguably mTLS makes the problem worse because it provides authenticated
> protocol traces which might be usable for cross-protocol attacks.
>
> -Ekr
>
>
> On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
>> >No new protocol should use TLS without ALPN.  It only opens space
>> for cross-protocol attacks.  Did the working group consider this
>> possibility in their discussions?
>>
>> I don't believe that message has been made as public as it should be.
>>
>> ___
>> dns-privacy mailing list
>> dns-priv...@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
> ___
> 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] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Stephen Farrell]

On 29/04/2021 19:28, Salz, Rich wrote:

To make it obvious (I thought it was): I agree, and think we need to
make that fact more widely known.


I think I agree but seems like ECH may add a subtlety - maybe
what we need to promote is the idea that new protocols should
define new ALPN strings, but also that intermediaries can't
depend on those to route connections as the inner and outer
ALPN values can be independent in the case of ECH (use of
which might not that visible to the application if a library
were to default to use of ECH where possible).

Cheers,
S.



From: Eric Rescorla  Date: Thursday, April 29, 2021 at
2:24 PM To: Rich Salz  Cc: Martin Thomson
, "dns-priv...@ietf.org" ,
"tls@ietf.org"  Subject: Re: [dns-privacy] [TLS] Martin
Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with
COMMENT)

Probably not, but I agree with MT.

The general idea here is that any given protocol trace should only be
interpretable in one way. So, either you need the interior protocol
to be self-describing or you need to separate the domains with ALPN.
I don't believe that either the IP ACL or mTLS addresses this issue,
and in fact arguably mTLS makes the problem worse because it provides
authenticated protocol traces which might be usable for
cross-protocol attacks.

-Ekr


On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich
mailto:40akamai@dmarc.ietf.org>>
wrote:

No new protocol should use TLS without ALPN.  It only opens space
for cross-protocol attacks.  Did the working group consider this
possibility in their discussions?


I don't believe that message has been made as public as it should
be.

___ dns-privacy mailing
list dns-priv...@ietf.org 
https://www.ietf.org/mailman/listinfo/dns-privacy




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




OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Salz, Rich]

To make it obvious (I thought it was): I agree, and think we need to make that 
fact more widely known.

From: Eric Rescorla 
Date: Thursday, April 29, 2021 at 2:24 PM
To: Rich Salz 
Cc: Martin Thomson , "dns-priv...@ietf.org" 
, "tls@ietf.org" 
Subject: Re: [dns-privacy] [TLS] Martin Duke's No Objection on 
draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

Probably not, but I agree with MT.

The general idea here is that any given protocol trace should only be 
interpretable in one way. So, either you need the interior protocol to be 
self-describing or you need to separate the domains with ALPN. I don't believe 
that either the IP ACL or mTLS addresses this issue, and in fact arguably mTLS 
makes the problem worse because it provides authenticated protocol traces which 
might be usable for cross-protocol attacks.

-Ekr


On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:
>No new protocol should use TLS without ALPN.  It only opens space for 
> cross-protocol attacks.  Did the working group consider this possibility in 
> their discussions?

I don't believe that message has been made as public as it should be.

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

Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Eric Rescorla]

Probably not, but I agree with MT.

The general idea here is that any given protocol trace should only be
interpretable in one way. So, either you need the interior protocol to be
self-describing or you need to separate the domains with ALPN. I don't
believe that either the IP ACL or mTLS addresses this issue, and in fact
arguably mTLS makes the problem worse because it provides authenticated
protocol traces which might be usable for cross-protocol attacks.

-Ekr


On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich  wrote:

> >No new protocol should use TLS without ALPN.  It only opens space for
> cross-protocol attacks.  Did the working group consider this possibility in
> their discussions?
>
> I don't believe that message has been made as public as it should be.
>
> ___
> dns-privacy mailing list
> dns-priv...@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Salz, Rich]

>No new protocol should use TLS without ALPN.  It only opens space for 
> cross-protocol attacks.  Did the working group consider this possibility in 
> their discussions?

I don't believe that message has been made as public as it should be.

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

Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Eric Vyncke (evyncke)]

Martin,

The IETF Last Call on this document has completed on the 20th of April 2021 but 
it is never too late of course.

I just added our security Area Directors in the loop so that know your question 
for their ballot due for next week.

Regards

-éric



-Original Message-
From: dns-privacy  on behalf of Sara Dickinson 

Date: Thursday, 29 April 2021 at 14:52
To: Martin Thomson 
Cc: DNS Privacy Working Group , "tls@ietf.org" 

Subject: Re: [dns-privacy] Martin Duke's No Objection on 
draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)



> On 29 Apr 2021, at 01:09, Martin Thomson  wrote:
> 
> On Wed, Apr 28, 2021, at 20:27, Sara Dickinson wrote:
>> An early version of this specification proposed a XoT specific ALPN in 
>> order to distinguish this from a connection intended to perform 
>> recursive to authoritative DoT (often called ADoT). ADoT is not yet 
>> specified, but is the subject of ongoing discussions in DPRIVE. The 
>> working group rejected this idea for XoT and switched to the current 
>> spec which does not use an ALPN at all. 
> 
> No new protocol should use TLS without ALPN.  It only opens space for 
cross-protocol attacks.  Did the working group consider this possibility in 
their discussions?

What the working group asked for following the ALPN discussion was that the 
document contain a description of the options an authoritative nameserver that 
supports XoT can use to manage TLS connections and the queries received on 
those connections  - that is provided in Appendix A: 
https://tools.ietf.org/html/draft-ietf-dprive-xfr-over-tls-11#appendix-A

As more context, the document also covers various existing mechanisms that 
can be used to manage zone transfers (including IP ACLs and TSIG) and how they 
combine with Strict and Mutual TLS authentication. The document specifies that 
the server MUST use either an IP ACL or mTLS to authenticate the XoT client. 

Regards

Sara. 

___
dns-privacy mailing list
dns-priv...@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Sara Dickinson]

> On 29 Apr 2021, at 01:09, Martin Thomson  wrote:
> 
> On Wed, Apr 28, 2021, at 20:27, Sara Dickinson wrote:
>> An early version of this specification proposed a XoT specific ALPN in 
>> order to distinguish this from a connection intended to perform 
>> recursive to authoritative DoT (often called ADoT). ADoT is not yet 
>> specified, but is the subject of ongoing discussions in DPRIVE. The 
>> working group rejected this idea for XoT and switched to the current 
>> spec which does not use an ALPN at all. 
> 
> No new protocol should use TLS without ALPN.  It only opens space for 
> cross-protocol attacks.  Did the working group consider this possibility in 
> their discussions?

What the working group asked for following the ALPN discussion was that the 
document contain a description of the options an authoritative nameserver that 
supports XoT can use to manage TLS connections and the queries received on 
those connections  - that is provided in Appendix A: 
https://tools.ietf.org/html/draft-ietf-dprive-xfr-over-tls-11#appendix-A

As more context, the document also covers various existing mechanisms that can 
be used to manage zone transfers (including IP ACLs and TSIG) and how they 
combine with Strict and Mutual TLS authentication. The document specifies that 
the server MUST use either an IP ACL or mTLS to authenticate the XoT client. 

Regards

Sara. 

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