Re: [TLS] Is there a way forward after today's hum?

[Ackermann, Michael]

Ted
You may be aware that most enterprises have been migrating away from 3270 for 
20 years or more.  Very little still exists.  What little does exist is 
usually implemented via tn3270.   In the browser scenario you describe I would 
expect the Server side to be a tn3270 server,  but you will have to fill in the 
details of the use case you are describing,  to be sure.

I hope the above helps,  but my real question is why would this be special or 
even relevant to the TLS1.3 discussion.

Attempting to address specific applications or implementations would seem only 
add confusion IMHO.

Thanks

Mike



From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: Thursday, July 20, 2017 10:48 AM
To: Tom Ritter 
Cc: IETF TLS 
Subject: Re: [TLS] Is there a way forward after today's hum?

The problem is that one of the applications for web browsers is as a 
replacement for 3270s (the first web browser).   That use case is said to 
require this functionality.

On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter 
mailto:t...@ritter.vg>> wrote:
On 20 July 2017 at 01:53, Yoav Nir 
mailto:ynir.i...@gmail.com>> wrote:
>
> On 20 Jul 2017, at 8:01, Russ Housley 
> mailto:hous...@vigilsec.com>> wrote:
>
> Ted, if we use a new extension, then the server cannot include it unless the
> client offered it first.  I am thinking of an approach where the server
> would include information needed by the decryptor in the response.  So, if
> the client did not offer the extension, it would be a TLS protocol violation
> for the server to include it.
>
>
> So we also add an alert called “key-export-needed” in case the client does
> not include it.
>
> That way a browser (as an example) can show the user why the connection was
> broken (“server requires wiretapping to be enabled. Go to about:config if
> that is OK and change the allow-wiretap setting to True”)

I previously expressed that I could support the extension mechanism -
I'm sympathetic to regulatory requirements and unhappy with, although
understanding of, what has become the 'standard mechanism' (breaking
crypto) to achieve them. I've looked at more than one 'end to end'
encrypted messenger that tosses in the 'third end' of key escrow.

But to suggest such a mechanism might ever be implemented in a web
browser throws my hackles up. The discussion has always been about
datacenter - the people concerned say "We don't want your datacenter
stuff in our protocol and the proponents say "No really, we only care
about the datacenter."

The concerns around some future government-mandated key escrow is very
real and very concerning.

-tom

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



The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SNI with early data

[Matt Caswell]

On 20/07/17 18:10, Benjamin Kaduk wrote:
> On 07/20/2017 04:51 AM, Matt Caswell wrote:
>> I note in draft-21 the following text:
>>
>>When clients use a PSK obtained externally to send early data, then
>>the following additional information MUST be provisioned to both
>>parties:
>>
>>-  The TLS version number for use with this PSK
>>
>>-  The cipher suite for use with this PSK
>>
>>-  The Application-Layer Protocol Negotiation (ALPN) protocol
>>   [RFC7301], if any is to be used
>>
>>-  The Server Name Indication (SNI), if any is to be used
>
> These are in addition to the hash algorithm provisioned with the
> external psk that is needed for 1-RTT operation, as mentioned somewhat
> in passing in section 4.2.10
>
>> Later it says this:
>>
>>In order to accept early data, the server MUST have accepted a PSK
>>cipher suite and selected the first key offered in the client's
>>"pre_shared_key" extension.  In addition, it MUST verify that the
>>following values are consistent with those negotiated in the
>>connection during which the ticket was established.
>>
>>-  The TLS version number and cipher suite.
>>
>>-  The selected ALPN [RFC7301] protocol, if any.
>>
>>
>> The language about "during which the ticket was established" seems to
>> suggest that the following checks do not apply to an external PSK -
>> which I don't think is intended. Additionally there does not seem to
>
> These values are a subset of those listed above.  I believe this block
> of text only applies to NST-provisioned PSKs being used for early data,
> as the previous text applies to external PSKs being used for early
> data.

Interesting because I assumed the intention was the opposite. I'm not
sure why this restriction should only apply to NST-provisioned PSKs.


>  So, since the previous list is a superset, there is no problem
> caused by this text not applying to external PSKs.

The earlier text is about what needs to be *provisioned* to both
parties. This text is about what MUST be verified on the server. I
think these are two subtly different things. I see no reason to
exclude SNI from requiring to be verified, nor do I see a reason to
restrict it to NST PSKs only. Either you MUST do it for both types of
PSK or you don't need to do it at all. What is the benefit of
complicating things by providing a partial list that MUST be verified
for one type of PSK only?

If this block of text is about NST PSKs only then the implication is
that a server MAY tolerate discrepancies in ALPN for external PSK. At
least that is the way I read it (although I don't think that was the
intention).

>
>> be a requirement on the server to check that the SNI is consistent.
>> So, there is a mandatory requirement for an external PSK to specify
>> the SNI, but no requirement on the server to check that it is actually
>> correct. Is this discrepancy intentional?
>>
>
> I'm not sure I fully understand what you are saying.
> The text says that (for external PSKs) the SNI must be provisioned to
> both parties, which to me implies that the server must only use the
> given PSK for early data with the specified SNI.  (That is, that the
> server has to check.)

It does not imply that to me. It says it has to be provisioned. That
fact that NST PSK MUST verify, implies to me that non-NST PSKs may
tolerate discrepancies.

>
> For tickets, the requirement that SNI must match the original connection
> is mentioned in section 4.6.1 (NewSessionTicket).

Again...why only for NST PSKs?

>
> In short ... I don't see any problems here.  Do you still see a problem?

Yes - given that we have different interpretations of the same text I
still see a problem. I think it should be a lot more explicit, and
remove the discrepancies between NST PSKs and external PSKs.

There is another example of this, earlier on in section 4.2.9:

"The parameters for the 0-RTT data (symmetric cipher suite, ALPN
protocol, etc.) are the same as those which were negotiated in the
connection which established the PSK."

This implicitly seems to only apply to NST PSKs. Why not external PSKs too?

Matt

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

Re: [TLS] Is there a way forward after today's hum?

[Ted Lemon]

As I said in the previous message, the 3270 was the original web browser.
What I mean by that is that the 3270 transaction model is basically a
primitive version of http: you throw up a page, the user enters some data,
then the user hits send and all the data goes to the server at once.   The
reason the 3270 is no longer widely used is because it's been replaced by
web browsers.

Mentioning that in passing probably made my message less clear; the point
is that the 3270<->mainframe model of operation comes with very different
assumptions than the web browser<->service provider model, and one of the
problems you have is that what you are doing is really the former and not
the latter.


On Fri, Jul 21, 2017 at 12:00 PM, Ackermann, Michael 
wrote:

> Ted
>
> You may be aware that most enterprises have been migrating away from 3270
> for 20 years or more.  Very little still exists.  What little does
> exist is usually implemented via tn3270.   In the browser scenario you
> describe I would expect the Server side to be a tn3270 server,  but you
> will have to fill in the details of the use case you are describing,  to be
> sure.
>
>
>
> I hope the above helps,  but my real question is why would this be special
> or even relevant to the TLS1.3 discussion.
>
>
>
> Attempting to address specific applications or implementations would seem
> only add confusion IMHO.
>
>
>
> Thanks
>
>
>
> Mike
>
>
>
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Thursday, July 20, 2017 10:48 AM
> *To:* Tom Ritter 
> *Cc:* IETF TLS 
> *Subject:* Re: [TLS] Is there a way forward after today's hum?
>
>
>
> The problem is that one of the applications for web browsers is as a
> replacement for 3270s (the first web browser).   That use case is said to
> require this functionality.
>
>
>
> On Thu, Jul 20, 2017 at 4:43 PM, Tom Ritter  wrote:
>
> On 20 July 2017 at 01:53, Yoav Nir  wrote:
> >
> > On 20 Jul 2017, at 8:01, Russ Housley  wrote:
> >
> > Ted, if we use a new extension, then the server cannot include it unless
> the
> > client offered it first.  I am thinking of an approach where the server
> > would include information needed by the decryptor in the response.  So,
> if
> > the client did not offer the extension, it would be a TLS protocol
> violation
> > for the server to include it.
> >
> >
> > So we also add an alert called “key-export-needed” in case the client
> does
> > not include it.
> >
> > That way a browser (as an example) can show the user why the connection
> was
> > broken (“server requires wiretapping to be enabled. Go to about:config if
> > that is OK and change the allow-wiretap setting to True”)
>
> I previously expressed that I could support the extension mechanism -
> I'm sympathetic to regulatory requirements and unhappy with, although
> understanding of, what has become the 'standard mechanism' (breaking
> crypto) to achieve them. I've looked at more than one 'end to end'
> encrypted messenger that tosses in the 'third end' of key escrow.
>
> But to suggest such a mechanism might ever be implemented in a web
> browser throws my hackles up. The discussion has always been about
> datacenter - the people concerned say "We don't want your datacenter
> stuff in our protocol and the proponents say "No really, we only care
> about the datacenter."
>
> The concerns around some future government-mandated key escrow is very
> real and very concerning.
>
> -tom
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] notes for TLS WG Session 2 at IETF 99

[Kathleen Moriarty]

Hi,

The email seems to be missing some text that was in the etherpad (or
reordered maybe), so here it is again:

IETF99 TLS WG 2nd session (19-July-2017)

(all errors are JLH's)

Agenda/Administrivia

Exported Authenticators (EKR)

draft 21, hopefully close

WGLC #2 ended yesterday

Changes since -19

shorten HKDF labels

make post-handshake auth imp option

add per-ticket nonce, each ticket is assoc. w/ new PSK

new section 0-RTT anti-replay

Mandatory anti-replay (PR# 1059)

requires some bounded mechanism, but no specific technique

Should we adopt this? Any objections?

MT: every instance has to ensure that it only accepts the same 0-RTT
once... which means an unbounded state problem

EKR: imp in NSS would guarantee "as 0-RTT"

... "you must accept 0-RTT data once"

MT: We've got a window, only accept in that window, no guarantee either.

(No objections)

PR# 1053: Hashes that aren't hashes

HKDF-Expand-Label included a hash function that occasionally is not a hash.

essentially, SHA156(empty string) passed frequently to something else.

Probably worth saying "you can pass a null value, and not pass a hash"

EKR: any opinions?

MT: noticed while doing vectors draft, we do this once every
handshake. I don't care.

EKR: there are two places that it can happen.

MT: still, I could care less.

Hannes: doesn't make sense to change since people have implemented like this.

RLB: I agree with MT and Hannes. Like the current mechanism, can opt
with table of hash values.

Placeholder: NAT/Middleboxes

TLS 1.3 starting to show increased connection failure rates.

hard to meausre but 1-10%

Problem seems to be middleboxen

proposals are either make connection look more or less like TLS 1.2

Joe S: when will experiments complete?

EKR: depends on what we see. Will have data relatively soon, 4-8
weeks. Takes a while to get into a release... but nightlies and betas
give some indication of if it will work.

draft-ietf-tls-dnssec-chain-exstension (Melinda Shore)

completed WGLC on this draft.
(https://www.ietf.org/proceedings/99/slides/slides-99-tls-sessb-dnssec-chain-validation-00.pdf)

excellent feedback so far.

(melinda summarizes changes)

record ordering (server canonicalization, yes or no?) No one came to mic.

use of _udp label for QUIC

Ted Hardie: reading of the draft is that UDP label used for DTLS and QUIC.

...: you might have two different TLSA records, one for DTLS and one
for QUIC. Maybe call it _quic?

Paul Woters: want to make sure we don't create a new plaintext reference

tell client imps how to handle unexpected/irrelevant/extraneous records?

Joe: we'll close on these remaining issues before reving the draft.

DTLS 1.3 (EKR)

first mentions something about exported authenticators:

certificate type extension goes in server [something] message.

odd thing is can have EE X.509 extension [somewhere] which is nuts.

Suggest we maintain the property where I change the entry in the table
and [something]

Trying to keep 1.2 functionality.

Reminder: ACKs

implicit ACKs historically.

interacts badly with some TLS 1.3 features (like NST)

Solution: intro an explicit ACK

current proposal: SACK

kind of ripping off the QUIC structure.

MT: other thing with it being a handshake message is that it adds to
the transcript record and that gets weird.

When should receivers ACK

supposed to ACK when you're not moving the state machine forward, when
messages might have gotten lost, not for non-handshake messages

If anyone thinks this is a bad strategy, please speak up.

Joe S: how many people have had a chance to look at this? Not too many.

Janardhan Igengar: would be nice if this is not too complicated.

Reduced Header Format

MT: we currently have range between 20-64 reserved for us in this
demux thing. We only use the lower half of the 20s... this uses the
upper half of that range from 32 onwards. Can use that entire space
and allows good distinguishing. Don't see us using too much more
content types.

EKR: essentially the point of doing something different would be to
have much longer sequence bits.

MT: not sure I've convinced Ian Swette [sp?]

SPT: thing about this is that the IoT will think we ned to make this
smaller... this seems about as small as you can get to.

MT: one optimization we could make in addition, would be to remove the length.

EKR: but that would make the ACK'ing problematic (?)

MT: other way to do that is to do some internal framing... "I've got
an ACK and some other stuff in here"

... real challenge here are the cases when you're changing keys. would
need internal lengths for those content types.

Connection IDs

have spent an enormous amount of time on this.

things behind NATs have problems rebinding.

also a serious privacy problem, none of the proposals I've seen are
adequate let alone completely baked.

huge problem in the browser context, not so much in the mobile context.

proposal for DTLS is to kind of punt: have an optional but fixed
Connection ID. Doesn't change across t

[TLS] Consistency for Signature Algorithms?

[Hubert Kario]

Signature Algorithms for ECDSA now define both the curve and the hash 
algorithm:

  ecdsa_secp256r1_sha256(0x0403),
  ecdsa_secp384r1_sha384(0x0503),
  ecdsa_secp521r1_sha512(0x0603),

This is in contrast to the TLS 1.2 protocol, where any hash can be used with 
any curve.

There are good reasons for that change:
 - less combinations to test
 - establishes the low water mart for security

I see few problems with that though:
 1). there are not insignificant number of clients that advertise support for 
  all (at least P-256 and P-384) curves, but don't advertise support for 
  hashes stronger than SHA-256 with ECDSA[1] 
 2). This is inconsistent with RSA-PSS behaviour, where key size is completely
  detached from the used hash algorithm.
 3). This is not how ECDSA signatures in X.509 work, so it doesn't actually 
  limit the signatures on certificates (in other words, as an implementer
  you need to support all hashes with all curves either way)

With the implementers hat on, I'd prefer to drop the curves from signature 
algorithm names/specifications and return to TLS 1.2 behaviour.
With my security hat on, I'd say that we should set the minimal key sizes for 
RSA-PSS signatures too, as we did with ECDSA.

Any other ideas?


 1 - Nick Sullivan from Cloudflare provided me with some stats from random 
5 client hellos from early 2017:

Sigalgs:
ECDSA + SHA-256 = 39104 (78.2%)
ECDSA + (SHA-256 + SHA-384 + SHA-512) = 28678 (57.4%)
ECDSA + (SHA-256 + SHA-384 + !SHA-512) = 8934 (17.9%)
ECDSA + (SHA-256 + !SHA-384 + !SHA-512) = 1492 (2.98%)

Note: many of the 1492 seem to be on iOS and only support:
[RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]

Curves:
none = 757 (1.51%)
P-256 = 49243 (98.5%)
P-384 = 49233 (98.5%)
P-256 + P-384 = 49233 (98.5%)
P-256 + !P-384 = 10 (0.02%)
!P-256 + P-384 = 0 (0%)
-- 
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] Consistency for Signature Algorithms?

[Benjamin Kaduk]

On 07/21/2017 08:23 AM, Hubert Kario wrote:
> Signature Algorithms for ECDSA now define both the curve and the hash 
> algorithm:
>
>   ecdsa_secp256r1_sha256(0x0403),
>   ecdsa_secp384r1_sha384(0x0503),
>   ecdsa_secp521r1_sha512(0x0603),
>
> This is in contrast to the TLS 1.2 protocol, where any hash can be used with 
> any curve.

I assume you saw
https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
raised a different question in this same general area.

I do not see how the response here cannot be the same as it was there:
namely, that the current formulation is assumed to have WG consensus,
having been through two WGLCs; there would need to be rather strong
reasons to make changes at this stage.

-Ben


> There are good reasons for that change:
>  - less combinations to test
>  - establishes the low water mart for security
>
> I see few problems with that though:
>  1). there are not insignificant number of clients that advertise support for 
>   all (at least P-256 and P-384) curves, but don't advertise support for 
>   hashes stronger than SHA-256 with ECDSA[1] 
>  2). This is inconsistent with RSA-PSS behaviour, where key size is completely
>   detached from the used hash algorithm.
>  3). This is not how ECDSA signatures in X.509 work, so it doesn't actually 
>   limit the signatures on certificates (in other words, as an implementer
>   you need to support all hashes with all curves either way)
>
> With the implementers hat on, I'd prefer to drop the curves from signature 
> algorithm names/specifications and return to TLS 1.2 behaviour.
> With my security hat on, I'd say that we should set the minimal key sizes for 
> RSA-PSS signatures too, as we did with ECDSA.
>
> Any other ideas?
>
>
>  1 - Nick Sullivan from Cloudflare provided me with some stats from random 
> 5 client hellos from early 2017:
>
> Sigalgs:
> ECDSA + SHA-256 = 39104 (78.2%)
> ECDSA + (SHA-256 + SHA-384 + SHA-512) = 28678 (57.4%)
> ECDSA + (SHA-256 + SHA-384 + !SHA-512) = 8934 (17.9%)
> ECDSA + (SHA-256 + !SHA-384 + !SHA-512) = 1492 (2.98%)
>
> Note: many of the 1492 seem to be on iOS and only support:
> [RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]
>
> Curves:
> none = 757 (1.51%)
> P-256 = 49243 (98.5%)
> P-384 = 49233 (98.5%)
> P-256 + P-384 = 49233 (98.5%)
> P-256 + !P-384 = 10 (0.02%)
> !P-256 + P-384 = 0 (0%)
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Consistency for Signature Algorithms?

[Dr Stephen Henson]

On 21/07/2017 14:23, Hubert Kario wrote:
> Signature Algorithms for ECDSA now define both the curve and the hash 
> algorithm:
> 
> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
> ecdsa_secp521r1_sha512(0x0603),
> 
> This is in contrast to the TLS 1.2 protocol, where any hash can be used
> with any curve.
> 
> There are good reasons for that change: - less combinations to test -
> establishes the low water mart for security
> 
> I see few problems with that though: 1). there are not insignificant number
> of clients that advertise support for all (at least P-256 and P-384)
> curves, but don't advertise support for hashes stronger than SHA-256 with
> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
> completely detached from the used hash algorithm. 3). This is not how ECDSA
> signatures in X.509 work, so it doesn't actually limit the signatures on
> certificates (in other words, as an implementer you need to support all
> hashes with all curves either way)
> 

There is another and significant problem with the change. In TLS 1.2 support
for a curve was indicated in the supported curves extension and it implied
support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
supported groups extension are for ECDH only. Support for a curve for ECDSA is
indicated in the signature algorithms extension.

I agree though that there is an anomaly here. For example AFAICS in
certificates for TLS1.3 you're allowed (with some caveats) to use a
P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
allowed at all. Is that likely to be a problem in practice? Are there many
such certificates about in the wild?

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/

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

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Russ Housley]

Nick:

Thanks for this summary.  This resolves my previous concerns.

Russ


> On Jul 18, 2017, at 7:06 AM, Nick Sullivan  
> wrote:
> 
> Sean,
> 
> We've had some additional discussions in person here at IETF 99 with folks 
> who were in the proxy certificates and short-lived certs camp, and we think 
> there is now more agreement that the mechanism described in this draft is 
> superior to the alternatives. I've included a summary of some of the pros and 
> cons of the approaches:
> 
> Proxy certificates vs. Delegated Credentials
> Pro proxy certificates:
> - Already deployed in some industries, though not on the Web.
> - Fits the conceptual model that public key == certificate.
> Con proxy certificates:
> - Proxy certificates adds additional complexity to the delegation other than 
> limiting the time period (full X.509, additional constraints  such as 
> hostname).
> - Encourages implementers to reuse PKIX libraries rather than build code as 
> part of TLS:
> -- There have been problems and inconsistencies around pathlen and 
> constraints enforcement in existing PKIX libraries.
> -- Modifying these libraries is more complex and risk prone than delegated 
> creds (which can easily be implemented in TLS as demonstrated by the 3 
> interoperable implementations at the IETF 98 hackathon).
> - In proxy certificates, pathing is SKI dependent, not directly tied to EE 
> cert. This is a binding weaker than delegated credentials which includes a 
> signature over the EE certificate.
> 
> Short-lived certs vs. Delegated Credentials
> Pro short-lived certs:
> - Short lived certs work with existing libraries, no new code changes.
> Con short-lived certs:
> - Not widely available from CAs, especially for EV.
> - Potentially problematic to the CT ecosystem (all certificates must be 
> logged in CT, which may bloat them).
> - Introduces a high-risk operational dependency on external party:
> -- Requires frequent exchanges with an external Certificate Authority (must 
> provide proof of domain possession to CA vs. internally managed credential 
> minter for delegated credentials).
> -- There is no fallback if the CA has outage. With delegated credentials you 
> can fall back to a LURK-style protocol with the long-lived certificate key.
> 
> Given these comparisons, we think the proposed draft is the superior option 
> and would like to continue the discussion about adopting it.
> 
> Nick
> 
> On Fri, May 19, 2017 at 12:58 AM Sean Turner  > wrote:
> All,
> 
> During the WG call for adoption, a couple of questions were raised about 
> comparison/analysis of sub-certs versus proxy and/or short-lived 
> certificates.  There is some discussion currently in the draft, but the 
> chairs feel that these issues need further discussion (and elaboration in the 
> draft) prior to WG adoption.  So let’s keep the conversation going.
> 
> J&S
> 
> > On Apr 12, 2017, at 15:31, Sean Turner  > > wrote:
> >
> > All,
> >
> > At our IETF 98 session, there was support in the room to adopt 
> > draft-rescorla-tls-subcerts [0].  We need to confirm this support on the 
> > list so please let the list know whether you support adoption of the draft 
> > and are willing to review/comment on the draft before 20170429.  If you 
> > object to its adoption, please let us know why.
> >
> > Clearly, the WG is going to need to work through the trade-offs between 
> > short-lived certificates and sub-certs because both seem, to some, to be 
> > addressing the same problem.
> >
> > Cheers,
> >
> > J&S
> >
> > [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts 
> > 
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Consistency for Signature Algorithms?

[Hubert Kario]

On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
> On 07/21/2017 08:23 AM, Hubert Kario wrote:
> > Signature Algorithms for ECDSA now define both the curve and the hash
> > 
> > algorithm:
> >   ecdsa_secp256r1_sha256(0x0403),
> >   ecdsa_secp384r1_sha384(0x0503),
> >   ecdsa_secp521r1_sha512(0x0603),
> > 
> > This is in contrast to the TLS 1.2 protocol, where any hash can be used
> > with any curve.
> 
> I assume you saw
> https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
> raised a different question in this same general area.
> 
> I do not see how the response here cannot be the same as it was there:
> namely, that the current formulation is assumed to have WG consensus,
> having been through two WGLCs; there would need to be rather strong
> reasons to make changes at this stage.

MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory (MUST) 
and no word about any of the other two.

given that we already have CAs that use P-384 for signatures. I'd say this is 
a big conflict between theory and practice.

> > There are good reasons for that change:
> >  - less combinations to test
> >  - establishes the low water mart for security
> > 
> > I see few problems with that though:
> >  1). there are not insignificant number of clients that advertise support
> >  for>  
> >   all (at least P-256 and P-384) curves, but don't advertise support
> >   for
> >   hashes stronger than SHA-256 with ECDSA[1]
> >  
> >  2). This is inconsistent with RSA-PSS behaviour, where key size is
> >  completely>  
> >   detached from the used hash algorithm.
> >  
> >  3). This is not how ECDSA signatures in X.509 work, so it doesn't
> >  actually
> >  
> >   limit the signatures on certificates (in other words, as an
> >   implementer
> >   you need to support all hashes with all curves either way)
> > 
> > With the implementers hat on, I'd prefer to drop the curves from signature
> > algorithm names/specifications and return to TLS 1.2 behaviour.
> > With my security hat on, I'd say that we should set the minimal key sizes
> > for RSA-PSS signatures too, as we did with ECDSA.
> > 
> > Any other ideas?
> > 
> >  1 - Nick Sullivan from Cloudflare provided me with some stats from random
> > 
> > 5 client hellos from early 2017:
> > 
> > Sigalgs:
> > ECDSA + SHA-256 = 39104 (78.2%)
> > ECDSA + (SHA-256 + SHA-384 + SHA-512) = 28678 (57.4%)
> > ECDSA + (SHA-256 + SHA-384 + !SHA-512) = 8934 (17.9%)
> > ECDSA + (SHA-256 + !SHA-384 + !SHA-512) = 1492 (2.98%)
> > 
> > Note: many of the 1492 seem to be on iOS and only support:
> > [RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]
> > 
> > Curves:
> > none = 757 (1.51%)
> > P-256 = 49243 (98.5%)
> > P-384 = 49233 (98.5%)
> > P-256 + P-384 = 49233 (98.5%)
> > P-256 + !P-384 = 10 (0.02%)
> > !P-256 + P-384 = 0 (0%)
> > 
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


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

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

Re: [TLS] Consistency for Signature Algorithms?

[Ilari Liusvaara]

On Fri, Jul 21, 2017 at 02:41:50PM +0100, Dr Stephen Henson wrote:
> On 21/07/2017 14:23, Hubert Kario wrote:
> > Signature Algorithms for ECDSA now define both the curve and the hash 
> > algorithm:
> > 
> > ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
> > ecdsa_secp521r1_sha512(0x0603),
> > 
> > This is in contrast to the TLS 1.2 protocol, where any hash can be used
> > with any curve.
> > 
> > There are good reasons for that change: - less combinations to test -
> > establishes the low water mart for security
> > 
> > I see few problems with that though: 1). there are not insignificant number
> > of clients that advertise support for all (at least P-256 and P-384)
> > curves, but don't advertise support for hashes stronger than SHA-256 with
> > ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
> > completely detached from the used hash algorithm. 3). This is not how ECDSA
> > signatures in X.509 work, so it doesn't actually limit the signatures on
> > certificates (in other words, as an implementer you need to support all
> > hashes with all curves either way)
> > 
> 
> There is another and significant problem with the change. In TLS 1.2 support
> for a curve was indicated in the supported curves extension and it implied
> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
> supported groups extension are for ECDH only. Support for a curve for ECDSA is
> indicated in the signature algorithms extension.

I suppose some new dual-version TLS 1.2/1.3 libraries might have the
same issue as mine: supported groups is just plain ignored for ECDSA,
and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.

> I agree though that there is an anomaly here. For example AFAICS in
> certificates for TLS1.3 you're allowed (with some caveats) to use a
> P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
> allowed at all. Is that likely to be a problem in practice? Are there many
> such certificates about in the wild?

Actually, P-256+SHA512 is allowed with a caveat, even if the
certificate is not self-signed. And with the same caveat, server can
send a certificate signed with P-256+SHA3-512, despite TLS
codepoint for it having never existed (not many clients can validate it
through).




-Ilari





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

Re: [TLS] Consistency for Signature Algorithms?

[Watson Ladd]

On Fri, Jul 21, 2017 at 8:00 AM, Ilari Liusvaara 
wrote:

> On Fri, Jul 21, 2017 at 02:41:50PM +0100, Dr Stephen Henson wrote:
> > On 21/07/2017 14:23, Hubert Kario wrote:
> > > Signature Algorithms for ECDSA now define both the curve and the hash
> > > algorithm:
> > >
> > > ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503),
> > > ecdsa_secp521r1_sha512(0x0603),
> > >
> > > This is in contrast to the TLS 1.2 protocol, where any hash can be used
> > > with any curve.
> > >
> > > There are good reasons for that change: - less combinations to test -
> > > establishes the low water mart for security
> > >
> > > I see few problems with that though: 1). there are not insignificant
> number
> > > of clients that advertise support for all (at least P-256 and P-384)
> > > curves, but don't advertise support for hashes stronger than SHA-256
> with
> > > ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key
> size is
> > > completely detached from the used hash algorithm. 3). This is not how
> ECDSA
> > > signatures in X.509 work, so it doesn't actually limit the signatures
> on
> > > certificates (in other words, as an implementer you need to support all
> > > hashes with all curves either way)
> > >
> >
> > There is another and significant problem with the change. In TLS 1.2
> support
> > for a curve was indicated in the supported curves extension and it
> implied
> > support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
> > supported groups extension are for ECDH only. Support for a curve for
> ECDSA is
> > indicated in the signature algorithms extension.
>
> I suppose some new dual-version TLS 1.2/1.3 libraries might have the
> same issue as mine: supported groups is just plain ignored for ECDSA,
> and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.
>
> > I agree though that there is an anomaly here. For example AFAICS in
> > certificates for TLS1.3 you're allowed (with some caveats) to use a
> > P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512
> is not
> > allowed at all. Is that likely to be a problem in practice? Are there
> many
> > such certificates about in the wild?
>
> Actually, P-256+SHA512 is allowed with a caveat, even if the
> certificate is not self-signed. And with the same caveat, server can
> send a certificate signed with P-256+SHA3-512, despite TLS
> codepoint for it having never existed (not many clients can validate it
> through).
>

But this doesn't affect security if i understand the model correctly.

>
>
>
>
> -Ilari
>
>
>
>
>
> ___
> 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] SNI with early data

[Benjamin Kaduk]

I put some proposed tidying in
https://github.com/tlswg/tls13-spec/pull/1061 .

More inline.

On 07/21/2017 05:14 AM, Matt Caswell wrote:
> On 20/07/17 18:10, Benjamin Kaduk wrote:
>> On 07/20/2017 04:51 AM, Matt Caswell wrote:
>>> I note in draft-21 the following text:
>>>
>>>When clients use a PSK obtained externally to send early data, then
>>>the following additional information MUST be provisioned to both
>>>parties:
>>>
>>>-  The TLS version number for use with this PSK
>>>
>>>-  The cipher suite for use with this PSK
>>>
>>>-  The Application-Layer Protocol Negotiation (ALPN) protocol
>>>   [RFC7301], if any is to be used
>>>
>>>-  The Server Name Indication (SNI), if any is to be used
>> These are in addition to the hash algorithm provisioned with the
>> external psk that is needed for 1-RTT operation, as mentioned somewhat
>> in passing in section 4.2.10
>>
>>> Later it says this:
>>>
>>>In order to accept early data, the server MUST have accepted a PSK
>>>cipher suite and selected the first key offered in the client's
>>>"pre_shared_key" extension.  In addition, it MUST verify that the
>>>following values are consistent with those negotiated in the
>>>connection during which the ticket was established.
>>>
>>>-  The TLS version number and cipher suite.
>>>
>>>-  The selected ALPN [RFC7301] protocol, if any.
>>>
>>>
>>> The language about "during which the ticket was established" seems to
>>> suggest that the following checks do not apply to an external PSK -
>>> which I don't think is intended. Additionally there does not seem to
>> These values are a subset of those listed above.  I believe this block
>> of text only applies to NST-provisioned PSKs being used for early data,
>> as the previous text applies to external PSKs being used for early
>> data.
> Interesting because I assumed the intention was the opposite. I'm not
> sure why this restriction should only apply to NST-provisioned PSKs.

Because a similar (slightly stronger) restriction already applies to
external PSKs, but is elsewhere in the document?

>
>>  So, since the previous list is a superset, there is no problem
>> caused by this text not applying to external PSKs.
> The earlier text is about what needs to be *provisioned* to both
> parties. This text is about what MUST be verified on the server. I
> think these are two subtly different things. I see no reason to
> exclude SNI from requiring to be verified, nor do I see a reason to

SNI must be verified in order to use the ticket for 1-RTT, which is a
prerequisite for using it for 0-RTT.  That's just covered elsewhere in
the document, and the editor apparently didn't see a need to repeat the
requirement here.

> restrict it to NST PSKs only. Either you MUST do it for both types of
> PSK or you don't need to do it at all. What is the benefit of
> complicating things by providing a partial list that MUST be verified
> for one type of PSK only?

Yes, you MUST do it for both types.  It's just (prior to my pull
request) specified in different parts of the spec, due to how it evolved.

Perhaps this requires my understanding of what it means to "provision a
PSK with associated values", namely, that the given PSK is only defined
for use with those values, and (e.g.) a server that negotiates the use
of that PSK with different value(s) is in violation of the spec.  Maybe
"provisioning a PSK with associated values" can be interpreted
differently, though, but I'm still unclear on what exactly such an
alternate interpretation would be.

> If this block of text is about NST PSKs only then the implication is
> that a server MAY tolerate discrepancies in ALPN for external PSK. At
> least that is the way I read it (although I don't think that was the
> intention).

[I'd just be repeating myself if I added something here.]

>>> be a requirement on the server to check that the SNI is consistent.
>>> So, there is a mandatory requirement for an external PSK to specify
>>> the SNI, but no requirement on the server to check that it is actually
>>> correct. Is this discrepancy intentional?
>>>
>> I'm not sure I fully understand what you are saying.
>> The text says that (for external PSKs) the SNI must be provisioned to
>> both parties, which to me implies that the server must only use the
>> given PSK for early data with the specified SNI.  (That is, that the
>> server has to check.)
> It does not imply that to me. It says it has to be provisioned. That
> fact that NST PSK MUST verify, implies to me that non-NST PSKs may
> tolerate discrepancies.

So ... what does it mean to have it provisioned and then not do anything
with it?  In such an interpretation, the text about needing to provision
those values along with the PSK has no practical effect, making it "dead
code" that should not have been in the spec in the first place.  An
interpretation where that text is not "dead code" seems much more plausible.

-Ben

>> For tickets, the requirement 

Re: [TLS] Consistency for Signature Algorithms?

[Benjamin Kaduk]

On 07/21/2017 09:34 AM, Hubert Kario wrote:
> On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
>> On 07/21/2017 08:23 AM, Hubert Kario wrote:
>>> Signature Algorithms for ECDSA now define both the curve and the hash
>>>
>>> algorithm:
>>>   ecdsa_secp256r1_sha256(0x0403),
>>>   ecdsa_secp384r1_sha384(0x0503),
>>>   ecdsa_secp521r1_sha512(0x0603),
>>>
>>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
>>> with any curve.
>> I assume you saw
>> https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
>> raised a different question in this same general area.
>>
>> I do not see how the response here cannot be the same as it was there:
>> namely, that the current formulation is assumed to have WG consensus,
>> having been through two WGLCs; there would need to be rather strong
>> reasons to make changes at this stage.
> MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory (MUST) 
> and no word about any of the other two.
>
> given that we already have CAs that use P-384 for signatures. I'd say this is 
> a big conflict between theory and practice.
>

I'm afraid I don't understand this remark.  There is the caveat to which
Ilari alludes, that the server can send whatever chain it has, if the
server can't send a chain that complies with the client's
signature_algorithms.  Since certificate validation is assumed to be
largely a function of the PKI library and not really in scope for the
TLS spec itself, this is not particularly problematic.  The other main
usage of the signature_algorithms limits what can be used in
CertificateVerify, which is directly relevant to TLS and depends on the
key attested to in the certificate.  Are you claiming that there are
servers that only possess certificates with p384 keys (i.e., no RSA or
p256 or other fallback cert)?

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

Re: [TLS] Consistency for Signature Algorithms?

[Dr Benjamin Kaduk]

On 07/21/2017 08:41 AM, Dr Stephen Henson wrote:
> On 21/07/2017 14:23, Hubert Kario wrote:
>> Signature Algorithms for ECDSA now define both the curve and the hash 
>> algorithm:
>>
>> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
>> ecdsa_secp521r1_sha512(0x0603),
>>
>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
>> with any curve.
>>
>> There are good reasons for that change: - less combinations to test -
>> establishes the low water mart for security
>>
>> I see few problems with that though: 1). there are not insignificant number
>> of clients that advertise support for all (at least P-256 and P-384)
>> curves, but don't advertise support for hashes stronger than SHA-256 with
>> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
>> completely detached from the used hash algorithm. 3). This is not how ECDSA
>> signatures in X.509 work, so it doesn't actually limit the signatures on
>> certificates (in other words, as an implementer you need to support all
>> hashes with all curves either way)
>>
> There is another and significant problem with the change. In TLS 1.2 support
> for a curve was indicated in the supported curves extension and it implied
> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
> supported groups extension are for ECDH only. Support for a curve for ECDSA is
> indicated in the signature algorithms extension.

Could you say a bit more about why you believe this to be a problem?  On
the face of it, it seems that the previous state overloaded a single
field to mean multiple only semi-related things, whereas the new
formulation keeps things more orthogonal and easier to implement in a
modular way.  That is, groups are for key exchange, and signature
algorithms are for signing, and there is no muddy overlap between them.

Thanks,

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

Re: [TLS] draft-ietf-tls-exported-authenticator questions

[Benjamin Kaduk]

Unrelated to Ilari's questions, I wonder if we want to say anything
about certificate_request_context values being unique across both in-TLS
post-handshake auth and exported authenticators.

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

Re: [TLS] Consistency for Signature Algorithms?

[Dr Stephen Henson]

-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/
On 21/07/2017 20:45, Dr Benjamin Kaduk wrote:
> On 07/21/2017 08:41 AM, Dr Stephen Henson wrote:
>> On 21/07/2017 14:23, Hubert Kario wrote:
>>> Signature Algorithms for ECDSA now define both the curve and the hash 
>>> algorithm:
>>>
>>> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), 
>>> ecdsa_secp521r1_sha512(0x0603),
>>>
>>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
>>> with any curve.
>>>
>>> There are good reasons for that change: - less combinations to test -
>>> establishes the low water mart for security
>>>
>>> I see few problems with that though: 1). there are not insignificant number
>>> of clients that advertise support for all (at least P-256 and P-384)
>>> curves, but don't advertise support for hashes stronger than SHA-256 with
>>> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is
>>> completely detached from the used hash algorithm. 3). This is not how ECDSA
>>> signatures in X.509 work, so it doesn't actually limit the signatures on
>>> certificates (in other words, as an implementer you need to support all
>>> hashes with all curves either way)
>>>
>> There is another and significant problem with the change. In TLS 1.2 support
>> for a curve was indicated in the supported curves extension and it implied
>> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the
>> supported groups extension are for ECDH only. Support for a curve for ECDSA 
>> is
>> indicated in the signature algorithms extension.
> 
> Could you say a bit more about why you believe this to be a problem?  On the
> face of it, it seems that the previous state overloaded a single field to mean
> multiple only semi-related things, whereas the new formulation keeps things 
> more
> orthogonal and easier to implement in a modular way.  That is, groups are for
> key exchange, and signature algorithms are for signing, and there is no muddy
> overlap between them.
> 

I didn't mean there was a problem with the current spec, I meant there was a
problem with the proposed change: i.e. to remove the curve requirement from
signature algorithms.

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/

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

Re: [TLS] Consistency for Signature Algorithms?

[Dr Stephen Henson]

On 21/07/2017 16:00, Ilari Liusvaara wrote:
> 
> I suppose some new dual-version TLS 1.2/1.3 libraries might have the
> same issue as mine: supported groups is just plain ignored for ECDSA,
> and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.
> 

That is potentially a problem yes.

Suppose a server has an EE certificate with a P-256 public key and the client
preference order is ecdsa_secp384r1_sha384, ecdsa_secp256r1_sha256. For TLS 1.3
it will use ecdsa_secp256r1_sha256 and sign TLS messages using P-256+SHA256.

In TLS 1.2 the same preference list means sha384+ecdsa, sha256+ecdsa without the
curve restriction. In this case the server might sign the message using
P-256+SHA384 because the client prefers it. That isn't allowed in TLS 1.3 but is
in TLS 1.2. A client which enforces the TLS 1.3 signature algorithm rules for
TLS 1.2 might abort the connection at that point.

>> I agree though that there is an anomaly here. For example AFAICS in
>> certificates for TLS1.3 you're allowed (with some caveats) to use a
>> P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
>> allowed at all. Is that likely to be a problem in practice? Are there many
>> such certificates about in the wild?
> 
> Actually, P-256+SHA512 is allowed with a caveat, even if the
> certificate is not self-signed. And with the same caveat, server can
> send a certificate signed with P-256+SHA3-512, despite TLS
> codepoint for it having never existed (not many clients can validate it
> through).
> 

Yes you're right, the caveat of not otherwise having any suitable chain allows
that case.

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/

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

Re: [TLS] draft-ietf-tls-exported-authenticator questions

[Watson Ladd]

On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk  wrote:
> Unrelated to Ilari's questions, I wonder if we want to say anything about
> certificate_request_context values being unique across both in-TLS
> post-handshake auth and exported authenticators.

This context is not a security sensitive thing: it is for disambiguation.
>
> -Ben
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

Re: [TLS] draft-ietf-tls-exported-authenticator questions

[Ilari Liusvaara]

On Fri, Jul 21, 2017 at 10:17:08PM -0700, Watson Ladd wrote:
> On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk  wrote:
> > Unrelated to Ilari's questions, I wonder if we want to say anything about
> > certificate_request_context values being unique across both in-TLS
> > post-handshake auth and exported authenticators.
> 
> This context is not a security sensitive thing: it is for disambiguation.

I'm not so sure about that.

If crc is repeated within a connection, then the old certificate
message can be replayed.

If crc is guessed, then reply can be pregenerated anytime during
connection.

However, neither seems crticial, but might be of magnitude to note.


-Ilari

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

Re: [TLS] draft-ietf-tls-exported-authenticator questions

[Watson Ladd]

On Fri, Jul 21, 2017 at 10:34 PM, Ilari Liusvaara
 wrote:
> On Fri, Jul 21, 2017 at 10:17:08PM -0700, Watson Ladd wrote:
>> On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk  wrote:
>> > Unrelated to Ilari's questions, I wonder if we want to say anything about
>> > certificate_request_context values being unique across both in-TLS
>> > post-handshake auth and exported authenticators.
>>
>> This context is not a security sensitive thing: it is for disambiguation.
>
> I'm not so sure about that.
>
> If crc is repeated within a connection, then the old certificate
> message can be replayed.
>
> If crc is guessed, then reply can be pregenerated anytime during
> connection.
>
> However, neither seems crticial, but might be of magnitude to note.

Yes, if we want  freshness then we need a challenge-response protocol.
I don't recall if the H2 draft does.

>
>
> -Ilari



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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